From owner-freebsd-ports@FreeBSD.ORG Tue Mar 26 16:52:57 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7F0CC487; Tue, 26 Mar 2013 16:52:57 +0000 (UTC) (envelope-from andrew.w.nosenko@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 493AAAE5; Tue, 26 Mar 2013 16:52:57 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so6732934iaf.0 for ; Tue, 26 Mar 2013 09:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rKptGnOIWbXQstzTn4j/MJ21QiIDDFIdGsITvQvxmA4=; b=RJQD1T9ATnRspyQyoGQM1PxoxqSUZDgi3xJIdEYjargXWZyYppurgr6RGIOSrFvUSV 47uUbBhXLTilHDnQp9BB61Y3LhPgNE0VelZCoQx21R+BVGa3AGHim9qEfCYj8RZusXsl q0ftVe7rcwLZecM3An5LmyIjd3KsdKAKlIwMGPxjunKbhQMcqsG9XbANzsBuV9j4nGct vcV4RtL4M0Nazs8tuHF3raEufC7ejsifU2lcKi+CmL9oTvOqc+eoFa+0nRNAtXY1FQqM QZ7QfXy+ZcvGtfjESTOB+DwAMkRJCgeQK1ywN8MYV67/q+SytO2+KFV4ZsDvma0yTaWK xHqg== MIME-Version: 1.0 X-Received: by 10.43.65.195 with SMTP id xn3mr9774980icb.5.1364316776968; Tue, 26 Mar 2013 09:52:56 -0700 (PDT) Received: by 10.64.68.106 with HTTP; Tue, 26 Mar 2013 09:52:56 -0700 (PDT) In-Reply-To: References: <201303261050.r2QAo9v6041217@mech-cluster241.men.bris.ac.uk> Date: Tue, 26 Mar 2013 18:52:56 +0200 Message-ID: Subject: Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk? From: "Andrew W. Nosenko" To: Jeremy Messenger Content-Type: text/plain; charset=ISO-8859-1 Cc: gerald@pfeifer.com, mexas@bristol.ac.uk, freebsd-ports@freebsd.org, bdrewery@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 16:52:57 -0000 On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger wrote: > On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko > wrote: >> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger >> wrote: >>> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko >>> wrote: >>>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht >>>> wrote: >>>>> From andrew.w.nosenko@gmail.com Mon Mar 25 18:09:38 2013 >>>>> >>>>> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer wrote: >>>>> > On Mon, 25 Mar 2013, Anton Shterenlikht wrote: >>>>> >> I've now run ia64 with the above change for over 2 weeks, >>>>> >> mostly rebuilding ports, etc. >>>>> >> I didn't see any issues with gcc47. >>>>> >> So, from my very limited testing, >>>>> >> gcc47 can be made default. >>>>> > >>>>> > Thanks for the feedback, Anton! To really make that switch >>>>> > globally, we'll need more extensive testing, a full ports builds >>>>> > run, since there is a chance that some port you are not using may >>>>> > be broken, and I hope to get this done in the coming weeks. >>>>> >>>>> >From my expiriense, devel/glib20 cannot be compiled with gcc47. >>>>> >>>>> Isn't it built with the system default compiler: >>>>> >>>>> configure:3954: checking for C compiler version >>>>> configure:3963: cc --version >&5 >>>>> cc (GCC) 4.2.1 20070831 patched [FreeBSD] >>>>> >>>>> I think we are only talking about updating lang/gcc to 4.7. >>>> >>>> By default -- yes, it is going to build with base gcc. But topic and, >>>> therefore, my reaction was about overriding compiler to be lang/gcc* >>>> from ports and whether there are ports, which fail in that case. At >>>> least, as I understand it. >>>> >>>> Now, why overriding the compiler for Glib seems important to me and >>>> why I tried to do that: >>>> >>>> Since >>>> commit aba0f0c38bbfa11ad48b5410ebdbed2a99e68c58 >>>> Author: Ryan Lortie >>>> Date: Tue Oct 18 16:21:50 2011 -0400 >>>> >>>> gatomic: introduce G_ATOMIC_LOCK_FREE >>>> >>>> glib atomics implementation depends on gcc predefined macro >>>> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, which is absent on the base >>>> gcc-4.2 and on Clang (all version, at least at that time). >>>> >>>> As consequence, we have a mutex-based implementation of atomics. >>>> Building Glib using more modern GCC (e.g. gcc-4.7) would help, but >>>> gnome-libtool hack prevents us from that. >>> >>> Did you install all ports with GCC 4.7? If you install libtool with >>> foo compiler then install other ports with bar compiler will be >>> broken. You have to reinstall libtool with the bar compiler to make >>> other ports with bar compiler works. >> >> No, I should not do that (of course if assume that port machinery >> doesn't interfere with configure results by discarding part of them). > > You need to try it. You can't assume anything. I don't assume. I just know it. Know from everyday usage. > It's well known that if > you change the CC/CXX then you have to reinstall libtool. Although, I > don't know if it's still true for present libtool, but it was problem > with libtool15 at last time when I checked. The libtool15 will storage > the CC, CXX and other stuff as default of what you used it on > libtool15. (ie: Run 'libtool --config') My knowledge based on 2.x series. At the times of 1.x, the "base" compiler was modern enough for mitigate the need to redefine compilers. > > The gnome-libtool was copied from ${LOCALBASE}/bin/libtool (libtool > port) then patch the bug of shared library version in gnome-libtool. > It also changed the configure to look at gnome-libtool. Nothing more > and nothing less. You can look at Mk/bsd.gnome.mk by search for > ltverhack. I know it and knew at the time of writting. I don't know or don't understand why these "hacks" are needed, and, if they are really needed, then why they maintained separatelly instead of be pushed to the upstream and become part of libtool out-of-the-box. If, for some reason, libtool upstream cannot be conviced, or just at the transition stage, why patch the ${LOCALBASE}/bin/libtool? Why don't patch the "local" libtool generated by package's configure and which contains all configure-gatchered variables properly filled (at least for those packages, which use fresh enough libtool version)? Or why don't patch the devel/libtool (if need) for install the patched ltmain.sh (if need) and then force package to re-grab autotools/libtool related things and regenerate the configure script? > >> libtool script is a _generated_ thing when used with autoconf. >> 'configure' does some checks (including how to execute linker >> depending on used languages) and generates the "current" libtool sript >> using these results. This generated script has nothing with >> /usr/local/bin/libtool. Moreover, the system-wide libtool has no >> business there, not used and may be completely absent until you want >> regenerate and replace all package-supplied tools by your copy by >> something like 'autoreconf -f'. >> >> As you can see, under proper workflow, there no dependency, which >> version of compiler was installed or used on the time of >> /usr/local/bin/libtool generation. All knowledge about currently used >> language, compiler, linker abelities and so on are gatchered by >> configure and written into "local" package-specific libtool script (in >> contrast to the "global" /usr/local/bin/libtool). >> >> The only one problem that ports machinery decides to trow out these >> results and use own copy, which know nothing about actual package >> preferences, needs, nor used language. >> >>> >>>> See also: >>>> Thread "atomic ops broken on mac/xcode" >>>> https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00089.html >>>> >>>> Gnome bugzilla #682818: atomic ops broken on mac/xcode >>>> https://bugzilla.gnome.org/show_bug.cgi?id=682818 >>>> >>>> LLVM/Clang bugzilla #11174: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_ >>>> http://llvm.org/bugs/show_bug.cgi?id=11174 >>>> -- Andrew W. Nosenko