is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?

Tue Mar 26 15:46:06 UTC 2013

On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
<andrew.w.nosenko at gmail.com> wrote:
> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
> <mezz.freebsd at gmail.com> wrote:
>> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
>> <andrew.w.nosenko at gmail.com> wrote:
>>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
>>> <mexas at bristol.ac.uk> wrote:
>>>>         From andrew.w.nosenko at gmail.com Mon Mar 25 18:09:38 2013
>>>>
>>>>         On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer <gerald at 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 at 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 at gmail.com>

-- 
mezz.freebsd at gmail.com - mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gnome at FreeBSD.org