severity 101223 normal thanks I see your point. It's not a packaging bug, and after moving the v3 ABI .so and .a files to lib/gcc-lib/... it all works much better now.
I still think gcc should be changed to generate a commandline for collect2 that places -L$prefix/$gcclibdir before all other -L either specified or implied by various environment variables. Unless someone can give an example of when g++ 2.95.x would ever want to use a different libstdc++ than the one it was built with? It should always come first, or am I missing something? On Wed, Jul 04, 2001 at 01:17:22AM +0200, Matthias Klose wrote: > Gordon Sadler writes: > > Note below the order of the -L args. /usr/lib/gcc-lib/i386-linux/2.95.4 > > comes last... Shouldn't it be first? Maybe a change to the specs? It so > > happens I have gcc-3 and libstdc++-v3 installed in /usr/local, so I can > > compile this on a few ways: > > Ok, then gcc-2.95 picks the libstdc++.so (from gcc-3.0) from /usr/local and > cannot find the symbol because it's mangled in another way? > > This situation only occurs, if you have another libstdc++ in the link > path, that is not compatible with the linker used. So the error should > not occur, if you move the libstdc++.so (gcc-3.0's libstdc++) link > into the compiler specific libdir. Correct? > > I'd like to downgrade the report, because this is a situation that > does not exist with the Debian g++-2.95 and g++-3.0 packages. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Gordon Sadler
