Re: Re: libgcc --disable-shared test case

[John Spencer <maillist-musl@barfooze.de>]

Rob Landley wrote:
> On 01/11/14 17:55, John Spencer wrote:
>> Rich Felker wrote:
>>> 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.
>>
>> that would be
>> https://github.com/sabotage-linux/sabotage/blob/36661440192e2ec51531ea81c7866578010f3283/KEEP/gcc-454-libgcc_hidden.patch 
>>
> 
> In 4.2 there is no libgcc/Makefile.in, instead there's a mklibgcc.in 
> generating the file. Given that it's generating a value and assigning it 
> to vis_hide a few lines earlier,

@vis_hide@ is some external stuff that passes in all function names or 
so. the makefile has some logic depending on --disable-shared to either
set vis_hide to all functions (@vis_hide@), or to nothing at all.
this patch here just sets vis_hide to them all unconditionally

> I have no idea if the suggested fix 
> (trying to pass through a value from autoconf?) is relevant to this 
> version of the code.
> 
> The real problem is I have no way to reproduce the failure yet. The 


you can just build libc.so with the new compiler and if it has any 
undefined symbols in it, it's broken (readelf -a)

a broken libc.so has stuff like this
2: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __muldc3
3: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __mulsc3
4: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __mulxc3


> comment that it occurs building musl for mips seems useful, I'll try 
> that. But it's kinda hard to fix a failure I've never seen fail...
> 
> Rob
>