It happens on openoffice compile. A way to solve first: Quick and dirty: Add 'use amd64 && append-flags "-fPIC"' to the hunspell ebuild. Debian shows a proper way: http://packages.debian.org/unstable/text/hunspell http://ftp.debian.org/debian/pool/main/h/hunspell/hunspell_1.1.4-3.diff.gz (hunspell-1.1.4/debian/patches/01_pic_versions.dpatch - This adds a hunspell_pic.a library next to the non-pic hunspell.a library version.) http://go-oo.org/patches/src680/static-libs-use-_pic.diff This is the error a user gets: Making: ../../../unxlngx6.pro/lib/libspell680lx.so g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' -shared -Wl,-O1 -Wl,--version-script ../../../unxlngx6.pro/misc/spell_spell680lx.map -L../../../unxlngx6.pro/lib -L../lib -L/var/tmp/portage/openoffice-680.169.0/work/ooo-build/build/src680-m169/solenv/unxlngx6/lib -L/var/tmp/portage/openoffice-680.169.0/work/ooo-build/build/src680-m169/solver/680/unxlngx6.pro/lib -L/var/tmp/portage/openoffice-680.169.0/work/ooo-build/build/src680-m169/solenv/unxlngx6/lib -L/opt/gcj-4.1.0/lib64 -L/opt/gcj-4.1.0/jre/lib/amd64 -L/opt/gcj-4.1.0/jre/lib/amd64/server -L/opt/gcj-4.1.0/jre/lib/amd64/native_threads -L/usr/lib64 -L/usr/lib64 -L/usr/lib64/mozilla-firefox ../../../unxlngx6.pro/slo/spell_dflt_version.o ../../../unxlngx6.pro/slo/spell_dflt_description.o -o ../../../unxlngx6.pro/lib/libspell680lx.so ../../../unxlngx6.pro/slo/sprophelp.o ../../../unxlngx6.pro/slo/sreg.o ../../../unxlngx6.pro/slo/sspellimp.o -luno_cppu -luno_cppuhelpergcc3 -lvos3gcc3 -ltl680lx -lsvt680lx -lsvl680lx -lvcl680lx -luno_sal -lucbhelper3gcc3 -lutl680lx -llng680lx -lhunspell -ldl -lpthread -lm -Wl,-Bdynamic -lstlport /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libhunspell.a(dictmgr.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libhunspell.a: could not read symbols: Bad value collect2: ld returned 1 exit status I hope I did not miss something. :)
hmm; hunspell isn't keyworded for amd64 yet, and openoffice is explicitly keyworded -amd64. What are you building for?
hunspell does fine on amd64. recent openoffice milestones do fine on amd64. I maintain an openoffice overlay for these milestones. With the help of Chaosite (nickname) we get things ready for amd64. And one thing is to report issues so things do fine when you keyword them amd64 in portage. ;)
Created attachment 86918 [details, diff] create hunspell_pic.a library
Created attachment 86919 [details, diff] add diff to ebuild
I've no problem with you reporting; I just need to understand what you're trying to achieve, in order to be confident that fixes are appropriate. Presumably openoffice is loading the hunspell archive dynamically; I had assumed that it was linked to openoffice at build time (in which case it shouldn't need -fPIC, unless there's something about amd64 that I don't understand). If it's loading it dynamically, it is odd that it isn't doing it with a shared library (.so)). openoffice, amd64 teams - any comments?
No problem. ;) I do not understand it. I just see what Debian and Ubuntu does. I test right now on x86 that it does not break openoffice. hunspell just ships a non-pic static library which causes the error on amd64.
Oh I get it - openoffice is making its own shared library from the hunspell archive. In which case we should always be using the PIC versions in openoffice (regardless of amd64), otherwise we'll end up with TEXTRELs in libspell680lx.so - something to check in the openoffice build.
(In reply to comment #7) > In which case we should always be using the PIC versions in openoffice > (regardless of amd64), otherwise we'll end up with TEXTRELs in libspell680lx.so > - something to check in the openoffice build. > which indeed happens and is bug #126452
Wouldn't be simpler to make hunspell build a shared library at side of the static archive? Like it's done for a52dec and libdts?
True. I can confirm that libspell680li.so has TEXTRELs on x86. There are issues with libspell680lp.so on ppc. bug 126587. Could that be sourced from a non-pic version of hunspell.a? https://bugs.gentoo.org/show_bug.cgi?id=126587#c20 says: "... all major ppc distributions (Debian for example) has OO 2.0.2 for ppc ready and working."
Having it as .so isn't difficult but it's taking me some time mainly for collisions with the other patch, but I'm almost done.
Created attachment 86925 [details, diff] hunspell-1.1.4-libtool.patch This patch make use of libtool for building the libraries, thus installs copies of .so libraries, that are built correctly with -fPIC, which should solve all the problems related to PIC and textrels. It needs an updated execrename patch I'm going to attach and an ebuild patch that I'm going to attach too.
Created attachment 86926 [details, diff] hunspell-1.1.4-renameexes.patch
Created attachment 86927 [details, diff] Ebuild patch This is the ebuild patch, it adds the patches in the correct order, uses eautoreconf rather than autoreconf, runs elibtoolize for safety, uses make instead of emake for install.
ok; building an so is fine in and of itself, but openoffice builds libspell680lx.so from the hunspell object files _and also_ others (see the log extract in c#1). So the .so as built isn't useful to openoffice, unless the openoffice build is modified more significantly. I guess the advantage of libtool is that it builds (or should build ;) ) the right thing on any platform. I'll do whatever openoffice will require - so over to you, suka ;) If you want to do the pic archive thing (see patch on go-oo.org referenced in c#1) then I'll bump it to build the _pic.a archives. Probably easiest in the short term. In the long term, it would be better for upstream openoffice to publish an API that spell checkers can adhere to, so spellcheckers can build .so's independently - which leads me to suggest that doing the .so thing should be driven upstream. (BTW I never saw the textrels in libspell680lx.so because I'm using the hardened compiler, which built the objects PIE, which was PIC enough in this case!)
Just to note: If you are going to build the _pic.a we just need the hunk to link to hunspell_pic. I use system agg which fails with the diff from Debian. @ suka Is it ok to you that I add a diff to ooo-build for this then?
Kevin I don't understand why it won't work. For what I can see from the error log, openoffice is simply passing -lhunspell, that fails because there's no .so and thus ld takes /usr/lib64/libhunspell.a that is non-PIC. When the .so is present -lhunspell will take /usr/lib64/libhunspell.so, that is PIC and will go on. This will allow to link without changes to openoffice buildsystem I think.
Hanno can you try to build openoffice with the modified hunspell to build .so libraries and without the hunks from debian patches to use _pic libraries? That way should build and link libhunspell dynamically, not requiring a rebuild in case of version bump or security issues.
(In reply to comment #17) Ah; thanks - yet more fog clears. So if we build the .so, no change to the openoffice build. Has to be the best solution, you agree suka?
(In reply to comment #18) > Hanno can you try to build openoffice with the modified hunspell to build .so > libraries ... @ Diego Already on the way for x86. I will tell Chaosite to test this on amd64. Latter one may take some time to get a result.
(In reply to comment #19) > > So if we build the .so, no change to the openoffice build. Has to be the best > solution, you agree suka? I naturally always agree that solutions which require no action on my part are the best ;) Will test it now
On x86: The library libspell680li.so links to hunspell.so just fine. The TEXREL vanishes. Runtime does just fine aswell. As expected.
ok; in CVS :) Thanks for the great help, everyone. I'll mention this change to upstream. (it's not keyworded ~amd64 yet; Flameeyes will do that)
Just wanted to add, that the TEXTREL also went away with the hunspell update, good job everyone!
