View topic - Shared Libs don't build from multiple files ?

Shared Libs don't build from multiple files ?

anything that doesn't fit to other groups.

Shared Libs don't build from multiple files ?

Postby bjchip » Thu Sep 09, 2004 5:53 am

We have a fairly complex system which, when building requires that we create shared libraries (.so) from two or more source or .o files (we've tried this many ways). Building a .a archive to work from doesn't work either.

In all cases of multiple files, symbols are lost in the .so files. We have problems with QCC and with g++ so it is a pretty deep rooted problem.

uinterface_cmd.so :uinterface_cmd.o cmd_interface.o
$(CXX) -shared $@ $^ $(LIBDEST) -lrlib

This leaves us with missing symbols which are plainly in the .o files and which disappear from the .so files. We also see, in some build variations, the .o files don't even get included in the .so, they are "NEEDED" as reported by the objdump.

We are really puzzled here. Anyone with any suggestions?

Thanks
BJ
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Postby rick » Thu Sep 09, 2004 3:16 pm

Off the top of my head, don't you need a -o flag when you create the shared object? ie:
$(CXX) -shared -o $@ $^ $(LIBDEST) -lrlib

Rick..
rick
QNX Master
 
Posts: 500
Joined: Wed Nov 13, 2002 3:59 am

Postby bjchip » Thu Sep 09, 2004 9:40 pm

Sorry

My bad, the -o is there too. Matter of fact, if you can think of a compile option we've probably tried it already, but I am hoping to see all the possible permutations suggested in case we missed one.

We just tried it on a 6.2.1 system with 2.95.3 compiler and it produced all the symbols but the dlopen() call segfaults (as of 15 minutes ago, we are checking). This leaves us with an error in the runtime libs for 2.95.3 and a linker problem in 6.3 - 3.3.1 or 2.95.3 compilers. What is wrong is rather nasty for us.

respectfully
BJ
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Postby rick » Thu Sep 09, 2004 10:32 pm

Hmm.. seg faulting on dlopen is usually caused by failing to compile one (or more) of the objects with the -shared flag. Of course if you are having problems with static libs, the shared issues may just be a red herring.

Is there anything "interesting" about these objects? Are they just plain C/C++? Are they extremely large or anything? I mean obviously most of the rest of us aren't having these problems, so the trick is to see what you are doing differently.

Rick..
rick
QNX Master
 
Posts: 500
Joined: Wed Nov 13, 2002 3:59 am

Postby bjchip » Thu Sep 09, 2004 10:58 pm

We're going over the code, but at least one of the modules that dies in dlopen is explicitly built -shared. The odd bit for us is that the same code generates ALL the symbols in the .so in 2.95.3 under 6.2.1 and only a fraction of the symbols wind up in the .so in 3.3.1 or 2.95.3 on 6.3. Same code. The dlopen works on 6.3 but there's no symbol to work with, it fails on 6.2.1 when the symbols are there.

Code is pretty straightforward modem control stuff. Works nicely under linux not particularly huge individually, overall pretty big as a system.

respectfully
BJ
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Postby rick » Fri Sep 10, 2004 3:59 pm

Hmm.. lost my response to this - will try again..

Do you have any inline asm in your code? The only time I had a similiar problem was when I was porting code from linux and the inline asm that worked there, would not work in QNX - mainly because it wasn't relocatible and QNX's linker was not able to deal with it (I don't recall the exact details).

If not, the next approach is to take a simple example and build it in your frame work - and then slowly add more to the simple case until you start seeing the problem again - basic divide and conquer.

It is a PIA but it might give you a single module causing the problem - which can then help identify what the problem is - be it a bug in your code, or a "feature" that QNX has. ;-)

Rick..
rick
QNX Master
 
Posts: 500
Joined: Wed Nov 13, 2002 3:59 am

Postby evanh » Sat Sep 11, 2004 12:42 am

I got fed up with openqnx's habit of losing my posts so now I always take a copy of the text before clicking submit.
evanh
QNX Master
 
Posts: 737
Joined: Sat Feb 01, 2003 8:04 am

Postby cburgess » Sat Sep 11, 2004 7:27 pm

By losing symbols, do you mean that you get a bunch of "unknown symbol" messages when trying to load the shared object?

If so, you have been bitten by a 6.3.0 linker bug.

BTW - the segfault on dlopen under 6.2.1 is almost certainly a non-shared object being linked in - check your map file, and check (with objdump -h) for the presence of rel.text or rel.rodata - these are sure signs.

Under 6.3.0 this wouldn't fail, since it will detect the code relocations and just make your 'shared' object a private copy.
cburgess
QNX Master
 
Posts: 209
Joined: Tue Aug 31, 2004 8:40 pm
Location: Ottawa

Postby noc » Sun Sep 12, 2004 5:45 am

cburgess wrote:BTW - the segfault on dlopen under 6.2.1 is almost certainly a non-shared object being linked in - check your map file, and check (with objdump -h) for the presence of rel.text or rel.rodata - these are sure signs.

Under 6.3.0 this wouldn't fail, since it will detect the code relocations and just make your 'shared' object a private copy.


Does that mean 6.3.0 starts to support COW ?
noc
Senior Member
 
Posts: 1634
Joined: Sat Jul 06, 2002 4:34 am

Postby bjchip » Sun Sep 12, 2004 9:35 pm

There is a 6.3.0 linker bug? Is this something there is a patch/workaround for?

We don't have inline asm, but we did inline a bunch of low-level C. I will discuss this with
the team. I suspect we can leave it without the inline flag... but if the compiler should optimize it
to become an inline, would it be the same?

I will push my guy in OZ to check for the qnx "official word" on bugs in linkers.

respectfully
BJ
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Postby bjchip » Sun Sep 12, 2004 9:50 pm

Yes, A raft of unknown symbol complaints that have no identifier for the symbol. Just the error message without any clues as to what causes them. Not what I'd expect from the error messages. Makes me wonder though, if the two things are related. If I have a non-shared object inadvertently included would the operation to make the private copies leave a dangling error flag/pointer in the linker?

respectfully
BJ
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Postby cburgess » Tue Sep 14, 2004 1:16 pm

noc wrote:
cburgess wrote:BTW - the segfault on dlopen under 6.2.1 is almost certainly a non-shared object being linked in - check your map file, and check (with objdump -h) for the presence of rel.text or rel.rodata - these are sure signs.

Under 6.3.0 this wouldn't fail, since it will detect the code relocations and just make your 'shared' object a private copy.


Does that mean 6.3.0 starts to support COW ?


No, it just makes a complete copy of the shared objects code.
cburgess
QNX Master
 
Posts: 209
Joined: Tue Aug 31, 2004 8:40 pm
Location: Ottawa

Postby cburgess » Tue Sep 14, 2004 1:18 pm

bjchip wrote:There is a 6.3.0 linker bug? Is this something there is a patch/workaround for?

We don't have inline asm, but we did inline a bunch of low-level C. I will discuss this with
the team. I suspect we can leave it without the inline flag... but if the compiler should optimize it
to become an inline, would it be the same?

I will push my guy in OZ to check for the qnx "official word" on bugs in linkers.

respectfully
BJ


Are you seeing the problem with 3.3.1 too? So far we have only seen it with 2.95.3

Right now the only solution is to use the 6.2.1 linker.

If you can, a reproduceable test case (small as possible) would help the tools guys track it down faster.
cburgess
QNX Master
 
Posts: 209
Joined: Tue Aug 31, 2004 8:40 pm
Location: Ottawa

Postby cburgess » Tue Sep 14, 2004 1:21 pm

bjchip wrote:Yes, A raft of unknown symbol complaints that have no identifier for the symbol. Just the error message without any clues as to what causes them. Not what I'd expect from the error messages. Makes me wonder though, if the two things are related. If I have a non-shared object inadvertently included would the operation to make the private copies leave a dangling error flag/pointer in the linker?

respectfully
BJ


An interesting question... the answer is, I dont _THINK_ so. :wink:
cburgess
QNX Master
 
Posts: 209
Joined: Tue Aug 31, 2004 8:40 pm
Location: Ottawa

Postby bjchip » Tue Sep 28, 2004 9:01 pm

cburgess wrote:
bjchip wrote:There is a 6.3.0 linker bug? Is this something there is a patch/workaround for?

We don't have inline asm, but we did inline a bunch of low-level C. I will discuss this with
the team. I suspect we can leave it without the inline flag... but if the compiler should optimize it
to become an inline, would it be the same?

I will push my guy in OZ to check for the qnx "official word" on bugs in linkers.

respectfully
BJ


Are you seeing the problem with 3.3.1 too? So far we have only seen it with 2.95.3

Right now the only solution is to use the 6.2.1 linker.

If you can, a reproduceable test case (small as possible) would help the tools guys track it down faster.


Yes, 3.3.1 as well as 2.95.3 -
hmmmm... a separate 6.2.1 linker? Could I use it under 6.3 ?

At present we are critical time (ain't we always) and working around using static links for this high-level driver code. We haven't been able to reproduce it with simple examples yet, possibly because we were using C rather than C++ for the simple examples and the problem is in C++. It was the linker (so we thought), which is why we tried the C for a first cut. To make it do this spaghetti link trick we'll probably have to build some C++ code with similar dependencies and inheritance. Longer and harder and so it is delayed.
bjchip
Active Member
 
Posts: 46
Joined: Wed Nov 26, 2003 10:20 pm

Next

Return to General Programming

Who is online

Users browsing this forum: No registered users and 3 guests