Date: Tue, 26 Mar 2013 10:46:05 -0500 From: Jeremy Messenger <mezz.freebsd@gmail.com> To: "Andrew W. Nosenko" <andrew.w.nosenko@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: <CADLFtteNg8BFBnMPD29Tij7Yt5n0TGR5ouXkEXfk2r_xVa7TxQ@mail.gmail.com> In-Reply-To: <CALa-7vyQHGjzkdsPxvgV0q51z=YLdEtnXBR_u1fRo2bP_8FaSg@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> <CALa-7vyQHGjzkdsPxvgV0q51z=YLdEtnXBR_u1fRo2bP_8FaSg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
<andrew.w.nosenko@gmail.com> wrote:
> 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).
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 <andrew.w.nosenko@gmail.com>
--
mezz.freebsd@gmail.com - mezz@FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLFtteNg8BFBnMPD29Tij7Yt5n0TGR5ouXkEXfk2r_xVa7TxQ>