RE: dlopen() returns undefined symbol for library w/ RTLD_LAZY

[Davidzeu <davidzeu at gmail dot com>]

guys,
i located the problem.

The problem was to do with the "libtool --mode=link g++ -export-dynamic "
flag missing in the main (main.exe) linkage. 
this "-export-dynamic" flag was not included in the makefile, because of
which the dynamic loading (dlopen) had the "undefined symbol" issue.

Now, after i add the '-export-dynamic' flag for the main.exe linkage, the
problem was solved.

It was because my teammate dint update this makefile entries when he ported
the code from the Solaris machine to the Linux machine.

Anyways, hope this will be of some help for someone who intends to port the
source code across the platforms.

Thanks Eljay.


--david




Davidzeu wrote:
> 
> 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-tp24621028p24640130.html
Sent from the gcc - Help mailing list archive at Nabble.com.