| Author |
Message |
|
|
Post subject: Shared Libs don't build from multiple files ?
 Posted: Sep 09, 2004 - 05:53 AM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
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 |
|
|
| |
|
|
|
 |
|
|
|
Post subject:
Posted: Sep 09, 2004 - 03:16 PM
|
|
QNX Master
Joined: Nov 13, 2002
Posts: 499
|
|
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.. |
_________________
An old, er, experienced QNX user
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 09, 2004 - 09:40 PM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 09, 2004 - 10:32 PM
|
|
QNX Master
Joined: Nov 13, 2002
Posts: 499
|
|
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.. |
_________________
An old, er, experienced QNX user
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 09, 2004 - 10:58 PM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 10, 2004 - 03:59 PM
|
|
QNX Master
Joined: Nov 13, 2002
Posts: 499
|
|
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.. |
_________________
An old, er, experienced QNX user
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 11, 2004 - 12:42 AM
|
|
QNX Master
Joined: Feb 01, 2003
Posts: 737
|
|
| 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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 11, 2004 - 07:27 PM
|
|
QNX Master
Joined: Aug 31, 2004
Posts: 175
Location: Ottawa
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 12, 2004 - 05:45 AM
|
|
Senior Member
Joined: Jul 06, 2002
Posts: 1629
|
|
|
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 ? |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 12, 2004 - 09:35 PM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 12, 2004 - 09:50 PM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
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 |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 14, 2004 - 01:16 PM
|
|
QNX Master
Joined: Aug 31, 2004
Posts: 175
Location: Ottawa
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 14, 2004 - 01:18 PM
|
|
QNX Master
Joined: Aug 31, 2004
Posts: 175
Location: Ottawa
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 14, 2004 - 01:21 PM
|
|
QNX Master
Joined: Aug 31, 2004
Posts: 175
Location: Ottawa
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
|
Post subject:
Posted: Sep 28, 2004 - 09:01 PM
|
|
Active Member
Joined: Nov 26, 2003
Posts: 46
|
|
|
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. |
|
|
| |
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
