This has been raised as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22499 upstream, but Pinski's reply is (in part) correct: Gentoo is probably doing things slightly wrong :-) Directories are currently configured as: --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050723 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050723/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050723 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050723/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050723/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050723 Pinski points out that --enable-version-specific-runtime-libs overrides most of the other settings in 4.1. However, even if you drop this option, the installation still doesn't work (for g++ STL stuff, anyway): the shared libraries are put into: /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0 not /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0-beta20050723 as you expect/want. I have found that you need to also add: --libexecdir=/usr/libexec/gcc/i686-pc-linux-gnu/4.1.0-beta20050723 --libdir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050723 I'm going to try to push the upstream bug a little more - this new set of options results in the creation of: /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0-beta20050723/gcc/i686-pc-linux-gnu/4.1.0 and /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050723/gcc/i686-pc-linux-gnu/4.1.0 due to the way some of the install targets are set up in vanialla gcc... Phil
punted that config option
Erm, this doesn't fix the problem. With 4.1.0_beta20050819 the installation still leaves files in: /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0 and /usr/lib/gcc/i686-pc-linux-gnu/4.1.0 This is because libexecdir and libdir aren't being set (see comment #1). Phil -- snip log -- * PREFIX: /usr * BINPATH: /usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050819 * LIBPATH: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819 * DATAPATH: /usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819 * STDCXX_INCDIR: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4 * Configuring GCC with: --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050819 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4 [...other non-dir settings...] It may claim LIBPATH is correct, but it doesn't seem to configure (correctly) using it...
the problem with --libdir and say gcc 3.3 or gcc 3.4 is that the files are installed into paths like /usr/libexec/gcc/i686-pc-linux-gnu/3.4.4/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
Yes, and the same is true of (some of) the files in 4.1.x. I pointed this out upstream and frankly didn't feel that I got a particularly satisfactory response, but the answer is basically "that's what it should do", and was referred to the info page. (Which didn't actually say anything *that* specific, just that the stuff would go under the directory specified, which it is.) I'm *really* not convinced that it is, but I gave up trying to progress it after the report was closed as INVALID. I've looked at the Makefile's and I can't see any way (via configure) of stopping 4.1.0 from installing into a directory called 4.1.0 at some point. Personally, I think the Makefile's are wrong, but see previous paragraphs :-( Phil The current ebuild for gcc 4.1.0 results in (libstdc++ is in /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/): pgr letters $ g++ -v a.cc -o a Using built-in specs. Target: i686-pc-linux-gnu Configured with: /usr/src/tmp/portage/gcc-4.1.0_beta20050819/work/gcc-4.1-20050819/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050819 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050819/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++,f95 --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 4.1.0 20050819 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -quiet -v -D_GNU_SOURCE a.cc -quiet -dumpbase a.cc -mtune=pentiumpro -auxbase a -version -o /tmp/ccOMk5S8.s ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4 /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050819/include/g++-v4/backward /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/include /usr/include End of search list. GNU C++ version 4.1.0 20050819 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.1.0 20050819 (experimental). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=129176 Compiler executable checksum: 8d4249cf38a9e91d1ce3bbf1e4d1b540 /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/ccdKk14c.o /tmp/ccOMk5S8.s GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o a /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/ccdKk14c.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../crtn.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status
confirming. i found this after noticing that c++ code compiled with a 4.0 snapshot was linking against libstdc++ from a 3.3 snapshot (3.3.5.20050130 or whichever). after removing 3.3 from the system i couldn't compile anything that linked with -lstdc++. this appears in any testing snapshot ebuild of gcc but not the release versions in the portage tree, because in the release versions the gcc BASE_VER and the ebuild's $PV are the same so everything ends up in the same subdir.
Maybe that's a stupid question, but what can we do?? I experience the same problems, so I'm not able to compile ncurses-5.4.20050827 for example. Another question: why ist gcc downgraded?? This is my configuration at the moment: gcc-config -c i686-pc-linux-gnu-4.1.0-beta20050902 This is what emerge -uDp world will do: emerge -p gcc These are the packages that I would merge, in order: Calculating dependencies ...done! <-------snip----------> [ebuild NS ] sys-devel/gcc-4.0.1 So, in this case gcc would be downgraded from 4.1.0-beta to 4.0.2? If I'm wrong could anybody explain this to me, please?
Because I removed the gcc-4.1 ebuilds from the tree. I really never should have put them in the tree to begin with. If you want to use gcc-4.1 (which is currently still too unstable to do anything useful with except debug gcc, imho), then you can maintain the ebuild in your overlay. Once gcc-4.1's first rc comes out, I'll put it back in the tree.
Not that I really mind about gcc 4.1 snapshots being in portage (I build them locally anyway), but... Upstream don't believe that the current installation behaviour is a bug - it is unlikely that this is going to change before 4.1beta comes out (or after, if you believe upstreams response to my gcc bug report). Anyway, I'll just wait for everything to get fixed somewhere :-)
i think in order to fix this we'd have to mung the version in gcc.c / build files
(In reply to comment #9) > i think in order to fix this we'd have to mung the version in gcc.c / build files It looks like if we just put ${P} into ${S}/gcc/BASE-VER it will install everything correctly. The `gcc -v` output then will look like this: gcc version 4.1.0-beta20051029 20051026 (experimental) If we really wanted, we could probably just erase everything in ${S}/gcc/DATESTAMP if it bothered us that much :)
i'd say do both ... destroy both BASE-VER and DATESTAMP
Alright, should be fixed in the tree. Thanks.
