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@xxxxxxxxxx >> <mailto:gordan@xxxxxxxxxx>> 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
