public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: "John (Eljay) Love-Jensen" <eljay@adobe.com>
To: Erik Rull <erik.rull@rdsoftware.de>
Cc: GCC-help <gcc-help@gcc.gnu.org>
Subject: RE: Transitive Linking fails
Date: Thu, 18 Mar 2010 12:45:00 -0000	[thread overview]
Message-ID: <4B7A6CC9992C4E4FB188D02872C90A6B134F57@nambxv01a.corp.adobe.com> (raw)
In-Reply-To: <4BA16A4F.2010507@rdsoftware.de>

Hi Erik,

> Well, the linking itself was now fine, but I've got new problems in parts of the software that do not use parts of the library.

That sounds odd and unexpected to me.

> When I link the .o files directly into the shared object, then I have no problem, the software runs fine then.

> I've built the lib using
> $(AR) rcs libx.a obj1.o obj2.o
> where $(AR) put out "ar"

That looks good.

> As far as I understood it these two commands should result in the same file:
> $(LD) (shared object options) libshared.so libx.a obj5.o obj6.o
> and
> $(LD) (shared object options) libshared.so obj1.o obj2.o obj5.o obj6.o
> right or not?

No, not right.

For the libx.a file, the linker will only pull over the items from the libx.a that are associated with unresolved symbols.

Since the files are processed in order (left-to-right), as specified on the command-line, the libx.a is processed first.

When the libx.a is processed, at that time there are no unresolved symbols, so nothing will be copied out of the libx.a archive.

> If not what must be done to make these two lines behaviour equivalent?

Try this:

$(LD) (shared object options) libshared.so obj5.o obj6.o libx.a

However...

If you really, really, really want everything included from the libx.a into libshared.so:

$(LD) (shared object options) libshared.so obj5.o obj6.o --whole-archive libx.a --no-whole-archive

However, I discourage that approach.  Instead I suggest you extract out all the .o files from the libx.a, and put them on the link line explicitly:

$(AR) x libx.a obj1.o obj2.o
$(LD) (shared object options) libshared.so obj5.o obj6.o obj1.o obj2.o

> or must I take -static -lx?

Even if you use -static -lx, the order is still important and must appear after your object files (*.o).

Also, you need to "undo" the static state after your library parameters, otherwise the static state is still in effect for any implicit libraries.  (In such a situation people might say, "Why does my libshared.so go from 17 KB to 200 MB with the -Bstatic directive?")

$(LD) (shared object options) libshared.so obj5.o obj6.o -Bstatic -lx -Bdynamic

Sincerely,
--Eljay

  reply	other threads:[~2010-03-18 11:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 17:28 Erik Rull
2010-03-15 19:17 ` John (Eljay) Love-Jensen
2010-03-18  0:50   ` Erik Rull
2010-03-18 12:45     ` John (Eljay) Love-Jensen [this message]
2010-03-16 15:57 ` Ian Lance Taylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B7A6CC9992C4E4FB188D02872C90A6B134F57@nambxv01a.corp.adobe.com \
    --to=eljay@adobe.com \
    --cc=erik.rull@rdsoftware.de \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).