From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10349 invoked by alias); 4 May 2010 16:55:09 -0000 Received: (qmail 10227 invoked by uid 48); 4 May 2010 16:54:56 -0000 Date: Tue, 04 May 2010 16:55:00 -0000 Message-ID: <20100504165456.10226.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug lto/41376] collect2 does not handle static libraries In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "bmei at broadcom dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-05/txt/msg00345.txt.bz2 ------- 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? -- bmei at broadcom dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bmei at broadcom dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41376