Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Community/Discussion/QNX Momentics Community Support/R_386_NONE relocations and "Unknown Symbol" errors/List of Posts
Forum Topic - R_386_NONE relocations and "Unknown Symbol" errors: (8 Items)
   
Update
Matthew Del Buono
08/27/2008 7:13 PM
post12519
R_386_NONE relocations and "Unknown Symbol" errors   
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
Ryan Mansfield(deleted)
08/28/2008 9:42 AM
post12533
Re: R_386_NONE relocations and "Unknown Symbol" errors   
Matthew Del Buono wrote:
> As you can see both libcpp.so.3 and libcpp.so.4 are showing up. This doesn't seem correct to me.

Use either -Wl,-t or -W,--verbose to see how libcpp.so.3 gets linked in. 
  If you are compiling everything with 3.3.5, libcpp.so.3 should 
definitely not be there, and it will cause serious problems.

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

First, resolve the issue of linking in libcpp.so.3 and then check to 
make sure you are not linking in non-PIC code into your shared object.

Regards,

Ryan Mansfield
Colin Burgess(deleted)
08/28/2008 9:47 AM
post12534
Re: R_386_NONE relocations and "Unknown Symbol" errors   
This looks like a mix of 2.95.3 and 3.3.5 objects.  The base executable loads libcpp.so.3,
and the load of the dll loads libcpp.so.4

You can't safely mix C++ objects that were compiled with different versions of the compiler.

Ryan Mansfield wrote:
> Matthew Del Buono wrote:
>> As you can see both libcpp.so.3 and libcpp.so.4 are showing up. This doesn't seem correct to me.
> 
> Use either -Wl,-t or -W,--verbose to see how libcpp.so.3 gets linked in. 
>   If you are compiling everything with 3.3.5, libcpp.so.3 should 
> definitely not be there, and it will cause serious problems.
> 
>> Any suggestions would be greatly appreciated, because as it stands right now we don't know how to proceed.
> 
> First, resolve the issue of linking in libcpp.so.3 and then check to 
> make sure you are not linking in non-PIC code into your shared object.
> 
> Regards,
> 
> Ryan Mansfield
> 
> _______________________________________________
> QNX Momentics Community Support
> http://community.qnx.com/sf/go/post12533
> 

-- 
cburgess@qnx.com
Matthew Del Buono
08/28/2008 11:16 PM
post12590
Re: R_386_NONE relocations and "Unknown Symbol" errors   
> You can't safely mix C++ objects that were compiled with different versions of
>  the compiler.

I'm aware of that. Unfortunately, I don't see why there would be different versions. In Momentics, as far as I can see, 
all of them have the same version of the compiler selected.

I have installed now 4.2.1 and binutils 2.17 to try once more.  I then ran this line off a suggestion from another post 
to replace all of the base things with the 2.17 versions in hopes that this might be a problem, but I have had no effect
:

bash-2.05a# for file in `ls ntox86-*-2.17`; do cp -f $file `echo $file | sed 's/ntox86\-\([^-]*\)\-2.17/i386-pc-nto-qnx6
.3.0-\1/g'`; done

I should explain my project, probably. I have 4 components right now: The main application (called base), a module 
(called sercom), and two static libraries (called util and serlib).

serlib is linked into sercom, and util is linked into base, sercom, and serlib. (Hint: Is it possible that the fact that
 util links into serlib and then into sercom is a problem?).

Anyway, attached is the output from adding -Wl,-t as you recommended. I don't see any indicaton of using the 2.95 tools,
 etc. Do you? I split them up into 4 text files for easier viewing.

One thing I DID notice is that "util" and "serlib" did not seem to be listening to the -Wl,-t option; I don't see it 
used at all in the command lines. I put it under the "linker" options in momentics for the projects -- is this correct? 
I thought it was, but I don't see it used anywhere.
Attachment: Text base.txt 3.65 KB
Matthew Del Buono
08/28/2008 11:17 PM
post12591
Re: R_386_NONE relocations and "Unknown Symbol" errors   
This is the output from sercom's build (Sorry for all the posts, but I can only attach one file at a time)
Attachment: Text sercom.txt 4.68 KB
Matthew Del Buono
08/28/2008 11:17 PM
post12592
Re: R_386_NONE relocations and "Unknown Symbol" errors   
This is the output from serlib's build. Note that -Wl,-t does not show up anywhere in the build.
Attachment: Text serlib.txt 3.28 KB
Matthew Del Buono
08/28/2008 11:18 PM
post12593
Re: R_386_NONE relocations and "Unknown Symbol" errors   
This is the output from util's build. Again, note the lack of -t being passed to the linker.
Attachment: Text util.txt 2.15 KB
Matthew Del Buono
08/28/2008 11:52 PM
post12594
Re: R_386_NONE relocations and "Unknown Symbol" errors   
Sorry for the sudden spam of posts. I seem to have found an (if not /the/) issue. As I mentioned earlier, I found it 
quite strange that "serlib" and "util" were not listening to my linker settings.

I changed "serlib" and "util" to be "shared library without export" instead. After the appropriate modifications to the 
projects to account for this change, I am very happy to say that everything seems to be working OK.

This does, however, bring up an issue: I am perfectly OK with using this form instead of a static library, but why 
exactly can't I use a static library? This seems out of whack to me.

Anyway, thanks for the prodding in the right direction. Hopefully this will be the end of this little nightmare (with 
many more to come :D)

Thanks,
-- Matthew P. Del Buono

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems