Building without -Wl,-Bsymbolic-functions

Building without -Wl,-Bsymbolic-functions

[Jens]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 307 bytes --]


Hi!

Im building musl inside an oldish uclibc environment based on uclibc 
0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.

The linker does not accept -Bsymbolic-functions.

Im now building the shared library despite of this.

How broken will the musl libc be without -Bsymbolic-functions ?

Cheers,
Jens Låås

Re: Building without -Wl,-Bsymbolic-functions

[Rich Felker]

On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote:
> 
> Hi!
> 
> Im building musl inside an oldish uclibc environment based on uclibc
> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.
> 
> The linker does not accept -Bsymbolic-functions.
> 
> Im now building the shared library despite of this.
> 
> How broken will the musl libc be without -Bsymbolic-functions ?

If building without it entirely, the shared libc will just crash.

If replacing it with -Bsymbolic, it will run, but global variables in
libc that are accessed by the application (e.g. environ, optind, ...)
will actually have separate copies in libc and the application, and
thus the app won't work as expected.

A patch to add -Bsymbolic-functions to old binutils would be very
welcome... In the mean time, you could compile a new ld and pass the
-B option to gcc to give it the path for the new ld.


Rich

Re: Building without -Wl,-Bsymbolic-functions

[idunham]

> On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote:
>>
>> Hi!
>>
>> Im building musl inside an oldish uclibc environment based on uclibc
>> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.
>>
>> The linker does not accept -Bsymbolic-functions.
>>
>> Im now building the shared library despite of this.
>>
>> How broken will the musl libc be without -Bsymbolic-functions ?
>
> If building without it entirely, the shared libc will just crash.
>
> If replacing it with -Bsymbolic, it will run, but global variables in
> libc that are accessed by the application (e.g. environ, optind, ...)
> will actually have separate copies in libc and the application, and
> thus the app won't work as expected.
Last I checked, ISTR it was "Illegal instruction" or segfault (even for
hello world); I forget which was which, but both did not work at all.

> A patch to add -Bsymbolic-functions to old binutils would be very
> welcome... In the mean time, you could compile a new ld and pass the
> -B option to gcc to give it the path for the new ld.
The patch isn't trivial to get right, but 2.17.50 (20070703) is a
significant improvement in many other ways (a few code generation fixes
among them)...
I've built a tarball, but not really posted it publicly (tarballs in git
is really nasty 8-)* ).

Interestingly, -B is not needed if you just put the desired version first
in your path. (I found that out trying 2.17/2.17.50 on an Ubuntu host
Isaac Dunham

*see github.com/idunham/srcs if you still dare.

Re: Building without -Wl,-Bsymbolic-functions

[Rich Felker]

On Sat, Aug 18, 2012 at 12:07:34PM -0400, idunham@lavabit.com wrote:
> > On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote:
> >>
> >> Hi!
> >>
> >> Im building musl inside an oldish uclibc environment based on uclibc
> >> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.
> >>
> >> The linker does not accept -Bsymbolic-functions.
> >>
> >> Im now building the shared library despite of this.
> >>
> >> How broken will the musl libc be without -Bsymbolic-functions ?
> >
> > If building without it entirely, the shared libc will just crash.
> >
> > If replacing it with -Bsymbolic, it will run, but global variables in
> > libc that are accessed by the application (e.g. environ, optind, ...)
> > will actually have separate copies in libc and the application, and
> > thus the app won't work as expected.
> Last I checked, ISTR it was "Illegal instruction" or segfault (even for
> hello world); I forget which was which, but both did not work at all.

The first function call in __dynlink will jump to an invalid address,
yielding SIGILL or bogus behavior if the address is valid and SIGSEGV
if it's not.

It might be possible to include a hack to avoid this problem by
putting __asm__ (".hidden funcname"); at file scope in dynlink.c for
each function that might be used by the dynamic linker, but if any of
those functions in turn depend on other functions, it won't be
sufficient. I see it as a fairly fragile hack, and I'd rather not go
there; requiring -Bsymbolic-functions ensures that everything will
work.

> > A patch to add -Bsymbolic-functions to old binutils would be very
> > welcome... In the mean time, you could compile a new ld and pass the
> > -B option to gcc to give it the path for the new ld.
> The patch isn't trivial to get right, but 2.17.50 (20070703) is a
> significant improvement in many other ways (a few code generation fixes
> among them)...
> I've built a tarball, but not really posted it publicly (tarballs in git
> is really nasty 8-)* ).
> 
> Interestingly, -B is not needed if you just put the desired version first
> in your path. (I found that out trying 2.17/2.17.50 on an Ubuntu host
> Isaac Dunham

Whether this works probably depends on how gcc is configured. For
example cross compilers will never get ld, etc. from the path; they'll
always use their configured directories.

Rich

Re: Building without -Wl,-Bsymbolic-functions

[Jens]

On Sat, 18 Aug 2012, Rich Felker wrote:

> On Sat, Aug 18, 2012 at 01:38:23PM +0200, Jens wrote:
>>
>> Hi!
>>
>> Im building musl inside an oldish uclibc environment based on uclibc
>> 0.9.30.1, gcc 4.1.2 and GNU ld version 2.17.
>>
>> The linker does not accept -Bsymbolic-functions.
>>
>> Im now building the shared library despite of this.
>>
>> How broken will the musl libc be without -Bsymbolic-functions ?
>
> If building without it entirely, the shared libc will just crash.
>
> If replacing it with -Bsymbolic, it will run, but global variables in
> libc that are accessed by the application (e.g. environ, optind, ...)
> will actually have separate copies in libc and the application, and
> thus the app won't work as expected.
>
> A patch to add -Bsymbolic-functions to old binutils would be very
> welcome... In the mean time, you could compile a new ld and pass the
> -B option to gcc to give it the path for the new ld.

Lots of enligthening information in answers to this question. Thank you!

I did as suggested and compiled a newer version of ld.
Compilation now works beautifully out of the box.

Thanks,
Jens

>
>
> Rich
>