libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -dlopen self and optimizing away symbols


From: Ralf Wildenhues
Subject: Re: -dlopen self and optimizing away symbols
Date: Thu, 17 Aug 2006 07:42:00 +0200
User-agent: Mutt/1.5.12-2006-07-14

Hello Albert,

* Albert Chin wrote on Thu, Aug 17, 2006 at 12:39:25AM CEST:
> Just built openldap-2.3.25 on HP-UX 11.23/IA. 'make check' fails
> because a symbol wasn't available in the main binary which dlopen()'ed
> a module that required the symbol. The main binary was built with
> "-dlopen self".

> Unfortunately, the HP-UX 11.23/IA compiler, when generating
> .libs/slapd, will optimize _away_ symbols that are not used by any of
> the object files being linked:

Which compiler option causes it to optimize away the symbols?
Which linker option is that translated to?

> How do we solve this? I suppose we could build without CFLAGS but then
> we'd lose +DD64 for 64-bit objects.

Probably adding a linker flag at the end to undo the dangerous setting
should be safest, given there is such a flag.

But say, why is -Wl,-E not passed to the link line?  It should be
export_dynamic_flag_spec.  And it should have the desired effect:
|  -E             Mark all symbols defined by a program for export
|                 to shared libraries.  In a +compat mode link, ld
|                 marks only those symbols that are actually
|                 referenced by a shared library seen at link time.
|                 In a +std link, all symbols are exported by
|                 default, so -E is not necessary to make symbols
|                 visible.  However, it has an additional side
|                 effect of identifying all exported symbols as
|                 necessary, so that they will not be removed when
|                 using dead code elimination (+Oprocelim).

Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I
guess; but that should not even be necessary, given above documentation
(from ld(1)).

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]