Even after linking api's not gettingl linked until explicitly invoked

[Varun Tewari]

People,

I came across this scenario today on vxworks, using arm tool chain
ccarm for compiling
ararm for archiving
ldarm for linking.

I have compiled two sets of files a*.c and b*.c using ccarm.
Now, using ararm I create two libraries A.a and B.a
Then I am writing a small program(varun.c), which invokes api's in B.a

again this is compiled using ccarm and goes through.
Now, i start to link using ldarm
ldarm -lA -lB varun.o -o varun

Here, I start getting error(undefined reference) for all api's of A which api's in B invoke.
Now, when I invoke, explicitly in my code (varun.c) for which intially i was getting undefined reference, things work fine.


After doing some hit and trail, I realized, in essence the thing is, until I do some explicit invocation of atleast one api of file a1.c, none of the api's of a1.c archived in A.a are getting linked.


I know this probably isn't the precise place to ask this, and please ignore the ccarm, ldarm and ararm tools.

The reason I am posting this here, is that I found this pretty interesting and weird, and wanted to know if we turn on some option in C or gcc by default that makes us not hit this issue on linux.
I understand there is some operating system dependency here for this behavior, and its possible that one a flavor of linux, we might see such behavior and on other we might not, still what causes such behavior on a typical OS.
Is something like that specified by C.
2. does gcc has any such functionality that even after linking, you get error until we explicitly invoke.

Please excuse me, if you still think its unreasonable to post this here.

Pour in.

[Eric Sosman]

On 5/15/2013 12:20 PM, Varun Tewari wrote:
> People,
>
> I came across this scenario today on vxworks, using arm tool chain
> ccarm for compiling
> ararm for archiving
> ldarm for linking.
>
> I have compiled two sets of files a*.c and b*.c using ccarm.
> Now, using ararm I create two libraries A.a and B.a
> Then I am writing a small program(varun.c), which invokes api's in B.a
>
> again this is compiled using ccarm and goes through.
> Now, i start to link using ldarm
> ldarm -lA -lB varun.o -o varun
>
> Here, I start getting error(undefined reference) for all api's of A which api's in B invoke.
> Now, when I invoke, explicitly in my code (varun.c) for which intially i was getting undefined reference, things work fine.
>
>
> After doing some hit and trail, I realized, in essence the thing is, until I do some explicit invocation of atleast one api of file a1.c, none of the api's of a1.c archived in A.a are getting linked.
>
>
> I know this probably isn't the precise place to ask this, and please ignore the ccarm, ldarm and ararm tools.

You're right that this probably isn't exactly the right forum
for your question, but I think you're wrong about ignoring the tools.
Quite likely, it's the way the tools work that are at the heart of
your trouble. The C language itself has no notion of libraries nor
of how they contribute to forming an executable program; all the
language says is that there exists some unspecified way to combine
several separately-compiled modules ("translation units") into a
program. The mechanisms for doing this are entirely the province of
the tool set, and tools on different systems differ.

That said, it is fairly common for "linkers" to use what amounts
to a single-pass algorithm for selecting items from libraries. Many
linkers process the libraries in the order they appear on the command
line (or configuration file, or whatever), select any library members
that satisfy outstanding unresolved references, and then move on
never to revisit that library again. If that's how your linker works,
you may have better luck with

ldarm varun.o -lB -lA -o varun

If there are cyclical dependencies between A and B (that is, if some
members of A call some members of B *and* some B's call A's) you may
even need something like

ldarm varun.o -lA -lB -lA -o varun

... so that A is searched both before and after B (-lB -lA -lB would
also probably work).

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Varun Tewari]

Thnx man! tht makes sense!