Re: some odd library loading errors

[Rich Felker <dalias@libc.org>]

On Tue, Nov 17, 2015 at 04:45:16PM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-11-17 10:27:28 -0500]:
> > On Tue, Nov 17, 2015 at 04:23:56PM +0100, Szabolcs Nagy wrote:
> > > * u-uy74@aetey.se <u-uy74@aetey.se> [2015-11-17 13:14:29 +0100]:
> > > > The environment:
> > > >  Linux 3.# on x#86
> > > >  binutils 2.24
> > > >  musl 1.1.8 compiled for i486
> > > >  gcc 5.2.0
> > > > 
> > > > (the gcc has arch=i486 as the default)
> > > > 
> > > > No oddities were observed with the above until trying to use libatomic
> > > > which is provided by gcc-5.2.0.
> > > > 
> > > > The test case:
> > > > 
> > > > $ cat >a.c <<____
> > > > int main(){ return 0; }
> > > > ____
> > > > 
> > > > $ gcc -o a a.c -L<path-to-gcc-5.2.0-libs> -latomic
> > > > 
> > > > $ LD_LIBRARY_PATH=<path-to-gcc-5.2.0-libs> ./a
> > > > Error relocating <path-to-gcc-5.2.0-libs>/libatomic.so.1: __atomic_store_8: symbol not found
> > > > Error relocating <path-to-gcc-5.2.0-libs>/libatomic.so.1: __atomic_exchange_8: symbol not found
> > > > Error relocating <path-to-gcc-5.2.0-libs>/libatomic.so.1: __atomic_load_8: symbol not found
> > > > Error relocating <path-to-gcc-5.2.0-libs>/libatomic.so.1: __atomic_compare_exchange_8: symbol not found
> > > > 
> > > 
> > > this is a known issue, they use the gnu ifunc extension of
> > > elf to dispatch between different implementations based on
> > > the machine at library loadtime.
> > 
> > Is there something we need to add to the musl patches to disable this?
> > I would like to make sure both that it's going upstream and that I
> > have a patch in my toolchain build repo.
> > 
> 
> i guess --disable-gnu-indirect-function could be the default when
> gcc targets musl (assuming musl will not implement ifuncs anytime soon).

I think that's a reasonable assumption. Based on what I've seen
lately, rather than finding solutions to the problems we knew about
already, the rabbit hole keeps going deeper...

If you have reason to believe otherwise could you explain how we might
reasonably support ifunc?

Rich