Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
>> @@ -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 " Do you know if this part is need too? You can try to patch the CC and other stuff by tweak in Mk/bsd.gnome.mk example on CC (untest): -- ltverhack_PRE_PATCH=for file in gnome-ltmain.sh gnome-libtool; do \ if [ -f ${WRKDIR}/$$file ]; then \ ${REINPLACE_CMD} -e \ '/freebsd-elf)/,/;;/ s|major="\.$$current"|${ltverhack_LIB_VERSION}|; \ /freebsd-elf)/,/;;/ s|versuffix="\.$$current"|versuffix="$$major"|; /CC=/s|CC=.*|CC=${CC}|g' \ ${WRKDIR}/$$file; \ fi; \ done -- -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Wed, Mar 27, 2013 at 11:41 AM, Andrew W. Nosenko wrote: > On Wed, Mar 27, 2013 at 12:21 AM, Jeremy Messenger > wrote: >> On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko >> wrote: >>> On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger >>> wrote: On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko wrote: > On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger > wrote: >> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko >> wrote: >>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht >>> wrote: From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 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 >>> 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 , 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 buildi
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko wrote: > On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger > wrote: >> On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko >> wrote: >>> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger >>> wrote: On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko wrote: > On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht > wrote: >> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 >> >> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer >> 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 > 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" MIght be has to do with http://svnweb.freebsd.org/ports/head/devel/libtool/files/patch-libltdl_config_ltmain.sh ? >> 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)?
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger wrote: > On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko > wrote: >> On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger >> wrote: >>> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko >>> wrote: On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht wrote: > From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 > > On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer > 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 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 >> reg
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko wrote: > On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger > wrote: >> On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko >> wrote: >>> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht >>> wrote: From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 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 >>> 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 -- mezz.free...@gmail.com - m...@freebsd.org FreeB
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger wrote: > On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko > wrote: >> On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht >> wrote: >>> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 >>> >>> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer >>> 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 >> 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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko wrote: > On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht > wrote: >> From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 >> >> On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer >> 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 > 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. > 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 > ___ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- mezz.free...@gmail.com - m...@freebsd.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gn...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht wrote: > From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 > > On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer > 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 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. 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 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From andrew.w.nose...@gmail.com Mon Mar 25 18:09:38 2013 On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 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. Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer 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. Reason, as I see it, the reality may be slightly different or more complex, but, I hope it will give a hint about direction: 1. glib'c configure checks whether -Bsymbolic-functions option is supported by linker (by passing it as -Wl,-Bsymbolic-functions through CC/CXX frontend) 2. Because gcc47 frontend calls /usr/local/lib/ld, which is fresh enough, the check passes as "supported". 3. configure registers gcc47 as linker frontend, generates libtool script, and so on... 4. At the real link time the port machinery hijacks invocations to the generated libtool scrips and redirects them to the own gnome-libtool, which know nothing about configure results, and which uses hardcoded "cc" instead of requested gcc47 5. cc is /usr/bin/cc aka gcc-4.2 in my case. It uses /usr/bin/ld (from base) instead of /usr/local/bin/ld (from ports). 6. Base version lf ld is old enough and know nothing about -Bsymbolic-functions flag. 7. As consequence, build finishes with linker error. Again: The description above may be inaccurate or wrong in details. I didn't investigate the problem throughly. But it is how it looks like. -- Andrew W. Nosenko ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
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. > Also, I saw that gcc48 is released. > Do you have any plans to make gcc49 port? I did so yesterday. :-) It should be in your ports tree with the next update. Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From ger...@pfeifer.com Mon Mar 18 00:32:16 2013 On Sat, 16 Mar 2013, Bryan Drewery wrote: >>> So I wonder if there are any side effects or unexpected >>> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? > I don't think this is working as expected. See also ports/177017 which I > believe is a bsd.gcc.mk issue and not a pkgng or portmaster issue. My > understanding is that this user want > > When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47 > package, but still is using lang/gcc: You're right! In addition to setting GCC_DEFAULT_VERSION to 4.7, one also needs to adjust the following in Mk/bsd.gcc.mk: . if ${_USE_GCC} == ${GCC_DEFAULT_VERSION} _GCC_PORT:= gcc . else _GCC_PORT:= gcc${V} . endif The most correct way of doing this would be replacing the first line by . if ${_USE_GCC} == 4.6 That should then do the right thing; or you could just remove everything except for _GCC_PORT:= gcc${V} Either should work. (I'd love to update GCC_DEFAULT_VERSION to 4.7 one of these days; is the cluster sufficiently recovered for a test run?) Gerald Hi Gerald 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. Also, I saw that gcc48 is released. Do you have any plans to make gcc49 port? Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From ger...@pfeifer.com Mon Mar 18 00:32:16 2013 On Sat, 16 Mar 2013, Bryan Drewery wrote: >>> So I wonder if there are any side effects or unexpected >>> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? > I don't think this is working as expected. See also ports/177017 which I > believe is a bsd.gcc.mk issue and not a pkgng or portmaster issue. My > understanding is that this user want > > When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47 > package, but still is using lang/gcc: You're right! In addition to setting GCC_DEFAULT_VERSION to 4.7, one also needs to adjust the following in Mk/bsd.gcc.mk: . if ${_USE_GCC} == ${GCC_DEFAULT_VERSION} _GCC_PORT:= gcc . else _GCC_PORT:= gcc${V} . endif The most correct way of doing this would be replacing the first line by . if ${_USE_GCC} == 4.6 yes, this solves my problem, thank you. However, it's not portable. When the default is no longer 4.6, but, say 4.7, then one would have to change this to 4.7, right? I understand that one should not just mess with bsd.gcc.mk at will, but would be great if only a single change was needed for situations like mine. Thank you Anton That should then do the right thing; or you could just remove everything except for _GCC_PORT:= gcc${V} Either should work. (I'd love to update GCC_DEFAULT_VERSION to 4.7 one of these days; is the cluster sufficiently recovered for a test run?) Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On Sat, 16 Mar 2013, Bryan Drewery wrote: >>> So I wonder if there are any side effects or unexpected >>> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? > I don't think this is working as expected. See also ports/177017 which I > believe is a bsd.gcc.mk issue and not a pkgng or portmaster issue. My > understanding is that this user want > > When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47 > package, but still is using lang/gcc: You're right! In addition to setting GCC_DEFAULT_VERSION to 4.7, one also needs to adjust the following in Mk/bsd.gcc.mk: . if ${_USE_GCC} == ${GCC_DEFAULT_VERSION} _GCC_PORT:= gcc . else _GCC_PORT:= gcc${V} . endif The most correct way of doing this would be replacing the first line by . if ${_USE_GCC} == 4.6 That should then do the right thing; or you could just remove everything except for _GCC_PORT:= gcc${V} Either should work. (I'd love to update GCC_DEFAULT_VERSION to 4.7 one of these days; is the cluster sufficiently recovered for a test run?) Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On 2/11/2013 9:21 AM, Gerald Pfeifer wrote: > Hi Anton, > > On Thu, 7 Feb 2013, Anton Shterenlikht wrote: >> Right now the default GCC is GCC_DEFAULT_VERSION=4.6 >> For some time lang/gcc46 doesn't build for me on ia64. >> However, lang/gcc47 and lang/gcc48 do. >> >> There are quite a few ports which I cannot update >> because they depend on lang/gcc46 via USE_FORTRAN=yes. >> >> So I wonder if there are any side effects or unexpected >> effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? > > this should work. In my experience most ports that work with > GCC 4.6 also should with GCC 4.7, and most have USE_GCC=4.6+ > anyway, so other users may well have built them with a later > version aleady. Hi Gerald, I don't think this is working as expected. See also ports/177017 which I believe is a bsd.gcc.mk issue and not a pkgng or portmaster issue. My understanding is that this user want When I change GCC_DEFAULT_VERSION to 4.7, it now depends on the gcc47 package, but still is using lang/gcc: > $ make -C lang/p5-ExtUtils-F77 -V RUN_DEPENDS > gcc47:/home/bryan/freebsd/ports/lang/gcc > /usr/local/bin/perl5.12.4:/home/bryan/freebsd/ports/lang/perl5.12 -- Regards, Bryan Drewery bdrewery@freenode/EFNet signature.asc Description: OpenPGP digital signature
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From jnagyjr1...@gmail.com Mon Feb 11 22:45:53 2013 On 02/11/13 09:21, Gerald Pfeifer wrote: > Hi Anton, > > On Thu, 7 Feb 2013, Anton Shterenlikht wrote: >> And anyway, 4.7 will be the default soon, right? > > That's what I have been hoping to do, yes. With the ports > build cluster being unavailable for months now, we simply > could not do the necessary testing though. > > Anyone who wants to give this a try, I'd be happy to see that. It was my understanding GCC any version is being phased out (at least as a default) in favor of clang/llvm? Has this changed? We are talking about lang/gcc4x, not the default OS compiler. Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
On 02/11/13 09:21, Gerald Pfeifer wrote: Hi Anton, On Thu, 7 Feb 2013, Anton Shterenlikht wrote: And anyway, 4.7 will be the default soon, right? That's what I have been hoping to do, yes. With the ports build cluster being unavailable for months now, we simply could not do the necessary testing though. Anyone who wants to give this a try, I'd be happy to see that. It was my understanding GCC any version is being phased out (at least as a default) in favor of clang/llvm? Has this changed? -- Yours in Christ, Joseph A Nagy Jr "Whoever loves instruction loves knowledge, But he who hates correction is stupid." -- Proverbs 12:1 Emails are not formal business letters, whatever businesses may want. Original content CopyFree (F) under the OWL http://copyfree.org/licenses/owl/license.txt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
From ger...@pfeifer.com Mon Feb 11 16:59:44 2013 Hi Anton, On Thu, 7 Feb 2013, Anton Shterenlikht wrote: > Right now the default GCC is GCC_DEFAULT_VERSION=4.6 > For some time lang/gcc46 doesn't build for me on ia64. > However, lang/gcc47 and lang/gcc48 do. > > There are quite a few ports which I cannot update > because they depend on lang/gcc46 via USE_FORTRAN=yes. > > So I wonder if there are any side effects or unexpected > effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? this should work. In my experience most ports that work with GCC 4.6 also should with GCC 4.7, and most have USE_GCC=4.6+ anyway, so other users may well have built them with a later version aleady. One or the other port may exhibit a compile problem, in which case that would be an excellent opportunity to file a report against it and inform its maintainer. > And anyway, 4.7 will be the default soon, right? That's what I have been hoping to do, yes. With the ports build cluster being unavailable for months now, we simply could not do the necessary testing though. Anyone who wants to give this a try, I'd be happy to see that. Gerald ok, sure, I'll try it on ia64 first. I'll get back to you Anton ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
Hi Anton, On Thu, 7 Feb 2013, Anton Shterenlikht wrote: > Right now the default GCC is GCC_DEFAULT_VERSION=4.6 > For some time lang/gcc46 doesn't build for me on ia64. > However, lang/gcc47 and lang/gcc48 do. > > There are quite a few ports which I cannot update > because they depend on lang/gcc46 via USE_FORTRAN=yes. > > So I wonder if there are any side effects or unexpected > effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? this should work. In my experience most ports that work with GCC 4.6 also should with GCC 4.7, and most have USE_GCC=4.6+ anyway, so other users may well have built them with a later version aleady. One or the other port may exhibit a compile problem, in which case that would be an excellent opportunity to file a report against it and inform its maintainer. > And anyway, 4.7 will be the default soon, right? That's what I have been hoping to do, yes. With the ports build cluster being unavailable for months now, we simply could not do the necessary testing though. Anyone who wants to give this a try, I'd be happy to see that. Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
is it a good idea to overwrite GCC_DEFAULT_VERSION= in Mk/bsd.gcc.mk?
Hi Gerald Right now the default GCC is GCC_DEFAULT_VERSION=4.6 For some time lang/gcc46 doesn't build for me on ia64. However, lang/gcc47 and lang/gcc48 do. There are quite a few ports which I cannot update because they depend on lang/gcc46 via USE_FORTRAN=yes. So I wonder if there are any side effects or unexpected effects if I just change GCC_DEFAULT_VERSION= to e.g. 4.7? I know there are also ways to require a specific GCC version for a specific port via /etc/make.conf, however, this seems tedious. And anyway, 4.7 will be the default soon, right? Please comment ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"