Re: [Libreoffice] ld dynamic linker hash style

Hi Michael,

On Tue, Apr 05, 2011 at 11:53:55AM +0100, Michael Meeks wrote:
> On Mon, 2011-04-04 at 22:51 +0200, Francois Tigeot wrote:
> > During the last few days, my builds have been broken with this error message:
> >   makedepend: Shared object has no run-time symbol table
>
>       Oh - that is a downer indeed. What system are you using ?

DragonFly.

> > The problem is, this flag also prevents ld to write classic ELF ".hash"
> > sections, preventing some systems to be able to run the generated binaries.
>
>       Right - because they are big, and there is not much point in dragging
> all that obsolete bloat around ;-)

Well, if you can't run binaries without it, that's not so obsolete IMO.

> > One of my machines is using binutils-2.21 and cannot run binaries linked with
> > the --hash-style=gnu option. I need to investigate.
>
>       So - if you want to create binaries to run on other systems, then you
> need to beware. You will have hideous problems beyond belief, and way
> beyond just linking issues: glibc symbol versions alone will break
> almost everything :-)

The first step is to have the binaries run on the system they were
compiled on.
And I'm pretty sure I won't have any trouble with glibc ;-)

What I meant to say is even with binutils-2.21, the gnu-hash option doesn't
work in all cases.

> > Howewer, the fix is quite simple: replace --hash-style=gnu by
> > --hash-style=both The --hash-style=both option generates both old
> > and new-style sections, keeping all binutils happy.
>
>       Well - we need to do this for the 'Generic' builds with an explicit
> =both (cf. distro-configs) so it can run even on ancient systems, but
> Linux distributions in general should use the --hash-style=gnu if it is
> present in the toolchain (IMHO).

You lost me here: with the last commit, --hash-style=gnu is the default
and is not limited to Linux or specific Linux distributions.

>       So - I'm really not convinced :-) What system are you compiling on,
> and/or did you upgrade your gcc/binutils without upgrading glibc ?

System: DragonFly 2.9/x86_64
gcc: 4.4.5
binutils: 2.21
glibc: none

Be convinced :)

>       I guess it might be a good idea to default to 'auto' for hash-style,
> and compile and link a small test program with that, defaulting to 'gnu'
> if that is supported, and no flag if not. Should be fairly easy to do
> that with an AC_TRY_RUN (?).

That would be *much* better.

Cheers,

-- 
Francois Tigeot