public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/41376] collect2 does not handle static libraries
Date: Wed, 05 May 2010 08:55:00 -0000	[thread overview]
Message-ID: <20100505085504.22152.qmail@sourceware.org> (raw)
In-Reply-To: <bug-41376-10053@http.gcc.gnu.org/bugzilla/>



------- Comment #7 from rguenther at suse dot de  2010-05-05 08:55 -------
Subject: Re:  collect2 does not handle static libraries

On Tue, 4 May 2010, bmei at broadcom dot com wrote:

> ------- Comment #6 from bmei at broadcom dot com  2010-05-04 16:54 -------
> > So this is a rough first draft of the-kind-of-thing-i-was-thinking-of.  We get
> > collect2 to run a dummy link early, and extract the output from the
> > --lto-assist flag to get a list of archive members that we need lto to
> > recompile for us.
> > 
> 
> Well I spent some time to read into collect2/lto code and understand pro/cons
> of different approaches. So far, adding --lto-assist to ld/hacking collect2
> approach looks reasonable to me, though it does require gnu ld. What extra info
> should be in a complete symbol resolution file?

Basically what lto-plugin puts there.  A list of symbols for each
object files that is linked (thus, all required ar archive members)
together with the symbol resolution the linker chose (whether the
symbol was overridden, resolved to sth external, or used as the
prevailing definition).

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376


  parent reply	other threads:[~2010-05-05  8:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-16 13:03 [Bug lto/41376] New: collect2 (and maybe lto1) do " rguenth at gcc dot gnu dot org
2009-12-11 16:50 ` [Bug lto/41376] " rguenth at gcc dot gnu dot org
2010-04-28 13:39 ` [Bug lto/41376] collect2 does " davek at gcc dot gnu dot org
2010-04-28 23:49 ` davek at gcc dot gnu dot org
2010-04-29  5:28 ` davek at gcc dot gnu dot org
2010-04-29  8:29 ` rguenther at suse dot de
2010-05-04 16:55 ` bmei at broadcom dot com
2010-05-05  8:55 ` rguenther at suse dot de [this message]
2010-05-24  9:31 ` bmei at broadcom dot com
2010-05-24 12:15 ` rguenth at gcc dot gnu dot org
2010-05-24 13:30 ` bmei at broadcom dot com
2010-05-24 17:28 ` rguenther at suse dot de

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=20100505085504.22152.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).