The ebuild of gcc tries to run a script that it does not install, and this fails on my system. Perhaps this is because I have buildpkg set in FEATURES? Whatever the cause, here are the errors: cp: cannot stat `/var/tmp/portage-pkg/gcc-3.2.2/inf/files/fix_libtool_files.sh': No such file or directory chmod: failed to get attributes of `/var/tmp/portage/gcc-3.2.2/temp/fix_libtool_files.sh': No such file or directory /usr/sbin/ebuild.sh: line 498: /var/tmp/portage/gcc-3.2.2/temp/fix_libtool_files.sh: No such file or directory There is another failure mode for any system that uses the binary package that was created. It is not as noisy, but it is just as broken. Since there is nothing that creates the .oldgccversion file in the install part of the ebuild, the code that runs fix_libtool_files.sh is silently skipped. I'd suggest changing the post-install section to figure out the old GCC version for itself (perhaps by looking in the .la files?) instead of relying on the .oldgccversion kludge. Then, change the ebuild to install the fix_libtool_files.sh script as a part of the package so that the post-install section can run it when binary packages are built/used.
Nick ... the $T weirdness I asked you about the other day ...
Ok, I did some changes to try and prevent this in future: ---------------------- 09 Mar 2003; Martin Schlemmer <azarah@gentoo.org> gcc-3.2.2*.ebuild : Fix handling of fix_libtool_files.sh to be more $FILESDIR independant. We basically install it to /sbin now, and then call it from there. Also export LD_LIBRARY_PATH with new gcc library path in it to prevent gcc-config from borking when run. This will hopefully fix bugs #15288, #16632, #16797.
closing as fixed
