From patchwork Thu Oct 30 08:33:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 404926 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C929D14007B for ; Thu, 30 Oct 2014 19:33:40 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=KrtHA/hBccLOteyX nWKmr3uS5raOcSdA0yJKgDymU9UWUceksnXRFSCWKy87pfn0pYQ9VY20XiaDnfja WdqBl7cACTAeVND+4goc+yDnPtn1JpF+CI7OxNPgfFOan9geqw1BwyEKBX67D30w irBC+LYygsub0HIqAtqPgIknF/M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=7QQ8jAeF7RfOQFj/SN05Ca vuQcM=; b=O+n5ygT1FsrkOSmTsF8ZluZYQm0kuIaDPhcJDYjXwjr+ZqQwWiP2FG hVTgFmLjtUGGOOs4YhsX4H+xK/LbANOxfcVd6preQVluNq0/Tm0b0InkD2K19/lm R0M4YhBa+Wr+oexBhKPQWoL0y7VbcVCXIwpSYn/0SIMWqzjzqHvQo= Received: (qmail 11623 invoked by alias); 30 Oct 2014 08:33:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 11585 invoked by uid 89); 30 Oct 2014 08:33:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 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; Thu, 30 Oct 2014 08:33:30 +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 1XjlAb-0004ym-OD from Thomas_Schwinge@mentor.com ; Thu, 30 Oct 2014 01:33:26 -0700 Received: from feldtkeller.schwinge.homeip.net (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; Thu, 30 Oct 2014 08:33:24 +0000 From: Thomas Schwinge To: Jakub Jelinek CC: Uros Bizjak , "gcc-patches@gcc.gnu.org" , Tom Tromey , Jeff Law , Phil Muldoon Subject: Re: [PATCH 5/5] add libcc1 In-Reply-To: <20141028122350.GF10376@tucnak.redhat.com> References: <20141028093506.GE10376@tucnak.redhat.com> <544F7181.4060307@redhat.com> <544F8253.4040906@redhat.com> <20141028122350.GF10376@tucnak.redhat.com> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (i586-pc-linux-gnu) Date: Thu, 30 Oct 2014 09:33:08 +0100 Message-ID: <87y4rydkjf.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi! On Tue, 28 Oct 2014 13:23:50 +0100, Jakub Jelinek wrote: > On Tue, Oct 28, 2014 at 11:47:31AM +0000, Phil Muldoon wrote: > > I think I have a solution. Though my automake fu is very weak. Does > > this patch work for you? I'm really not sure how to deal with the > > three possible versions of libiberty any other way. > > That is insufficient, > a) you don't filter away -fsanitize=address, which would make it > unusable in gdb > b) without the -Wc, stuff, you get the ugly libtool warnings > c) the LTLDFLAGS mess is needed for libtool not eating the -Wc, stuff > So I'm proposing my patch (which is modeled after lto-plugin changes by > myself and others), [...] (Maybe we should now turn that into generic infrastructure?) > 2014-10-28 Jakub Jelinek > > * Makefile.am (CXXFLAGS, LDFLAGS): Filter out -fsanitize=address. > (libiberty_normal, libiberty_noasan, libiberty_pic, libiberty_dep): > New variables. > (libiberty): Set to -Wc, followed by the first existing noasan/, > pic/ or . libiberty.a. > (libcc1plugin_la_DEPENDENCIES, libcc1plugin_la_LINK, > libcc1_la_DEPENDENCIES, libcc1_la_LINK, LTLDFLAGS): New variables. > * Makefile.in: Regenerated. ;-) To re-use your words: »That is insufficient«, d) in a configuration where there is no lto-plugin built, we now try to link the shared libcc1 against a static libiberty: /bin/bash ./libtool --tag=CXX --mode=link g++ -m64 [...] -module -export-symbols [...]/source-gcc/libcc1/libcc1.sym -Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath /lib/../lib64 findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/libiberty.a libtool: link: g++ -m64 [...] -shared -nostdlib [...]/crti.o [...]/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o [...] -lstdc++ -lm -lc -lgcc_s [...]/crtendS.o [...]/crtn.o -m64 [...] -static-libstdc++ -static-libgcc ../libiberty/libiberty.a -Wl,-soname -Wl,libcc1.so.0 -Wl,-retain-symbols-file -Wl,[...]/source-gcc/libcc1/libcc1.sym -o .libs/libcc1.so.0.0.0 [...]/ld: ../libiberty/libiberty.a(regex.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC ../libiberty/libiberty.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status make[3]: *** [libcc1.la] Error 1 make[3]: Leaving directory `[...]/build-gcc/libcc1' make[2]: *** [all] Error 2 make[2]: Leaving directory `[...]/build-gcc/libcc1' make[1]: *** [all-libcc1] Error 2 make[1]: Leaving directory `[...]/build-gcc' make: *** [all] Error 2 Here is a patch that I'm testing; OK? I didn't understand what the conditions are that libcc1 might not be built as a shared library: is it always built as one -- but is that really supported on all systems? If that's indeed true, then this could be further simplified, and --enable-shared passed to the host libiberty unconditionally. Grüße, Thomas --- configure.ac +++ configure.ac @@ -1865,7 +1865,6 @@ if test -d ${srcdir}/gcc; then new_enable_languages=,c, # If LTO is enabled, add the LTO front end. - extra_host_libiberty_configure_flags= if test "$enable_lto" = "yes" ; then case ,${enable_languages}, in *,lto,*) ;; @@ -1873,10 +1872,8 @@ if test -d ${srcdir}/gcc; then esac if test "${build_lto_plugin}" = "yes" ; then configdirs="$configdirs lto-plugin" - extra_host_libiberty_configure_flags=--enable-shared fi fi - AC_SUBST(extra_host_libiberty_configure_flags) missing_languages=`echo ",$enable_languages," | sed -e s/,all,/,/ -e s/,c,/,/ ` potential_languages=,c, @@ -2190,6 +2187,17 @@ then esac fi +# Sometimes we have special requirements for the host libiberty. +extra_host_libiberty_configure_flags= +case " $configdirs " in + *" lto-plugin "* | *" libcc1 "*) + # When these are to be built as shared libraries, the same applies to + # libiberty. + extra_host_libiberty_configure_flags=--enable-shared + ;; +esac +AC_SUBST(extra_host_libiberty_configure_flags) + # Produce a warning message for the subdirs we can't configure. # This isn't especially interesting in the Cygnus tree, but in the individual # FSF releases, it's important to let people know when their machine isn't