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 andrew.w.nose...@gmail.com wrote: On Wed, Mar 27, 2013 at 12:21 AM, Jeremy Messenger mezz.free...@gmail.com wrote: On Tue, Mar 26, 2013 at 11:52 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger mezz.free...@gmail.com wrote: On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger mezz.free...@gmail.com wrote: On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk 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 ger...@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 de...@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 g...@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 ===
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 ger...@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. 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 Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk 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 ger...@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 de...@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. 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.nose...@gmail.com ___ 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 andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk 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 ger...@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 de...@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. 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.nose...@gmail.com ___ 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 2:49 PM, Jeremy Messenger mezz.free...@gmail.com wrote: On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht me...@bristol.ac.uk 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 ger...@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 de...@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.nose...@gmail.com ___ 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 10:00 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
me...@bristol.ac.uk 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
ger...@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 de...@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. 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 andrew.w.nose...@gmail.com
--
mezz.free...@gmail.com - m...@freebsd.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - gn...@freebsd.org
___
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
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
me...@bristol.ac.uk 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
ger...@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 de...@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
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
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 5:46 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 10:00 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 2:49 PM, Jeremy Messenger
mezz.free...@gmail.com wrote:
On Tue, Mar 26, 2013 at 6:33 AM, Andrew W. Nosenko
andrew.w.nose...@gmail.com wrote:
On Tue, Mar 26, 2013 at 12:50 PM, Anton Shterenlikht
me...@bristol.ac.uk 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
ger...@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 de...@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
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)? 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
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?
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?
On Mon, Mar 25, 2013 at 5:59 PM, Gerald Pfeifer ger...@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. 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 andrew.w.nose...@gmail.com ___ 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?
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
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?
On 02/11/13 09:21, Gerald Pfeifer wrote: Hi Anton, On Thu, 7 Feb 2013, Anton Shterenlikht wrote: snip 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 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: snip 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
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
