Hi Eljay, thank you for the prompt response. Actually, the 'main.exe' and the 'libtest.so' library both are developed in C++. And when I faced the undefined symbol problem, the first thing I did was the 'nm' and checked the dump. As I told you guys, library module(libtest.so) that was compiled with GCC 3.2.2 was working fine. So what I did was, just took a 'nm' dump of the library module(libtest.so) that was compiled GCC 3.2.2 version and the one with GCC 3.2.3. And then I did a 'vimdiff' to find out the difference in the 'nm' dumps of those two versions. Guess what, there was no change in the symbol naming in those two. the only difference was the following, the section of the 'nm' the one which was compiled the one compiled with with GCC 3.2.3 Gcc 3.2.2 U snprintf@@GLIBC_2.0 | U snprintf@@GLIBC_2.0 U sprintf@@GLIBC_2.0 | U sprintf@@GLIBC_2.0 U sscanf@@GLIBC_2.0 | U sscanf@@GLIBC_2.0 U strcmp@@GLIBC_2.0 | U strcmp@@GLIBC_2.0 U strcpy@@GLIBC_2.0 | --------------------------------------------------------- U strncpy@@GLIBC_2.0 | U strncpy@@GLIBC_2.0 U strscpy | U strscpy U strsncpy | U strsncpy U __strtod_internal@@GLIBC_2.0| U __strtod_internal@@GLIBC_2.0 And the symbol for which the undefined symbol error came, comes only after this particular section in the 'nm' output. So, from the 'nm' i could only understand in the GCC version 3.2.3, the U strcpy@@GLIBC_2.0 symbol added with elements. But I still dont know why there is any change in the symbol orders, when i dint make a single line of change in the source code. The only difference is the GCC version. but it should not be of much difference as the GCCs differ with only the minor version change (3.2.2 to 3.2.3). And, i feel that i am missing some compilation flags or something during the library module compilation. someone helpppp me.. --david ------------- John (Eljay) Love-Jensen wrote: > > Hi David, > > When I run into undefined symbol problems, the first thing I do is make > sure the symbol is where I think it is. > > Use the 'nm' tool to get a dump of where (and what) you expect the symbol > to be. > > It may be something as simple as looking for "Foo", but the C symbol is > "_Foo" on this other platform. That's "C mangling" on some platforms. > > Or it may be something more drastic as looking for "Foo", but the C++ > symbol is "_S3FooCCpC" mangled which could stand for "Foo(char, char, > char*)" -- and that mangled symbol should be (and is expected to be) C > mangled not C++ mangled. > > HTH, > --Eljay > > -- View this message in context: http://www.nabble.com/dlopen%28%29-returns-undefined-symbol-for-library-w--RTLD_LAZY-tp24621028p24637603.html Sent from the gcc - Help mailing list archive at Nabble.com.