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

Tue Mar 26 16:52:57 UTC 2013

On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger
<mezz.freebsd at gmail.com> wrote:
> 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.

I don't assume.  I just know it.  Know from everyday usage.

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

My knowledge based on 2.x series.  At the times of 1.x, the "base"
compiler was modern enough for mitigate the need to redefine
compilers.

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

I know it and knew at the time of writting.

I don't know or don't understand why these "hacks" are needed, and, if
they are really needed, then why they maintained separatelly instead
of be pushed to the upstream and become part of libtool
out-of-the-box.

If, for some reason, libtool upstream cannot be conviced, or just at
the transition stage, why patch the ${LOCALBASE}/bin/libtool?  Why
don't patch the "local" libtool generated by package's configure and
which contains all configure-gatchered variables properly filled (at
least for those packages, which use fresh enough libtool version)?  Or
why don't patch the devel/libtool (if need) for install the patched
ltmain.sh (if need) and then force package to re-grab
autotools/libtool related things and regenerate the configure script?

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