gcc-config version 1.3.13-r1 seems not to be compatible with a profile higher than 4.1.0. Supposing your current profile is gcc 4.2.0 and you want to set as a new profile a lower gcc release for instance 3.4.6, all your programs calling /lib/libgcc_s.so.1 will complain and will be unable to find the libstdc++.so.6 library, /lib/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0-alpha20060422/libstdc++.so.6 and of course will abort. That does affect python and all programs calling python, like env-update or portage tools e.g. emerge. So you are unable to emerge whatever program you want until you go back to the gcc 4.2.0 profile again (supposing the package is gcc 4.2.0 compatible ;)), otherwise you are stuck. As a workaround, you can set LD_LIBRARY_PATH to the gcc corresponding libstdc++.so library. For instance, export LD_LIBRARY_PATH=/usr/lib64/gcc/x86_64-pc-linux-gnu/3.4.6 after running gcc-config x86_64-pc-linux-gnu-3.4.6 That's really annoying ! Would it be worth the while emerging the last masked gcc-config 2.0 release in order to correct the problem or would it break the lot ? Thanks for your comments Jj
you cant reliably build things against gcc's C++ code version X and then try and use the library from version Y at runtime (where Y is older than X)
(In reply to comment #1) > you cant reliably build things against gcc's C++ code version X and then try > and use the library from version Y at runtime (where Y is older than X) Thank you for replying. Sorry if i didn't make myself clear, certainly because i misunderstood gcc-config features and goals, but please read it carefully. As you can guess, english speaking is not my mother tongue :). Sure, i understand your remark but in an other way, you can reliably build things with gcc's C++ code version X and then try and use the library from version Y at runtime (where X is older than Y). And that is exactly what doesn't work with gcc 4.2.x and portage tools using python (in my case compiled with an older version of gcc) when you try to compile a package with gcc 3.x for instance. It seems not really a compiler problem but rather an incompatibility with python library linkage (ld.so.conf ?) that affect portage in particular or perhaps a "simple" 4.2.x libgcc_s.so bug itself but it is not the object of the discussion. As far as i know 4.2 is backward compatible with older gcc releases, at least with the versions declared into /lib/libgcc_s.so (/lib/libgcc_s.so | grep GCC) and so libgcc_s.so should find the adequate library. Q:Why should i bother with older compiler ? A:Because some packages (without patches) are unable to be compiled with earlier gcc compilers. Q:How do i manage to make it work ? A:I set LD_LIBRARY_PATH manually to avoid /lib (ld.so.conf) The idea was to compile them with an older release of gcc and go back after a successful compilation to the last gcc release installed to make things consistent (via gcc-config command). In my case 4.2.x. The sources that i was able to compile successfully with an older compiler within a 4.2.X ready environment are working great, like other binaries ebuild e.g firefox-bin, ut2004, kernel modules, not necessarly compiled with one's latest compiler release... For a suggestion, it should be useful to get the choice to apply changes only to the current shell and set LD_LIBRARY_PATH to call the right gcc library path. Of course using a chrooted environment could do the same and even better, but we will fall into some sort of undescriptible dependency problems that are quiet more difficult to resolve if you don't have installed all the necessary dependencies earlier (waste of place and time!). I didn't really have an answer how to handle this but i tried to underline a feature (set LD_LIBRARY_PATH for example) that could help compiling some packages without to patch them again and again in order to meet them the requirement of the newest compiler... and i had hoped that gcc-config 2.x would integrate such feature :) PS: the most problem are programs like python calling libgcc_s.so. In that case, your are unable to call emerge in order to rescue your system! Thank you for your time, Jj
the best practice would be to disable c++ support in python (I do that for all of emerge -e system), the libgcc_s.so dependency is pulled by libstdc++.so you compiled gcc-4.2 and rebuilt python w/ it, so your libgcc_s.so (that is copied to /lib by gcc-config is the newest, now if you change to an older gcc everything using/needing libstdc++ from gcc-4.2 will fail, because the first libgcc_s.so found is the one from the older gcc.
gcc-config has been designed for per-session switching run: $ eval $(gcc-config -E 3.4.6) $ gcc foo.c now you can compile using 3.4.6 in the active shell without changing the system compiler
@Comment #1: yes that is exactly what appends. Disabling c++ support is a great idea. @comment #2: Great! i didn't thought to use eval and even PATH variable, convinced it could only be a LDPATH or LD_LIBRARY_PATH misconfiguration. Thank you for your advises, i will apply them right away and report if i found some strange behaviours :) Thx Jj
