Hello everyone,

I'm working on a modular C++ program which loads its components via dlopen(). We've recently run into an issue and we 
don't really know where to go from here, unfortunately.

Point #1: We can't use GCC 2.95 because of a compiler issue (it does not handle something in the language per standard).
 We can work around this issue, but the workaround is to make all members of one of our classes public, which we believe
 is not a real solution.

Point #2: We have GCC 3.3.5 (and recently 4.2.3) but both of them are giving us issues at runtime.

Everything goes smoothly until we reach dlopen() and try to open our shared object file. At this point, we see this:

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 actually output by the application calling dlopen() as it detects the failure and then 
outputs the return from dlerror()).

After a lot of research last night, we came across this linker issue between 2.95 and 3.3.5 resulting in R_386_NONE 
relocations. Now in all honesty, I have no idea what that actually means, but everything I read makes it sound bad. Sure
 enough:

bash-2.05a# ntox86-readelf -r ./sercom_g.so | grep R_386_NONE
00000000 00000000 R_386_NONE
00000000 00000000 R_386_NONE
00000000 00000000 R_386_NONE
00000000 00000000 R_386_NONE
00000000 00000000 R_386_NONE 

These go away when we use our workaround and compile for 2.95. We have rechecked the compiler tools to ensure that all 
components are being compiled with 3.3.5 (and then later 4.2.3) several times, and have gone as far as reinstalling QNX 
on the target and trying all over, but we still see the same result.

Does anyone have any suggestions on how to proceed? I don't see any reason why it should be loading in the libraries 
from 2.95, however I noticed the following earlier (I read that libcpp.so.3 is for 2.95-compiled applications, thus 
should not be here:)

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 

As you can see both libcpp.so.3 and libcpp.so.4 are showing up. This doesn't seem correct to me.

Any suggestions would be greatly appreciated, because as it stands right now we don't know how to proceed.

Thanks,
-- Matthew P. Del Buono