Currently, gcc libraries are isolated in different directories, per gcc version (say /usr/lib64/gcc/x86_64-pc-linux-gnu/4.2.3). Why not put them together (eg. /usr/lib64/gcc/x86_64-pc-linux-gnu/lib/) like any unix library ? I don't see an inconvenient of doing that, do you ? Moreover, there are downsides of doing this kind of segregation. The biggest one is that you currently have 1 active "gcc profile", preventing links to other gcc versions, forcing "unnecessary" recompilation of stuff on upgrades even if the old gcc version isn't removed AFAIK, this change is not translated by many changes in the toolchain ebuilds, and is very helpful, in the sense that it avoids many breakages. I really hope (among many) that it will be considered, discussed, and eventually implemented !
I'm sure this would break far more things than having them separated apparently does. Not to mention all of the file collisions this would introduce. vapier: ?
But other libraries owned by slotted packages work fine with multiple active libraries in parallel. Why should libstdc++ be any different than these?
(In reply to comment #2) > But other libraries owned by slotted packages work fine with multiple active > libraries in parallel. Why should libstdc++ be any different than these? > Doing this for just the libraries makes sense. It wasn't clear to me in the initial report that this was the intent.
Yes I was only talking about libraries :)
Would this fix breaking my C++ apps every time I switch gcc compiler with gcc-config. I.e. stop errors like this: icemon: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by icemon)
i dont see the point of putting them in a different directory. you arent gaining anything. gcc-config should already order LDPATH according to increasing version ... if it isnt, then it's a bug
(In reply to comment #5) Yes, it most likely would. AFAIK, that error occurs when a program linked against one version of libstdc++ is forced to use a lower version. In Gentoo's case, this occurs because: a.) Only one version of libstdc++ is available at any given time b.) All versions have the same soname, rather than the name + 3-part version that most libraries have, causing the program to dlopen the incorrect version rather than complaining about a broken linkage
*** Bug 250720 has been marked as a duplicate of this bug. ***
Closing as per Mike's comment about how this shouldn't gain us anything. If there is a bug in gcc-config's handling of LDPATHs, file another bug for that.
