Date: Tue, 26 Mar 2013 17:00:46 +0200 From: "Andrew W. Nosenko" <andrew.w.nosenko@gmail.com> To: Jeremy Messenger <mezz.freebsd@gmail.com> Cc: gerald@pfeifer.com, mexas@bristol.ac.uk, freebsd-ports@freebsd.org, bdrewery@freebsd.org Subject: Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk? Message-ID: <CALa-7vyQHGjzkdsPxvgV0q51z=YLdEtnXBR_u1fRo2bP_8FaSg@mail.gmail.com> In-Reply-To: <CADLFttcUBkj964auESWJEMx7%2BvnRRLPFO6LOwZcUHkTS=Vo0WQ@mail.gmail.com> References: <CALa-7vw=e2GkfvReD4-eurUv%2BNaR6nJAT9cZ45tQVT6uac-n7Q@mail.gmail.com> <201303261050.r2QAo9v6041217@mech-cluster241.men.bris.ac.uk> <CALa-7vx_gHLiMJpZ3P_VgFHDpRof1Azzma3Afa0f8NtNarUi-Q@mail.gmail.com> <CADLFttcUBkj964auESWJEMx7%2BvnRRLPFO6LOwZcUHkTS=Vo0WQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger <mezz.freebsd@gmail.com> wrote: > On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko > <andrew.w.nosenko@gmail.com> wrote: >> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht >> <mexas@bristol.ac.uk> 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 <gerald@pfeifer.com> 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 <desrt@desrt.ca> >> 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). 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 <andrew.w.nosenko@gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALa-7vyQHGjzkdsPxvgV0q51z=YLdEtnXBR_u1fRo2bP_8FaSg>