* Building without -Wl,-Bsymbolic-functions @ 2012-08-18 11:38 Jens 2012-08-18 12:14 ` Rich Felker 0 siblings, 1 reply; 5+ messages in thread From: Jens @ 2012-08-18 11:38 UTC (permalink / raw) To: musl [-- 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building without -Wl,-Bsymbolic-functions 2012-08-18 11:38 Building without -Wl,-Bsymbolic-functions Jens @ 2012-08-18 12:14 ` Rich Felker 2012-08-18 16:07 ` idunham 2012-08-19 6:11 ` Jens 0 siblings, 2 replies; 5+ messages in thread From: Rich Felker @ 2012-08-18 12:14 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building without -Wl,-Bsymbolic-functions 2012-08-18 12:14 ` Rich Felker @ 2012-08-18 16:07 ` idunham 2012-08-18 19:40 ` Rich Felker 2012-08-19 6:11 ` Jens 1 sibling, 1 reply; 5+ messages in thread From: idunham @ 2012-08-18 16:07 UTC (permalink / raw) To: musl > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building without -Wl,-Bsymbolic-functions 2012-08-18 16:07 ` idunham @ 2012-08-18 19:40 ` Rich Felker 0 siblings, 0 replies; 5+ messages in thread From: Rich Felker @ 2012-08-18 19:40 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Building without -Wl,-Bsymbolic-functions 2012-08-18 12:14 ` Rich Felker 2012-08-18 16:07 ` idunham @ 2012-08-19 6:11 ` Jens 1 sibling, 0 replies; 5+ messages in thread From: Jens @ 2012-08-19 6:11 UTC (permalink / raw) To: musl 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-08-19 6:11 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-08-18 11:38 Building without -Wl,-Bsymbolic-functions Jens 2012-08-18 12:14 ` Rich Felker 2012-08-18 16:07 ` idunham 2012-08-18 19:40 ` Rich Felker 2012-08-19 6:11 ` Jens
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).