This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: build-shlib-helper reporting of undefined symbols


> I'm in the process of submitting a MicroBlaze port to libc-ports, and I find
> that like other architectures, I'm explicitly linking with ld.so for a number
> of the libraries in my target's Makefile to resolve undefined symbols.

That's unfortunate but if it's the status quo for other ports then
following their example is probably the best way decouple progress on
your port from generic build improvements that nobody expects you to
tackle on your own.

> I have seen anecdotally that removing the linker command '-z,defs' in the
> build-shlib-helper (diff below) allows me to successfully build a functional
> MicroBlaze toolchain without requiring any of the explicit ld.so links.

Losing the -z defs functionality is bad in two ways.  First, it means
someone could introduce a bona fide defined-nowhere symbol and not get a
clear error message proximate to the cause.  That is mostly a nuisance,
since any attempt to thoroughly test the shared object in question would
discover the run-time error for the missing symbol.  Second, and much
more subtle, it means the shared objects you build do not get symbol
version binding for the references they make to ld.so symbols.  With the
right set of future circumstances, this could mean that the (then) old
binaries produced today start failing in strange ways.  In practice,
these will be binaries that are part of the glibc package and so they
will be updated in lock-step with installing a new ld.so.  But I find it
a scary possibility nonetheless (it's really more an explanation of why
everybody ought to be using -z defs to build all their shared objects
than a real concern for the libc build itself).  

We will absolutely not accept any change to remove -z defs in the
generic code, and we'd also object to any port doing that as a
workaround in its own sysdeps makefiles or configure scripts.

> Alternatively, Joseph had suggested that a group with --as-needed
> ld.so for each shared library link might be the best option;
> 
> >I think we should make all the miscellaneous shared libraries and .so 
> >files be linked more like normal libraries linked with a shared glibc 
> >after installation.  That is, --start-group libc.so libc_nonshared.a 
> >--as-needed ld.so --no-as-needed --end-group.  And with that change, 
> >remove all the miscellaneous rules in various makefiles (sysdeps and 
> >otherwise) to link this or that library with ld.so or libc_nonshared.a.

I agree.  We should also do this for linking programs (tests and
others).  But it needs to be done in a way that makes sure all such
targets have dependencies on all the constituents of their links.

> If this was to be done, where would be the right place to do it?

It's probably all in Makerules and mostly confined to the build-shlib*
variables and rules.  But someone pretty familiar with the makefiles
would need to look over everything to find all the details.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]