Date: Sat, 11 Jan 2014 17:45:09 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Re: libgcc --disable-shared test case On Sat, Jan 11, 2014 at 04:38:36PM -0600, Rob Landley wrote: > On 01/11/14 16:23, Rich Felker wrote: > >On Sat, Jan 11, 2014 at 04:04:25PM -0600, Rob Landley wrote: > >If you want to see the issue manifest without replacing uclibc, the > >easiest way would be to check *which* libgcc symbols got pulled into > >libc.so.0, then modify the test code for libfoo.so to use a feature > >that will pull in one of the libgcc symbols not in libc. > > > >Rich > > My goal is to make it work, with a brick if necessary. This includes > making it all work under musl. > > I'm already patching the libgcc.a build to produce libgcc_eh.a at > inappropriate times and shoehorning in symbols that problably > shouldn't go in there. (And then ccwrap is shoehorning in > libgcc_eh.a when it pulls in libgcc.a.) > > My position on the --disable-shared gcc being subtly broken is that > it's a bug in gcc I should fix (at least until replacing one more > FSF project with something better). Generally if I can reproduce a > problem and get enough time to work on it, I can fix it. I just > wanted to make sure that my failure to reproduce this issue wasn't > because I subtly screwed up. :) The way to fix it is to find the conditional logic in the gcc build system (I forget whether it's in configure, the Makefiles, or the headers) that disables use of the visibility attribute when --disable-shared is passed, and simply dummy it out so that visibility is always used. At one point we discussed on IRC how this could be fixed at the GCC level, so I could probably dig something out of IRC logs if you want. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.