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.
- main1.cpp → main1.o via qcc -c . It externs one function that just
does a printf.
- 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.
- 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
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.
- main1.cpp → main1.o via qcc -c . It externs one function that just
does a printf.
- 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/
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
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.
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.