[fedora-arm] dietlibc port?

[Gordan Bobic]

On 01/06/2011 11:15 PM, Rich Mattes wrote:

>> 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.

Indeed, it is much safer and better insulated.

>>> 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.

No, my point is that the CC, CXX and CPP environment variables aren't 
getting set. This doesn't seem to get passed in by default and it is 
pretty important if a different compiler is to be used. The real problem 
here is lack of consistency. There are four cases:

1) CC variables get set from %__cc. This is the way all package spec 
files should do it, IMO.

2) CC variables don't get set at all. The build will hopefully default 
to gcc/cc, and it could be easily overriden by exporting the CC 
environment variable before running the build process. Great in theory, 
but since some packages set it, either to %__cc or hard-code it, not 
really a solution.

3) CC variables get hard-coded in the spec file. Almost the worst 
possible case. This really, REALLY should never happen.

4) CC variables get hard-coded in the build source. I don't even want to 
go there.

> 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.

bzip2 spec file sets CC to %__cc, which is, IMO, the correct thing to 
do. My point was that all package spec files should do this.

> 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.

This is what I am doing, but considering that I am planning to do this 
for most of the packages in the distribution, that's going to be a LOT 
of bugzilla reports. So many, in fact, that I wouldn't be surprised if 
someboy closes them as NOTABUG/WONTFIX because non-gcc compilers "aren't 
supported". I've had this "not supported" line used a justification for 
all sorts of horrible bodges in the distro, with the solution being 
"we'll document it's broken".

Gordan