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.
--
gentoo-dev@gentoo.org mailing list
