Bugzilla Bug 133583

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 an attachment (id=86918) [edit]
create hunspell_pic.a library

Created an attachment (id=86919) [edit]
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 an attachment (id=86925) [edit]
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 an attachment (id=86926) [edit]
hunspell-1.1.4-renameexes.patch

Created an attachment (id=86927) [edit]
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!