On Tue, May 28, 2002 at 03:12:18PM -0400, Michael Grabenstein wrote: > > On Friday, May 24, 2002, at 01:00 PM, Robert Schiele wrote: > > >On Fri, May 24, 2002 at 12:30:57PM -0400, Michael Grabenstein wrote: > >> Two guesses: > >>1) LD_LIBRARY_PATH needs to be set to include the correct > >libstdc++.so > >>( you must be finding an older copy). > > > >Huh? No! XMI2SSLHandler is not a class defined in libstdc++! > > > > > Because it happened to me... :-) I am not sure of the gcc version,
That might be true, but not everything is always the same. --- Or in other words: Do not project your problem to every problem, someone has around the whole world, as that problem might be completely unrelated. > but newer gcc compilers create shared libraries that are not binary > compatible with the dynamic loader functions of older gcc (older version > of libstdc++). So the problem does not have to be that the class is not > in the libstdc++, just that the libstdc++ you are using can not load the > desired class... It seems, you are completely misunderstanding things here. libstdc++ has nothing to do with the linker, it's nothing magic about it, it's just a library. And as neither the requested symbols, nor the objects requesting them are part of libstdc++, this is absolutely in _no_ way related to libstdc++. > >>Or > >>2) Your gcc was not compiled with "--enable-shared", with version 3 > > > >>and newer gcc this is default. Beneath version 3 it was not the > >>default... > > > >Why do you think so? No one forces you to use shared libraries. > > > But that is the way all the samples build and if you want to use > the Perl bindings you have to have a shared library... Aehm, but in what way is _that_ related to the error message he reported? He did not build a sample, nor did he do any Perl stuff. He just tried to link an object file, which I assume he or someone else has written. Robert -- Robert Schiele Tel.: +49-621-181-2583 Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED]
msg06644/pgp00000.pgp
Description: PGP signature
