From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19028 invoked by alias); 31 Oct 2014 00:51:05 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 19004 invoked by uid 89); 31 Oct 2014 00:51:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Oct 2014 00:51:03 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Xk0Qd-0000eX-8H from joseph_myers@mentor.com ; Thu, 30 Oct 2014 17:50:59 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Fri, 31 Oct 2014 00:50:56 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1Xk0Qa-0005i1-08; Fri, 31 Oct 2014 00:50:56 +0000 Date: Fri, 31 Oct 2014 05:16:00 -0000 From: "Joseph S. Myers" To: David Malcolm CC: , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 06/10] Heart of the JIT implementation (was: Re: [PATCH 0/5] Merger of jit branch (v2)) In-Reply-To: <1414695171.29411.16.camel@surprise> Message-ID: References: <1413222308-25753-1-git-send-email-dmalcolm@redhat.com> <1413299342.9513.50.camel@surprise> <1413299604.9513.53.camel@surprise> <1414695171.29411.16.camel@surprise> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-10/txt/msg03246.txt.bz2 On Thu, 30 Oct 2014, David Malcolm wrote: > Looking at the build logs, I see: > -fPIC > within the xgcc args in the libgcc build logs, and That seems to depend on t-libgcc-pic, but that appears to cover most likely hosts (including any where I can be confident PIC is actually needed for shared libraries). > > It's certainly not clear that the > > -static-libstdc++ -static-libgcc default for building the compiler > > executables is the right one for building libgccjit.so. > > Agreed, but it's unclear to me what the default should be, and how to go > about fixing it. > > That said, it appears that people who want the libgccjit.so to > dynamically-link against libgcc and libstdc++ can already do so, by Can do so for libgccjit.so but not the compiler executables? (There are no doubt cases where it makes sense for the compiler executables to be dynamically linked with the shared libraries, but also I think cases for linking only libgccjit.so with the shared libraries.) > Do you have thoughts on how I should address this? Also, given that the No. > code works as-is, is resolving this a blocker for merging the jit > branch? (I've been rebasing, and plan to repost the fixed-up patches > for review shortly) I don't see it as a blocker, but I would not be surprised if having the libraries statically linked into libgccjit.so causes problems (is it safe to have two completely separate copies of libstdc++ in the same process? I don't know.). -- Joseph S. Myers joseph@codesourcery.com