is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
Andrew W. Nosenko
andrew.w.nosenko at gmail.com
Wed Mar 27 16:41:04 UTC 2013
On Wed, Mar 27, 2013 at 12:21 AM, Jeremy Messenger
<mezz.freebsd at gmail.com> wrote:
> On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko
> <andrew.w.nosenko at gmail.com> wrote:
>> 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.
>
> # pkg_info -IX libtool
> libtool-2.4.2 Generic shared library support script
> # libtool --config | grep CC=
> LTCC="cc"
> CC="cc"
I's about system-wide libtool (/usr/local/bin/libtool), which is
irrelevant and unused when autoconf+automake+libtool chain works.
When package builds using autoconf+automake+libtool chain, then the
generated libtool script works there.
System-wide libtool:
# pkg_info -xI libtool
libtool-2.4.2 Generic shared library support script
# /usr/local/bin/libtool --version
libtool (GNU libtool) 2.4.2
Written by Gordon Matzigkeit <gord at gnu.ai.mit.edu>, 1996
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# /usr/local/bin/libtool --config | grep CC=
LTCC="cc"
CC="cc"
# /usr/local/bin/libtool --config > ~/libtool-system
Libtool, generated for devel/glib20 with default compiler (gcc-4.2 from base):
# cd /usr/ports/devel/glib20
# make clean
===> Cleaning for glib-2.34.3
# make extract
===> License LGPL20 accepted by the user
===> Found saved configuration for glib-2.34.3
===> Fetching all distfiles required by glib-2.34.3 for building
===> Extracting for glib-2.34.3
===> License LGPL20 accepted by the user
===> Found saved configuration for glib-2.34.3
===> Fetching all distfiles required by glib-2.34.3 for building
=> SHA256 Checksum OK for gnome2/glib-2.34.3.tar.xz.
===> glib-2.34.3 depends on file: /usr/local/bin/xz - found
===> glib-2.34.3 depends on file: /usr/local/bin/perl5.12.4 - found
# cd work/glib-2.34.3/
# ls -l libtool
ls: libtool: No such file or directory
# ./configure CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
[output is skipped]
# ls -l libtool
-rwxr-xr-x 1 root wheel 297882 Mar 27 17:31 libtool
# ./libtool --config | grep CC=
LTCC="gcc"
CC="gcc"
# ./libtool --config > ~/libtool-glib-gcc
Libtool, generated for devel/glib20 with gcc-4.7 from ports:
# cd /usr/ports/devel/glib20
# make clean
===> Cleaning for glib-2.34.3
# make extract
===> License LGPL20 accepted by the user
===> Found saved configuration for glib-2.34.3
===> Fetching all distfiles required by glib-2.34.3 for building
===> Extracting for glib-2.34.3
===> License LGPL20 accepted by the user
===> Found saved configuration for glib-2.34.3
===> Fetching all distfiles required by glib-2.34.3 for building
=> SHA256 Checksum OK for gnome2/glib-2.34.3.tar.xz.
===> glib-2.34.3 depends on file: /usr/local/bin/xz - found
===> glib-2.34.3 depends on file: /usr/local/bin/perl5.12.4 - found
# cd work/glib-2.34.3/
# ls -l libtool
ls: libtool: No such file or directory
# ./configure CC=gcc47 CPPFLAGS=-I/usr/local/include
LDFLAGS=-L/usr/local/lib
[output is skipped]
# ls -l libtool
-rwxr-xr-x 1 root wheel 298022 Mar 27 17:38 libtool
# ./libtool --config | grep CC=
LTCC="gcc47"
CC="gcc47"
# ./libtool --config > ~/libtool-glib-gcc47
Differences:
system vs glib + default gcc:
# diff -U0 ~/libtool-system ~/libtool-glib-gcc
--- /root/libtool-system 2013-03-27 17:26:37.000000000 +0200
+++ /root/libtool-glib-gcc 2013-03-27 17:34:11.000000000 +0200
@@ -5,0 +6,3 @@
+# Whether or not to build static libraries.
+build_old_libs=no
+
@@ -18,3 +20,0 @@
-# Whether or not to build static libraries.
-build_old_libs=yes
-
@@ -28 +28 @@
-SHELL="/bin/sh"
+SHELL="/usr/local/bin/bash"
@@ -38 +38 @@
-host=amd64-portbld-freebsd8.0
+host=x86_64-unknown-freebsd8.0
@@ -42,2 +42,2 @@
-build_alias=amd64-portbld-freebsd8.0
-build=amd64-portbld-freebsd8.0
+build_alias=
+build=x86_64-unknown-freebsd8.0
@@ -68 +68 @@
-max_cmd_len=262144
+max_cmd_len=196608
@@ -127 +127 @@
-LTCC="cc"
+LTCC="gcc"
@@ -130 +130 @@
-LTCFLAGS="-O2 -pipe -O2 -march=native -fno-strict-aliasing"
+LTCFLAGS="-g -O2 -Wall"
@@ -244 +244 @@
-dlopen_support=yes
+dlopen_support=unknown
@@ -247 +247 @@
-dlopen_self=yes
+dlopen_self=unknown
@@ -250 +250 @@
-dlopen_self_static=no
+dlopen_self_static=unknown
@@ -268 +268 @@
-CC="cc"
+CC="gcc"
system vs. glib + gcc-4.7:
# diff -U0 ~/libtool-system ~/libtool-glib-gcc47
--- /root/libtool-system 2013-03-27 17:26:37.000000000 +0200
+++ /root/libtool-glib-gcc47 2013-03-27 17:39:40.000000000 +0200
@@ -5,0 +6,3 @@
+# Whether or not to build static libraries.
+build_old_libs=no
+
@@ -18,3 +20,0 @@
-# Whether or not to build static libraries.
-build_old_libs=yes
-
@@ -28 +28 @@
-SHELL="/bin/sh"
+SHELL="/usr/local/bin/bash"
@@ -38 +38 @@
-host=amd64-portbld-freebsd8.0
+host=x86_64-unknown-freebsd8.0
@@ -42,2 +42,2 @@
-build_alias=amd64-portbld-freebsd8.0
-build=amd64-portbld-freebsd8.0
+build_alias=
+build=x86_64-unknown-freebsd8.0
@@ -68 +68 @@
-max_cmd_len=262144
+max_cmd_len=196608
@@ -127 +127 @@
-LTCC="cc"
+LTCC="gcc47"
@@ -130 +130 @@
-LTCFLAGS="-O2 -pipe -O2 -march=native -fno-strict-aliasing"
+LTCFLAGS="-g -O2 -Wall"
@@ -238 +238 @@
-sys_lib_search_path_spec="/usr/lib "
+sys_lib_search_path_spec="/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd8.0/4.7.3
/usr/local/x86_64-portbld-freebsd8.0/lib /usr/local/lib/gcc47 /lib
/usr/lib "
@@ -244 +244 @@
-dlopen_support=yes
+dlopen_support=unknown
@@ -247 +247 @@
-dlopen_self=yes
+dlopen_self=unknown
@@ -250 +250 @@
-dlopen_self_static=no
+dlopen_self_static=unknown
@@ -258 +258 @@
-LD="/usr/bin/ld"
+LD="/usr/local/bin/ld"
@@ -268 +268 @@
-CC="cc"
+CC="gcc47"
glib + default gcc vs. glib + gcc-4.7:
# diff -U0 ~/libtool-glib-gcc ~/libtool-glib-gcc47
--- /root/libtool-glib-gcc 2013-03-27 17:34:11.000000000 +0200
+++ /root/libtool-glib-gcc47 2013-03-27 17:39:40.000000000 +0200
@@ -127 +127 @@
-LTCC="gcc"
+LTCC="gcc47"
@@ -238 +238 @@
-sys_lib_search_path_spec="/usr/lib "
+sys_lib_search_path_spec="/usr/local/lib/gcc47/gcc/x86_64-portbld-freebsd8.0/4.7.3
/usr/local/x86_64-portbld-freebsd8.0/lib /usr/local/lib/gcc47 /lib
/usr/lib "
@@ -258 +258 @@
-LD="/usr/bin/ld"
+LD="/usr/local/bin/ld"
@@ -268 +268 @@
-CC="gcc"
+CC="gcc47"
Output of all three 'libtool --config' commands (system libtool, Glib
with default gcc and Glib with gcc-4.7) are attached just for any
case.
>
> MIght be has to do with
> http://svnweb.freebsd.org/ports/head/devel/libtool/files/patch-libltdl_config_ltmain.sh
> ?
Sorry, seems I don't understand you.
How it is related to the honoring or ignoring the configure results?
>
>>> 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.
>
> The fix is really need. It is a bug in libtool that give wrong shared
> library version that will get bump at the every API change. See here:
> http://people.freebsd.org/~mezz/libtool.txt
>
>> 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?
>
> The problem is that you can't just simply add patch in the libtool by
> default or it will affect on thousands of ports (require rebuild,
> chase a lot of library shared version, fix pkg-plist, bump ports and
> etc.). If we complete add patch in all ports tree. It's more likely
> the upstream and maintainer of port will accept patch. That's awful a
> lot of work. Any volunteers?
>
>>>> 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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool-system
Type: application/octet-stream
Size: 11416 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130327/972ce2de/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool-glib-gcc
Type: application/octet-stream
Size: 11384 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130327/972ce2de/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libtool-glib-gcc47
Type: application/octet-stream
Size: 11518 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20130327/972ce2de/attachment-0002.obj>
More information about the freebsd-ports
mailing list