CFLAGS are quite completely discarded chen compiling portage package. The is problem is that I'm trying to build a Gentoo base system on an embedded PowerPC CPU (IBM 4xx) with no FPU. Because it's an embedded target with a tiny CPU and a few megs of RAM, I need the kernel to be as small as possible. So, need not to waste a lot of kernel space and CPU time using the kernel floating point emulation (it's about 5% of the kernel code size, in my case, and that's a lot in this environment, as kernel code can't be swapped...) So, it would be really great that all packages can be compiled with -msoft-float. If not, even if the code does not use floats, the gcc library does and gcc makes optimisations using floats (for example 64 bits load/stores using float registers, on PPC) and generates floats registers stores before calling some functions. For portage, I can see that the libsandbox uses some float instructions. Could it be possible then to respect the -msoft-float flag to solve this issue ? Reproducible: Always Steps to Reproduce: 1. 2. 3.
Are you actually going to be running portage on this embedded device? If you are, that's crazy. If not, why does it matter what CFLAGS libsandbox is compiled with?
That's exactly what I'm doing. It can take weeks, I don't care, but I just have to say that the CPU is a 252 Mhz one and that it's not what we can call a slow one... For now, I'm running a kernel with the floating-point emulation compiled in and I'm trying to bootstrap a generic PPC stage1 to get a really usable environment. And I will _never_ get a usable environment, even if I bootstrap it on another PPC machine, if there still are float instructions in the code. So, whatever the method I use to create the image, I need to be sure that everything is compiled with -msoft-float. If I'm trying to install a Gentoo environment on this machine, it's especially because I want to be able to compile and install some programs I want to test easily, so I really need portage to be fully usable. As I said, compilation time is not a real problem, as long as the resulting programs are able to run well.
Instead of the portage maintainers undoing something that was obviously done for a reason (make CFLAGS="-O1 -pipe" || die), why don't you just edit your local copy of the portage ebuild and add '-msoft-float' to the relevant line?
That's what I've done on my machine. And what I'll do is change gcc specs so those flags will always be used, even if not put on the command line. But I think it's a real problem, as there is a Gentoo embedded target, if it can't be ran properly on actual embedded hardwares... It's a generic problem, as most embedded CPUs don't have the full features from the CPU family they belong to available. So, you always can discard optimisation flags but you should never discards flags that indicates the CPU has less features than gcc default configuration. If the build system is not aware of this, Gentoo won't run on most embedded systems.
Afaik, most people don't run a full Gentoo system including portage on their embedded device. They use portage on a normal system to install packages into a chroot and then copy the resulting chroot to their embedded device.
This is not the real problem. As I said before, if the build system allow CFLAGS to be changed in a random way in the ebuilds, you won't be able to have a runable system for most embedded targets. -msoft-float and libsandbox are the example I just encountered, but the problem is really deeper: how can you compile a runnable system on a CPU that absolutelly need special compilation flags (like most embedded CPU do) because they do not implement the whole instruction set if some ebuilds discard the needed flags ? You can say "edit all problematics ebuilds", this is all right for someone like that know quite well the portage build system and the CPU I want to run on, but you can never say that to someone who wants to try the Gentoo system on a new platform, for example. If you want the Gentoo build system (which is really great, I know this and that's why I want to use it for my tests) to be used as a professional tool, it has to take care of "details" like this. I don't say "I want it now", I just say it has to be put somewhere on a TODO list and kept in mind for future improvments.
flag-o-matic already lists soft-float as an acceptable flag file bugs against specific packages that dont respect CFLAGS
