[fedora-arm] dietlibc port?

[Rich Mattes]

On 1/6/2011 11:56 AM, Gordan Bobic wrote:
> Deliberately off-list?
>
No, sorry, more of a brainfart.  Too many email clients...
> Rich Mattes wrote:
>> On Thu, Jan 6, 2011 at 11:33 AM, Gordan Bobic <gordan at bobich.net 
>> <mailto:gordan at bobich.net>> wrote:
>>
>>     Andy Green wrote:
>> > On 01/06/11 16:17, Somebody in the thread at some point said:
>> >
>> > Hi -
>> >
>> >> Digging a bit more, it seems that bin-arm/diet segfaults when
>>     executed
>> >> without any parameters, so it seems that this is the bit that
>> >> miscompiled somewhere.
>> >
>> > Did you try running it in gdb and get a clue about what blows?
>>
>>     Not yet, no.
>>
>> >> It turns out that the problem is actually to do witha GCC bug.
>>     When it
>> >> is building bin-arm/diet with -Ox (x = {s,2,3}) , the resulting
>>     binary
>> >> segfaults. When the binary is built with -O1 or -O0, it works fine.
>> >
>> > Is there a particular gcc bug you traced it down to?  Because it does
>> > not follow that all changes to program behaviour with different
>> > optimization options are necessarily gcc bugs; it can show up
>> > broken-ness in code that happens to not show symptoms according
>>     to how
>> > it is compiled.
>>
>>     That's fair, but an awful lot seems to break. If dietlibc really 
>> is that
>>     broken, I have to question how it ever worked for anyone 
>> reliably. I'm
>>     also wondering if it might be some of the Fedora patches that are
>>     breaking it. I'll try it without any post-0.32 patches.
>>
>> You should also probably try the F13 gcc.  Bugs reported against the 
>> F12 gcc are going to be ignored, since nobody is working on any F12 
>> stuff anymore.
>
> I am slowly shifting things over to F13, but there is a lot to DIY 
> build. For example, things like Firefox don't work because of an API 
> version mismatch with xulrunner. And it helps to have a relatively 
> usable system to do development on. :)
>
> Besides, the reason I need dietlibc is because util-vserver requires 
> it and I want to work on F13 stuff  in a vserver chroot in order to 
> ensure that the host system remains operational even if I badly break 
> important low-level things.
>
Ah, I see.  I've just been using a plain chroot into the f13 rootfs with 
/proc bind mounted to the rootfs /proc, but it looks like vserver has 
some more features.

>> If it helps, you should be able to override the CFLAGS and CXXFLAGS 
>> in the dietlibc specfile before calling make in order to lower the 
>> optimization level.
>
> The problem with that is two-fold:
>
> 1) It seems a lot (most?) of spec files don't actually set CC, CXX, 
> CPP, CFLAGS, CXXFLAGS, etc. accordoing to the rpmrc. I'm currently in 
> the process of going through most of the packages in RHEL6 (building 
> for x86 using ICC for a bit of extra speed) and F12/F13 (to build the 
> missing ones for the ARM port), and it seems that this happens all 
> over the place, and inconsistently to boot. For example, bzip2 sets 
> the variables according to rpmrc, but gzip doesn't. It is really 
> frustrating to find that the package management functionality is 
> ignored so frequently.
>
> 2) Ironically, having said 1), it seems that dietlibc introduces it's 
> optimization flags of -Os/-O2 _regardless_ of what the CFLAGS in the 
> environment says. I haven't checked the patches in the src.rpm yet, 
> but it is _probably_ coming from the upstream tar ball. Which is not 
> good, because it means chasing such dubious Makefile behaviour 
> upstream with developers who think "they know better" because "it 
> works for them".
>
> Gordan
The %configure macro is where the flags are set.  You can run rpm --eval 
%configure to see what's going on there.  It looks like the CPPFLAGS 
exported in gzip are in addition to the default CPPFLAGS, which are 
appended when %configure is called.  As for the bzip2 spec, it looks 
like there isn't a configure script, so the maintainer had to manually 
set all the variables that %configure would have taken care of.  I guess 
bzip2 is actually the anomaly here.

As for -O2 and -Os slipping in, you'll have to patch or sed them out.  A 
lot of the time upstream will hard code flags, but since -O2 is the 
Fedora default nobody really removes them when they pop up.  -O2 only 
appears in about 7 files, so it shouldn't be too hard to eliminate.

Rich