Please point this in eradicator's direction... schwartz ~ # gcc i686-pc-linux-gnu-gcc: no input files schwartz ~ # CHOST=powerpc-apple-linux-uclibc gcc powerpc-apple-linux-uclibc-gcc: no input files I'm not sure if this was a deliberate decision or not. It seems like a nice idea in theory but it's not working out for me in practise. Most of my cross-builds are now failing with "Cannot execute binary file." I suspect the intended behaviour was to execute the gcc for the native CTARGET. I could have a go at fixing this myself later but I've got to get back to work right now!
Hmmm looking at the source, I now see that it was a deliberate decision. What would be the "right" way to do this then?
I guess I should clarify. As far as I understand it, this behaviour would work for any package that does not need to run anything that gets built at compile-time and most packages that use autotools (but those would work anyway). I recently wrote some wrapper scripts that did the same thing, as well as some other clever tricks. Portage doesn't let you set your own PATH so I used distcc in FEATURES to run the scripts from /usr/lib/distcc/bin. As such, the scripts could be turned on and off. Your wrapper, however, doesn't seem to have any way of turning it off and hence I can't cross-build things like uclibc or linux-headers. I tried to tackle the problem of running compile-time built binaries by allowing you to specify the names of any such binaries in an env called BUILDBINS. If it detects one of these binaries alongside the -o option, it builds using the native compiler instead of the cross compiler. This obviously won't work in all cases but I figured it was better than nothing. It works with mplayer, for example.
Use ${CHOST}-gcc for your compiling needs. Using 'gcc' by default will guess the CHOST from envvar, and if it's not set, it'll fall back on the default. This was left in there because not all of the ebuilds use the correct compiler and just use 'gcc'. Let me know if you have any further questions about this. Feel free to jsut email me.
After getting an email from the submitter, I've decided to change the behavior to ignor the envvar. This is more correct in my mind, and the use of the envvar was there to help make broken packages work properly, but instead it makes working packages not in cross-compilation environments. This will be changed in the next release (probably in a week or so... I want to give time for more possible bugs to come in).
Actually, I decided to push this out sooner rather than waiting since there was another I wanted to address at the same time and this'll clear up all the known bugs. The ebuild is ready and I'm just waiting for the tarball to hit mirrors.
