I’m having an issue with a C++ application I’m writing. One of our components is compiled to a .so file which is then loaded using dlopen(). dlopen() fails, spewing out the following:
unknown symbol:
unknown symbol:
unknown symbol:
unknown symbol:
unknown symbol:
sercom_g.so is an invalid module: Unresolved symbols
(Note that the last line is a result of my application reporting the message from dlerror())
After doing some googling all tonight, I have come across this supposed linker issue that generates R_386_NONE relocations (I don’t really know what that means, but from what I read it sounds bad). Sure enough:
I’ve tried compiling with both the 3.3.5 and 4.2.3 tools, and both of them seem to be giving me the same problems. Is there anything else I should be trying to track this down? I really don’t understand the problem and where it’s originating from; consequently I don’t really know where to start to solve the issue.
Thanks for the suggestion. “export LD_DEBUG=1” seemed to do nothing, but DL_DEBUG produced what I assume is the expected output. If I am reading this correctly, it seems like there is an issue getting libcpp.so to link in, but I am unfamiliar with this output. Am I reading it correctly?
bash-2.05a# export DL_DEBUG=1
bash-2.05a# ./base_g
load_object: attempt load of libcpp.so.3
load_elf32: loaded lib at addr b8200000(text) b825d640(data)
dlopen("/root/sec09/modules/sercom_g.so",0)
load_object: attempt load of /root/sec09/modules/sercom_g.so
load_elf32: found DT_TEXTREL, mapping a private copy of text sections!
load_elf32: loaded lib at addr b8274000(text) b82ac860(data)
dlsym(8063330,_btext)=804fa74
Library loaded; type ‘add-sym sercom_g.so 804fa74’ in gdb to load symbols
load_object: attempt load of libcpp.so.4
load_elf32: loaded lib at addr b82b2000(text) b83010e0(data)
unknown symbol:
unknown symbol:
unknown symbol:
unknown symbol:
unknown symbol:
sercom_g.so is an invalid module: Unresolved symbols
I just realized that it says both “libcpp.so.3” and “libcpp.so.4” After some research, I have come to the conclusion that libcpp.so.3 should only be loaded by a program that was compiled using gcc 2.95 (which is inherently incompatibile, from what I am reading). Am I on the right track here?
I have double checked my settings, though, and everything in momentics says it is using 4.2.3 (admittedly the very first compile we did was with 2.95 but we left that recently in favor of 4.2.3’s new features).
Everything needs to be compiled by the same version of compiler. Note that 4.2.3 and the .so that come with it are as far as I know, not officially released, you could use 3.3.5.
I’m really at a loss now; I can’t see anything I’m doing out of the ordinary.
Mario, 3.3.5 shows the same problem. Furthermore, I’ve been using the same compiler on all of my projects every time (if I changed one, I changed them all and then did a clean and rebuild).
To be even more safe, I wiped the drive, reinstalled QNX/Momentics and imported the source files into new projects in a completely new folder. I didn’t install 4.2.3 this time, and simply compiled with 3.3.5. I see the same result.
I don’t really know where to go from here. Any advice would be great; and thanks for all the help you’ve given so far.
Thanks,
– Matthew P. Del Buono
EDIT: I would like to compile with 2.95 just to see what happens. Unfortunately, my code is not compatible with 2.95 due to a non-standard capability in it which was corrected sometime before 3.3.5.
EDIT2: My issue with 2.95 is that involving friends. To work around it temporarily, I made all members in the offending class public and commented out the friend declaration. I’m happy to report that upon doing this, all my problems are solved. The module gets opened by dlopen() without an issue. Unfortunately, this is not an acceptable solution; I need that friend declaration and to make these members private. Thus, I need to move onto 3.3.5. Is there any reason why I might still be linking to 2.95 libraries even though I definitely set the compiler to 3.3.5? Do I need to change anything?
You said you re-installed everything, but is it still trying to load libcpp.so.4. That wouldn’t be possible given that you don’t have 4.2.x installed anymore, it’s possible a copy of sercom_g.so , build with 4.x.x is somewhere in the LD path.