From owner-freebsd-ports@FreeBSD.ORG Tue Mar 26 15:46:06 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2569DEA1; Tue, 26 Mar 2013 15:46:06 +0000 (UTC) (envelope-from mezz.freebsd@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id C962D6D6; Tue, 26 Mar 2013 15:46:05 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id ht11so5726401vcb.27 for ; Tue, 26 Mar 2013 08:46:05 -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=vixJmOagsFNQYVEL8HJu3x2wXiQG/ZRktA7YbQOfYMc=; b=r8NjUx5Nk/q1NokDF08iJZx2SVl/XZtj8Fvl77F4dvjFnk3pcU4jZETkTfNa7JZIqf hYmCBYvuRjNUsZJR7pyHX44Kd9A4d4erCNqvFsDEy0OTNqR/vP2G9PGjAP91kn7+9zzm ROpQnjopXcxtHZThpFcSpF6zpswMi9aaV8YrNIuvrf/G3kH9Qck0QyICUEcvwGWfMOOD rP+vBALTVFLg+I2jXUpcZLLcqZ3A407v3TgEV5KTNw1PX+5CBuD+JQAy40hWMVWjG/kO PbcrEWtKzHH8S/d394O+SpVdurmBw3H/SSf4btbDbTupWY4nPkZvVbd17ZgsD/GG+mmJ GbbQ== MIME-Version: 1.0 X-Received: by 10.58.229.69 with SMTP id so5mr19526408vec.6.1364312765112; Tue, 26 Mar 2013 08:46:05 -0700 (PDT) Received: by 10.58.74.197 with HTTP; Tue, 26 Mar 2013 08:46:05 -0700 (PDT) In-Reply-To: References: <201303261050.r2QAo9v6041217@mech-cluster241.men.bris.ac.uk> Date: Tue, 26 Mar 2013 10:46:05 -0500 Message-ID: Subject: Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk? From: Jeremy Messenger To: "Andrew W. Nosenko" 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 15:46:06 -0000 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. 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') 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. > 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 -- mezz.freebsd@gmail.com - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org