Simon Strandman skrev:
R Hill skrev:
Simon Strandman wrote:
It seems like toolchain.eclass does something wrong when configuring
gcc 4.1 snapshots. I decided to try gcc 4.1 on my server so I
created a gcc-4.1.1.20060324 ebuild and defined the SNAPSHOT
variable in it (current cvs has a lot of bugfixes since the
release). This is the way I've done it with gcc 4.0 and I never had
any problems then. The ebuild emerges without problems but it
installs files in both /usr/lib/gcc/i686-pc-linux-gnu/4.1.1-20060324
and /usr/lib/gcc/i686-pc-linux-gnu/4.1.1. So when I try to emerge
anything it always fails with errors like this:
configure:2239: i686-pc-linux-gnu-gcc -O2 -march=pentium3 -pipe
-fomit-frame-pointer -D_FORTIFY_SOURCE=1 conftest.c >&5
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld:
cannot find -lgcc_s
collect2: ld returned 1 exit status
Just copying over the files from one dir to the other and then
symlinking it works around the problems. Any ideas?
This is caused by changes to the build system in 4.1 and GCC's
BASE-VER not matching portage's ${PV} in snapshot builds. Most of
the system directories are set up by portage during configure using
${PV} as part of the dirname. (eg.
includedir=/usr/<lib>/gcc/<chost>/${PV}/include). However, libdir
and libexecdir aren't set by portage (because they generate really
strange paths w/ --enable-version-specific-runtime-libs in GCC
3.3/3.4) and default to /usr/<lib>/gcc/<chost>/BASE-VER/blah. When
${PV} != BASE-VER, wackiness ensues.
Try this in your ebuild:
src_unpack() {
toolchain_src_unpack
echo ${PV/_/-} > "${S}"/gcc/BASE-VER
echo "" > "${S}"/gcc/DATESTAMP
}
--de.
Thanks for the help! But now it fails with this error:
<built-in>:1: internal compiler error: in define__GNUC__, at
c-cppbuiltin.c:296
Please submit a full bug report,
This has been reported in gcc bug #19372 and apperantly it has
something to do with the version string. :(
I opened a bug about it:
http://bugs.gentoo.org/show_bug.cgi?id=127724
--
gentoo-dev@gentoo.org mailing list
