[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
