Date: Wed, 27 Mar 2013 11:58:54 -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: <CADLFttf=B56NafU7rvh2nt1pVvMN9-1gSF5iG4mLxa1iwfJinQ@mail.gmail.com> In-Reply-To: <CALa-7vwcAVLHh63n_eq00rdA8mrwXpj5wqJ%2BYdrHV2wpXxUgWw@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> <CADLFtteNg8BFBnMPD29Tij7Yt5n0TGR5ouXkEXfk2r_xVa7TxQ@mail.gmail.com> <CALa-7vyas_6Ygg5V-oM%2Bb4%2BhBZMhCS2qa0=Uv4%2B1brjTp6yOew@mail.gmail.com> <CADLFtteEt2M2xxW9bOU%2BC_YoTUcBCCqorZnfUDHE66%2BPS-BWjg@mail.gmail.com> <CALa-7vwcAVLHh63n_eq00rdA8mrwXpj5wqJ%2BYdrHV2wpXxUgWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 27, 2013 at 11:41 AM, Andrew W. Nosenko <andrew.w.nosenko@gmail.com> wrote: > On Wed, Mar 27, 2013 at 12:21 AM, Jeremy Messenger > <mezz.freebsd@gmail.com> wrote: >> On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko >> <andrew.w.nosenko@gmail.com> wrote: >>> On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger >>> <mezz.freebsd@gmail.com> wrote: >>>> 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. >>> >>> 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. What I mean by is that we can add more patches in gnome-libtool after copied from bin/libtool by change the CC and other stuff. Or change the configure to copy from gnome-libtool during the generate. > 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@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@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?CADLFttf=B56NafU7rvh2nt1pVvMN9-1gSF5iG4mLxa1iwfJinQ>