unknown relocation type

bridged with qdn.public.devtools
Post Reply
Ryan Carmichael

unknown relocation type

Post by Ryan Carmichael » Mon Jul 07, 2003 8:44 pm

Has anyone ever seen this error before? I have a simple example that works
fine under Linux but gives me the above error under QNX. I could post the
contents of the source files (3 files, one function, 1 line each) but it is
probably easy enough just to describe it.

1. main1.cpp -> main1.o via qcc -c . It externs one function that just
does a printf.
2. main2.cpp -> main2.so via qcc -shared -o main2.so main2.cpp main1.o .
Here the shared object is created and all it does is extern a function that
calls the simple function in main1.o.
3. main3.cpp -> main3.out via qcc -o main3.out main3.cpp main2.so which
just calls the function exported by the .so.

They are all compiled with -Vgcc_ntoarmle_cpp. Everything compiles fine,
the "Unknown relocation type" occurs at runtime followed by a SIGSEGV.

If I skip step 1 and compile the main1.cpp source directly into the shared
object, everything works just fine. But that is not a viable solution for
other reasons. I really just don't understand why this isn't working in
QNX - apparently I'm breaking some rule that Linux is more leniant about.

Thanks,
Ryan Carmichael

Chris McKillop

Re: unknown relocation type

Post by Chris McKillop » Tue Jul 08, 2003 12:27 am

Ryan Carmichael <ryan.carmichael@dynetics.com> wrote:
Has anyone ever seen this error before? I have a simple example that works
fine under Linux but gives me the above error under QNX. I could post the
contents of the source files (3 files, one function, 1 line each) but it is
probably easy enough just to describe it.

1. main1.cpp -> main1.o via qcc -c . It externs one function that just
does a printf.
2. main2.cpp -> main2.so via qcc -shared -o main2.so main2.cpp main1.o .
Here the shared object is created and all it does is extern a function that
calls the simple function in main1.o.
You have to compile main1.cpp with -shared or -fPIC. QNX doesn't support
non PIC shared libs.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Ryan Carmichael

Re: unknown relocation type

Post by Ryan Carmichael » Tue Jul 08, 2003 1:13 pm

You have to compile main1.cpp with -shared or -fPIC. QNX doesn't support
non PIC shared libs.
Ah, you're right, if I compile main1.o with -fPIC, everything works great.

Unfortunately, the problem is that that was just a small example - I'm
really using a xxx.o that another company has compiled and sent, I don't
have the source code for it. Maybe I can get them to create it with -fPIC
for me and resend it, if there's no other solution.

Thanks!

Ryan

David Gibbs

Re: unknown relocation type

Post by David Gibbs » Tue Jul 08, 2003 5:48 pm

Ryan Carmichael <ryan.carmichael@dynetics.com> wrote:
You have to compile main1.cpp with -shared or -fPIC. QNX doesn't support
non PIC shared libs.

Ah, you're right, if I compile main1.o with -fPIC, everything works great.

Unfortunately, the problem is that that was just a small example - I'm
really using a xxx.o that another company has compiled and sent, I don't
have the source code for it. Maybe I can get them to create it with -fPIC
for me and resend it, if there's no other solution.
Possible solution -- don't put xxx.o in your shared object?

Just put your functions in, put xxx.o in a libxxx.a, then link your
application against your .so and their xxx.o by way of libxxx.a?

(I haven't tried it, but I think that should work.)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Ryan Carmichael

Re: unknown relocation type

Post by Ryan Carmichael » Wed Jul 09, 2003 7:51 pm

David,

What you suggested probably would work. I was lucky enough, however, to get
the authors of this .o to recreate it using -fPIC, and things are great.
Thanks for everyone's help.

Ryan

"David Gibbs" <dagibbs@qnx.com> wrote in message
news:bef04q$mf6$2@nntp.qnx.com...
Possible solution -- don't put xxx.o in your shared object?

Just put your functions in, put xxx.o in a libxxx.a, then link your
application against your .so and their xxx.o by way of libxxx.a?

(I haven't tried it, but I think that should work.)

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.devtools”