This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: A patch for elf32.em (Re: GNU/Linux vs. libtool --no-undefined)
- To: Ian Lance Taylor <ian at zembu dot com>
- Subject: Re: A patch for elf32.em (Re: GNU/Linux vs. libtool --no-undefined)
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 07 Feb 2001 05:07:07 -0200
- Cc: "H . J . Lu" <hjl at valinux dot com>, Fergus Henderson <fjh at cs dot mu dot oz dot au>, binutils at sourceware dot cygnus dot com
- Organization: GCC Team, Red Hat
- References: <20010205211708R.mitchell@codesourcery.com><jebssgkl77.fsf@hawking.suse.de><20010207024456.A10994@venus.cs.mu.oz.au><jeu2673iwq.fsf@hawking.suse.de> <20010206112928.A29981@valinux.com><20010207120535.A25034@hg.cs.mu.oz.au><20010206171540.E5565@valinux.com> <sihf27gpt3.fsf@daffy.airs.com>
On Feb 7, 2001, Ian Lance Taylor <ian@zembu.com> wrote:
> The original error appears to be warning about an undefined symbol
> reference from a shared library. Is that so? If it is, then I think
> the linker should be fixed to not warn about undefined references from
> shared libraries, even when --no-undefined is used. We care whether
> each reference is satisfied somewhere. I don't think we care whether
> each shared library included in the link has all symbols satisfied.
> Do we?
Assume I have a component library A, that is not self-contained, but
rather, it contains a few symbols that are supposed to be defined by
its users. Now assume I want to create a library B, with another
component that builds upon A, defining all symbols that are missing in
A, plus a number of other symbols that implement B's components.
I want B to be a complete dlopenable module, i.e., one that doesn't
depend on any external symbols that are not provided by libraries it's
linked with. So, I link B with --no-undefined --export-dynamic.
During the development phase, I keep A as a PIC static library, just
so that builds are faster (not having to compile PIC and non-PIC
versions of its object files). Various times, --no-undefined detects
that symbols are missing when linking B, because of various changes in
A and B.
At some point, someone suggests I'd save on building time if I created
A as a shared library, because then the link step of B wouldn't have
to copy pretty much everything from A into B; the dynamic linker would
take care of that. And that's indeed the case.
When my program dlopens B (with RTLD_LAZY, of course :-), it works
fine, and I'm a happy camper. Until, some day, after refactoring some
components in A, I exercise some seldom-exercised feature, and the
program crashes.
Some investigation leads to the conclusion that B had an undefined
symbol that it expected to get from A, but that I had forgotten to
define in A.
Why didn't --no-undefined work? Should the fact that A is shared or
static make any difference?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me