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

[Andrew W. Nosenko]

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).

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>