Re: PKGNG: virtualbox-ose wants lang/gcc AND pdftk wants lang/gcc46
+--On 12 janvier 2014 03:00:53 +0100 vermaden verma...@interia.pl wrote: | Where is the logic?I can not install lang/gcc and lang/gcc46 both at the | same time.Any hints? How to use BOTH virtualbox and pdftk using | PKGNG? Hum, I fixed this on January 4th[1], so it should be fixed in the current packages set. 1: http://www.freshports.org/print/pdftk -- Mathieu Arnold ___ 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: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc
On 23 December 2013 08:36, Bernhard Fröhlich de...@bluelife.at wrote: Am 22.12.2013 21:57 schrieb Dirk Meyer dirk.me...@dinoex.sub.org: Opera has an option to pick your poison. you can set COMPAT9, which does conflict with virtualbox. No it does not conflict anymore. That has been fixed already. Only a remark: the goal is install emulators/virtualbox-ose-additions and www/opera on a VirtualBox FreeBSD 10.0RC2. I have found a workaround: 1- First, install emulators/virtualbox-ose-additions with pkgng. Then you will get /usr/local/lib/gcc46/libstdc++.so.6 installed by lang/gcc port. 2- Install www/opera from ports: cd /usr/ports/www/opera make install clean. This trick works as the port only check the installation of the libstdc++.so.6; it does not care the which package installed the library. Yes, there are some corner cases you need the flexibility of the port system :-) Best regards ___ 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: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc
Am 23.12.2013 11:10 schrieb José García Juanino jjuan...@gmail.com: On 23 December 2013 08:36, Bernhard Fröhlich de...@bluelife.at wrote: Am 22.12.2013 21:57 schrieb Dirk Meyer dirk.me...@dinoex.sub.org: Opera has an option to pick your poison. you can set COMPAT9, which does conflict with virtualbox. No it does not conflict anymore. That has been fixed already. Only a remark: the goal is install emulators/virtualbox-ose-additions and www/opera on a VirtualBox FreeBSD 10.0RC2. I have found a workaround: 1- First, install emulators/virtualbox-ose-additions with pkgng. Then you will get /usr/local/lib/gcc46/libstdc++.so.6 installed by lang/gcc port. 2- Install www/opera from ports: cd /usr/ports/www/opera make install clean. This trick works as the port only check the installation of the libstdc++.so.6; it does not care the which package installed the library. Yes, there are some corner cases you need the flexibility of the port system :-) Best regards Yeah, that should work fine and my proposal was to change opera to depend on lang/gcc instead of lang/gcc46 because it is what most ports will use on FreeBSD 10. ___ 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: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-12-23 05:10:05 -0500, José García Juanino wrote: On 23 December 2013 08:36, Bernhard Fröhlich de...@bluelife.at wrote: Am 22.12.2013 21:57 schrieb Dirk Meyer dirk.me...@dinoex.sub.org: Opera has an option to pick your poison. you can set COMPAT9, which does conflict with virtualbox. No it does not conflict anymore. That has been fixed already. Only a remark: the goal is install emulators/virtualbox-ose-additions and www/opera on a VirtualBox FreeBSD 10.0RC2. I have found a workaround: 1- First, install emulators/virtualbox-ose-additions with pkgng. Then you will get /usr/local/lib/gcc46/libstdc++.so.6 installed by lang/gcc port. 2- Install www/opera from ports: cd /usr/ports/www/opera make install clean. This trick works as the port only check the installation of the libstdc++.so.6; it does not care the which package installed the library. Yes, there are some corner cases you need the flexibility of the port system :-) emulators/virtualbox-ose-additions can be built with clang and used with libc++ just fine. All you need is the following patches: https://redports.org/browser/jkim/emulators/virtualbox-ose-additions/files/extrapatch-src-VBox-Additions-x11-VBoxClient-Makefile.kmk https://redports.org/browser/jkim/emulators/virtualbox-ose-additions/files/extrapatch-src-VBox-Additions-x11-vboxvideo-Makefile.kmk The port maintainers did not like them, though. :-( Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJSuKIoAAoJEHyflib82/FGWFIH/jhBXA+qslegHzE7ikNGSK2z FajfbU+uHi0TygtGoQxgg8O0lDWbTvUFOtzL6+h+AgE0vjg1QmaUxkl8AUfwi/oi 1SViTxr/hEVDB/1yq7XbPXCkZxp/3UKiQST2/i8kTrIXnGbGgI3BcgrcDNsGRiqL +43lvKieI1DfIX7Zpi3hunABYTLRTX41BSimv/8XwCfdEgd/w2IMRvj+FKWAQ337 2O8slnkhIIm3fqQgKPzJRNdZb38OdCu8Mc+GSSVMsft/MC1Kb1AgHWqJabAmewz3 icy7d40BbCPrzRrj6KGndqI9VDQJdWF6yNFHsv6RTxZH7JttignBL0txlFs5a/Q= =9wdZ -END PGP SIGNATURE- ___ 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: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc
Am 22.12.2013 12:13 schrieb José García Juanino jjuan...@gmail.com:
Hello,
I have running a recent FreeBSD 10.0-RC2, and I get the following
scenario:
www/opera depends on lang/gcc46
devel/kBuild depends on lang/gcc
But both gcc46 and gcc are incompatible, so I cannot install opera and
kBuild. However, lang/gcc and lang/gcc46 install the same versión compiler
4.6.4. Any idea to fix this conflict? I am using pkgng to install the
ports.
kBuild is using USE_GCC=yes which uses lang/gcc right now in version 4.6.
Opera has a strict dependency on on FreeBSD 10 for gcc4.6 because of
libstdc++.so.6.
RUN_DEPENDS+= ${LOCALBASE}/lib/gcc46/libstdc++.so.6:${PORTSDIR}/lang/gcc46
I am not sure if opera really needs to be that strict on which libstdc++ it
uses since it also seems to be happy with libstdc++ from gcc 4.2 on FreeBSD
9.
I've cc'd the opera maintainer so let's see what he thinks.
___
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: kBuild and opera will not install in 10.0: lang/gcc46 conflicts with lang/gcc
Am 22.12.2013 21:57 schrieb Dirk Meyer dirk.me...@dinoex.sub.org: Bernhard Fröhlich schrieb:, Am 22.12.2013 12:13 schrieb Jos=E9 Garc=EDa Juanino jjuan...@gmail.com: I have running a recent FreeBSD 10.0-RC2, and I get the following scenario: www/opera depends on lang/gcc46 devel/kBuild depends on lang/gcc But both gcc46 and gcc are incompatible, so I cannot install opera and kBuild. However, lang/gcc and lang/gcc46 install the same versi=F3n compi= ler 4.6.4. Any idea to fix this conflict? I am using pkgng to install the ports. kBuild is using USE_GCC=3Dyes which uses lang/gcc right now in version 4.6. Opera has a strict dependency on on FreeBSD 10 for gcc4.6 because of libstdc++.so.6. In C++ you can not reuse your libraries without recompilation. This breaks the goal of object oriented design as stated in several books. Why does opera work fine with libstdc++ from gcc 4.2 then? Opera has an option to pick your poison. you can set COMPAT9, which does conflict with virtualbox. No it does not conflict anymore. That has been fixed already. ___ 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: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Saturday, 23 November 2013 03:00:54 Gerald Pfeifer wrote: On Sat, 23 Nov 2013, Baptiste Daroussin wrote: This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? Yes. I just tested this, and in my environment it seems to work (passing the tests described in the Handbook). ports/184178 when you commit this. :) Thank you both for addressing this so quickly :-D signature.asc Description: This is a digitally signed message part.
lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
Hi All / Gerald, The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. If this has been fixed, my apologies for the noise. Regards On Thursday, 21 November 2013 20:25:41 Ports-QAT wrote: Add stage support for games/knights-kde4. - Build ID: 20131118181800-45853 Job owner: d...@freebsd.org Buildtime: 3 days Enddate: Thu, 21 Nov 2013 20:25:39 GMT Revision: r334234 Repository: https://svnweb.freebsd.org/ports?view=revisionrevision=334234 - Port:games/knights-kde4 2.5.0_2 Buildgroup: 8.4-QAT/amd64 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228516/knig hts-2.5.0_2.log Buildgroup: 8.4-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228517/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/amd64 Buildstatus: DEPEND_OBJECT Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228518/knig hts-2.5.0_2.log Buildgroup: 9.2-QAT/i386 Buildstatus: LEFTOVERS Log: https://qat.redports.org//~d...@freebsd.org/20131118181800-45853-228519/knig hts-2.5.0_2.log -- Buildarchive URL: https://qat.redports.org/buildarchive/20131118181800-45853 redports https://qat.redports.org/ signature.asc Description: This is a digitally signed message part.
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Fri, 22 Nov 2013, David Naylor wrote: The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. This is _not_ an issue with lang/gcc46, but with the general ports infrastructure that I first reported on October 23rd. Bapt had a first patch a week ago http://people.freebsd.org/~bapt/info-dir.diff This indeed removed the stray info/ directory, but caused the following upon `make deinstall` in my testing: /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) : I just committed a workaround to lang/gcc46, will work on lang/gcc next, and filed PR ports/184178 to track this on the infrastructure side. 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: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Fri, Nov 22, 2013 at 11:05:04PM +0100, Gerald Pfeifer wrote: On Fri, 22 Nov 2013, David Naylor wrote: The following reports indicate that /usr/local/share/info/gcc46 (directory) is being left in the working environment and not properly cleaned up. Since the ports do not create or use anything in that directory I assume this is an issue with the lang/gcc46 port. This is _not_ an issue with lang/gcc46, but with the general ports infrastructure that I first reported on October 23rd. Bapt had a first patch a week ago http://people.freebsd.org/~bapt/info-dir.diff This indeed removed the stray info/ directory, but caused the following upon `make deinstall` in my testing: /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) /scratch2/tmp/gerald/prefix/gcc47/info/gcc47/dir: could not read (No such file or directory) and could not create (No such file or directory) : I just committed a workaround to lang/gcc46, will work on lang/gcc next, and filed PR ports/184178 to track this on the infrastructure side. Gerald This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff Sorry about it. Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? regards, Bapt pgprgXXRB8Ewq.pgp Description: PGP signature
Re: lang/gcc46 leaving directories around (WAS: [QAT] r334234: 3x leftovers, 1x depend_object)
On Sat, 23 Nov 2013, Baptiste Daroussin wrote: This should be a definitive fix: http://people.freebsd.org/~bapt/fix-info-subdir.diff : Btw that have shown a bug in pkg 1.2.0 rc1 and prior (not in 1.1.x) I have fix in master and will be in 1.2.0 rc2 Can you test? Yes. I just tested this, and in my environment it seems to work (passing the tests described in the Handbook). ports/184178 when you commit this. :) Thanks, 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: lang/gcc46
On Mon, 6 Aug 2012, b. f. wrote: Oops: I forgot though, that partly due to this policy of not bumping gcc shared library versions, we have some shared libraries in the base system that conflict with the shared libraries of the various gcc ports, and we have been enforcing the right links by inscribing hints in the binaries to look first in the right gcc port directories. But if we update lang/gcc from 4.6.x to another major version (e.g. 4.7.x), the directory changes, and linking for the old binaries will fail. So let me qualify my earlier answer: you can keep the old software working with minimal intervention, for example, by adding a symlink from the old directory to the new one. What we could do, for the canonical version of GCC (lang/gcc, USE_GCC=yes) is install those libraries into /usr/local/lib instead of /usr/local/lib/gccXY as we are doing for lang/gccXY. What do you think? I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that Making this change now would benefit a lot of people, now. Okay, but since I'm not in charge either, it will require (at least) Gerald's consent. That would be cool. Bapt wanted to look into this as well a few months ago, so perhaps the two of you can (should?) sync before proceeding? Gerald PS: I don't think we should go for the other option, static linking. ___ 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: lang/gcc46
Sorry for the formatting. Reply is below --- On Fri, 12/28/12, Gerald Pfeifer ger...@pfeifer.com wrote: From: Gerald Pfeifer ger...@pfeifer.com Subject: Re: lang/gcc46 To: Brendan Fabeny bf1...@gmail.com, Baptiste Daroussin b...@freebsd.org Cc: freebsd-ports@freebsd.org, Kevin Oberman kob6...@gmail.com Date: Friday, December 28, 2012, 4:08 PM On Mon, 6 Aug 2012, b. f. wrote: Oops: I forgot though, that partly due to this policy of not bumping gcc shared library versions, we have some shared libraries in the base system that conflict with the shared libraries of the various gcc ports, and we have been enforcing the right links by inscribing hints in the binaries to look first in the right gcc port directories. But if we update lang/gcc from 4.6.x to another major version (e.g. 4.7.x), the directory changes, and linking for the old binaries will fail. So let me qualify my earlier answer: you can keep the old software working with minimal intervention, for example, by adding a symlink from the old directory to the new one. What we could do, for the canonical version of GCC (lang/gcc, USE_GCC=yes) is install those libraries into /usr/local/lib instead of /usr/local/lib/gccXY as we are doing for lang/gccXY. What do you think? I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that Making this change now would benefit a lot of people, now. Okay, but since I'm not in charge either, it will require (at least) Gerald's consent. That would be cool. Bapt wanted to look into this as well a few months ago, so perhaps the two of you can (should?) sync before proceeding? Gerald PS: I don't think we should go for the other option, static linking. ___ 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 ..not a reply but additional information, I hope it is not to off-topic to this post. While trying to install gcc46, it wanted gcc46 already installed for some reason. I had just deleted it for the install. I did a workaround of sorts... ___ 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: lang/gcc46: .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER', rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER];
Date: Wed, 07 Nov 2012 17:48:35 +0100 From: O. Hartmann ohart...@zedat.fu-berlin.de To: Ports FreeBSD freebsd-ports@freebsd.org Subject: lang/gcc46: .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER', rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; On one of my FreeBSD 10-CURRENT boxes (FreeBSD 10.0-CURRENT #3 r242674M: Tue Nov 6 22:36:47 CET 2012) I get surprisingly the following error while upgrading the compiler port lang/gcc46. The bos in question is most recent updated kernel/world sources, compiled with CLANG and having CLANG set so far as the default compiler (clang is now cc). The port compiled prior to the switch to CLANG as the default also with CLANG without problem! The couriosity is that I also run two other boxes, also the very same sources for the OS and the most recent updated /usr/ports tree. Those boxes are modern hardware, Sandy-Bridge and Ivy-Bridge, the failing box is Core2Duo, I mention this here since I use -O3 and -march=3Dnative in the compiler options on ALL machines and I also compil= e the sources with option CXXFLAGS=3D -stdlib=3Dlibc++ -std=3Dc++11 set in /etc/src.conf. The shwon below error sounds weird, since the other boxes have compiled the very same day the port lang/gcc has been updated the very same port without problems. Since I spread arounf the boxes my /etc/make.conf and /etc/src.conf for FreeBSD 10.0-CURRENT, I'm very sure that I do not use other flags on the failing system. Any ideas? Regards, Oliver =3D=3D=3D=3D=3D cc -c -O3 -pipe -fno-strict-aliasing -march=3Dnative -march=3Dnative -I/usr/local/include -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.6-20121102/gcc -I.././../gcc-4.6-20121102/gcc/build -I.././../gcc-4.6-20121102/gcc/../include -I.././../gcc-4.6-20121102/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.6-20121102/gcc/../libdecnumber -I.././../gcc-4.6-20121102/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include \ -o build/genflags.o .././../gcc-4.6-20121102/gcc/genflags.c In file included from .././../gcc-4.6-20121102/gcc/genflags.c:28: =2E././../gcc-4.6-20121102/gcc/rtl.h:1989:13: warning: ISO C forbids forward references to 'enum' types [-Wpedantic] extern enum reg_class reg_preferred_class (int); ^ =2E././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; ^ =2E././../gcc-4.6-20121102/gcc/rtl.h:2112:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_static_reg_base_value[FIRST_PSEUDO_REGISTER]; ^ 1 warning and 2 errors generated. gmake[2]: *** [build/genflags.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc46. *** [build] Error code 1 Stop in /usr/ports/lang/gcc46. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55221 I thought it was just me on ia64. 4.7 updated fine: === Upgrade of gcc-4.7.3.20121013 to gcc-4.7.3.20121103 complete 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
lang/gcc46: .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER', rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER];
On one of my FreeBSD 10-CURRENT boxes (FreeBSD 10.0-CURRENT #3 r242674M: Tue Nov 6 22:36:47 CET 2012) I get surprisingly the following error while upgrading the compiler port lang/gcc46. The bos in question is most recent updated kernel/world sources, compiled with CLANG and having CLANG set so far as the default compiler (clang is now cc). The port compiled prior to the switch to CLANG as the default also with CLANG without problem! The couriosity is that I also run two other boxes, also the very same sources for the OS and the most recent updated /usr/ports tree. Those boxes are modern hardware, Sandy-Bridge and Ivy-Bridge, the failing box is Core2Duo, I mention this here since I use -O3 and -march=native in the compiler options on ALL machines and I also compile the sources with option CXXFLAGS= -stdlib=libc++ -std=c++11 set in /etc/src.conf. The shwon below error sounds weird, since the other boxes have compiled the very same day the port lang/gcc has been updated the very same port without problems. Since I spread arounf the boxes my /etc/make.conf and /etc/src.conf for FreeBSD 10.0-CURRENT, I'm very sure that I do not use other flags on the failing system. Any ideas? Regards, Oliver = cc -c -O3 -pipe -fno-strict-aliasing -march=native -march=native -I/usr/local/include -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I.././../gcc-4.6-20121102/gcc -I.././../gcc-4.6-20121102/gcc/build -I.././../gcc-4.6-20121102/gcc/../include -I.././../gcc-4.6-20121102/gcc/../libcpp/include -I/usr/local/include -I.././../gcc-4.6-20121102/gcc/../libdecnumber -I.././../gcc-4.6-20121102/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/local/include \ -o build/genflags.o .././../gcc-4.6-20121102/gcc/genflags.c In file included from .././../gcc-4.6-20121102/gcc/genflags.c:28: .././../gcc-4.6-20121102/gcc/rtl.h:1989:13: warning: ISO C forbids forward references to 'enum' types [-Wpedantic] extern enum reg_class reg_preferred_class (int); ^ .././../gcc-4.6-20121102/gcc/rtl.h:2105:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_initial_regno_reg_rtx[FIRST_PSEUDO_REGISTER]; ^ .././../gcc-4.6-20121102/gcc/rtl.h:2112:31: error: use of undeclared identifier 'FIRST_PSEUDO_REGISTER' rtx x_static_reg_base_value[FIRST_PSEUDO_REGISTER]; ^ 1 warning and 2 errors generated. gmake[2]: *** [build/genflags.o] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc46/work/build/gcc' gmake[1]: *** [all-gcc] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc46/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc46. *** [build] Error code 1 Stop in /usr/ports/lang/gcc46. signature.asc Description: OpenPGP digital signature
Re: lang/gcc46 dependency loop on lang/gcc
Me: Life Happened(tm), which means I'll get to this first thing tomorrow, Back on the job. Steps so far: 1) de-installed gcc46 2) removed suspect parts of make.conf 3) installed gcc48 4) de-installed gcc48 5) added back major suspect parts of make.conf, but removed line involving lang/gcc 6) installed gcc46 7) added back line involving lang/gcc 8) built gcc46 9) added back rest of suspect parts 10) built gcc46 11) used portmaster to re-build/re-install gcc46 All steps succeeded. Whatever the breakage is, it has - at least for the moment - gone away. No idea what it was. Thanks for the help. Sorry for the interruption for what appears to be a local error, Robert Huff ___ 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: lang/gcc46 dependency loop on lang/gcc
On 8/27/2012 2:35 PM, Doug Barton wrote: Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. This would seem to be an error in the bsd.gcc.mk logic, or perhaps an error in one of the ports' Makefiles, not sure yet. Any chance you could look into this? Doug I believe this was reported in ports/171135 as well for lang/gcc47. Received in private email: --- Installing the new version via the port === Installing for gcc-4.7.2.20120825 === gcc-4.7.2.20120825 depends on file: /usr/local/bin/as - found === gcc-4.7.2.20120825 depends on executable: gcc47 - not found ===Verifying reinstall for gcc47 in /usr/ports/lang/gcc47 ... (more than 100) make: Max recursion level (500) exceeded. *** Error code 2 Stop in /usr/ports/lang/gcc47. *** Error code 1 ... (more than 100) ___ 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: lang/gcc46 dependency loop on lang/gcc
Hello all, I have tested in a new freebsd 9.0. only install gcc47 then upgrade it. 在 2012-8-29，上午3:15，Bryan Drewery br...@shatow.net 写道： On 8/27/2012 2:35 PM, Doug Barton wrote: Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. This would seem to be an error in the bsd.gcc.mk logic, or perhaps an error in one of the ports' Makefiles, not sure yet. Any chance you could look into this? Doug I believe this was reported in ports/171135 as well for lang/gcc47. Received in private email: --- Installing the new version via the port === Installing for gcc-4.7.2.20120825 === gcc-4.7.2.20120825 depends on file: /usr/local/bin/as - found === gcc-4.7.2.20120825 depends on executable: gcc47 - not found ===Verifying reinstall for gcc47 in /usr/ports/lang/gcc47 ... (more than 100) make: Max recursion level (500) exceeded. *** Error code 2 Stop in /usr/ports/lang/gcc47. *** Error code 1 ... (more than 100) ___ 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: lang/gcc46 dependency loop on lang/gcc
On 08/28/2012 01:44 PM, Gerald Pfeifer wrote: On Mon, 27 Aug 2012, Doug Barton wrote: This would seem to be an error in the bsd.gcc.mk logic, or perhaps an error in one of the ports' Makefiles, not sure yet. Any chance you could look into this? I had done that when Robert contacted me first and could not find anything. FYI, Robert has some interesting stuff in make.conf that he is commenting out and testing. For future reference, if a user approaches you(pl.) about a problem compiling your port with portmaster the easiest way to determine if portmaster is a suspect or not is to ask the user to try the same action without using portmaster. In this case I'm pretty confident that this would have shown that portmaster was not the issue. Aside from my concern about using my time most effectively, I like to see the users get help ASAP. Any chance portmaster could tell us where the loop comes from? I looked at the -v option, but that one did not seem to provide this information and I feel stuck right now. As I pointed out earlier, it's 'make build-depends-list' But as for being stuck, I'm waiting on Robert to report his findings on which make.conf option hung him up. Is it possible you have some special setting somewhere, Robert, like USE_GCC=... as a global setting somewhere? (Though, shouldn't even that work with portmaster assuming that this part of the process, forcing deinstallation of the old version and installing a new package, does not depend on any other ports?) Portmaster waits until it builds the new thing successfully before uninstalling the old thing. Doug ___ 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: lang/gcc46 dependency loop on lang/gcc
Doug Barton writes: But as for being stuck, I'm waiting on Robert to report his findings on which make.conf option hung him up. Life Happened(tm), which means I'll get to this first thing tomorrow, Robert Huff ___ 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: lang/gcc46 dependency loop on lang/gcc
On 08/28/2012 03:12 PM, Robert Huff wrote: Doug Barton writes: But as for being stuck, I'm waiting on Robert to report his findings on which make.conf option hung him up. Life Happened(tm), which means I'll get to this first thing tomorrow, Sure, of course. :) I just wanted to let Gerald know he was off the hook for debugging this until we hear back from you. Doug ___ 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
lang/gcc46 dependency loop on lang/gcc
Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. This would seem to be an error in the bsd.gcc.mk logic, or perhaps an error in one of the ports' Makefiles, not sure yet. Any chance you could look into this? Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46 dependency loop on lang/gcc
On Mon, Aug 27, 2012 at 12:35:14PM -0700, Doug Barton wrote: Gerald, It seems that if lang/gcc46 is installed, and then you attempt to update it, lang/gcc shows up in the output of build-depends-list, run-depends-list, or perhaps both. If lang/gcc46 is not installed already, this doesn't happen. FWIW, on the machine on which I'm writing this note, I successfully performed an: Upgrade of gcc-4.6.4.20120608 to gcc-4.6.4.20120817 yesterday without incident (using portmaster). The machine is now running: FreeBSD albert.catwhisker.org 8.3-STABLE FreeBSD 8.3-STABLE #560 239646M: Fri Aug 24 04:21:00 PDT 2012 r...@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/ALBERT i386 (and had been updated to that just prior to the portmaster run). The ports tree is maintained as an SVN working copy; it was @303183 as of the time of the update in question. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpCdMvKCnRqQ.pgp Description: PGP signature
Re: lang/gcc46 dependency loop on lang/gcc
On 8/27/2012 12:44 PM, David Wolfskill wrote: FWIW, on the machine on which I'm writing this note, I successfully performed an: Upgrade of gcc-4.6.4.20120608 to gcc-4.6.4.20120817 yesterday without incident (using portmaster). Do you have lang/gcc installed, or lang/gcc46? pkg_info -qo gcc-4.6\* Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46 dependency loop on lang/gcc
On Mon, Aug 27, 2012 at 12:46:27PM -0700, Doug Barton wrote: ... Do you have lang/gcc installed, or lang/gcc46? pkg_info -qo gcc-4.6\* albert(8.3-S)[5] pkg_info -qo gcc-4.6\* lang/gcc46 albert(8.3-S)[6] Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgp41acYGQzOI.pgp Description: PGP signature
Re: lang/gcc46
On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: skipping quibbles and polemics Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. The upstream developers have a policy of avoiding version bumps for the runtime support libraries when possible, and instead using symbol versioning to maintain backward-compatibility. Only a very few pieces of software using libgcj or libobjc will have to be recompiled. For default packages, IIRC, that is only print/pdftk. Of course, it will be to the advantage of most users to recompile their packages with the new version of the compiler. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with that). I don't know of any magic solutions in the works that will solve the separation of libgcc from the compiler. :) I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. b. ___ 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: lang/gcc46
On 08/06/2012 00:30, b. f. wrote: On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: skipping quibbles and polemics Sure, whatever. Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. In my mind, this isn't good enough. But I'm not in charge of anything. :) I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. Universal support for that is years away, minimum. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. Making this change now would benefit a lot of people, now. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46
On 8/6/12, Doug Barton do...@freebsd.org wrote: On 08/06/2012 00:30, b. f. wrote: On 8/6/12, Doug Barton do...@freebsd.org wrote: On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. For the most part, yes. In my mind, this isn't good enough. But I'm not in charge of anything. :) Oops: I forgot though, that partly due to this policy of not bumping gcc shared library versions, we have some shared libraries in the base system that conflict with the shared libraries of the various gcc ports, and we have been enforcing the right links by inscribing hints in the binaries to look first in the right gcc port directories. But if we update lang/gcc from 4.6.x to another major version (e.g. 4.7.x), the directory changes, and linking for the old binaries will fail. So let me qualify my earlier answer: you can keep the old software working with minimal intervention, for example, by adding a symlink from the old directory to the new one. I think Gerald was referring to Bapt's plan to make it easier to make multiple packages from a single port, so that those who used packages exclusively could install a package consisting of only the runtime support libraries, rather than the whole compiler suite. Universal support for that is years away, minimum. I had patches to do this even without pkgng, but it made things a little more complicated, and didn't seem to be a high priority, so I didn't pursue it. If people feel that it is important, I could work with Gerald to revive that, or use a knob like that of ports/155408 with static linking to allow users to remove the runtime dependency for a lot of software, at the cost of some added overhead from redundancies. Making this change now would benefit a lot of people, now. Okay, but since I'm not in charge either, it will require (at least) Gerald's consent. And if you adopt the latter approach, it won't be one size fits all: it may make sense to use static linking to the support libraries for default packages, of which a comparatively few are built with lang/gcc4*, but it will be less suitable for those who routinely use lang/gcc4* for most if not all of their packages. b. ___ 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: lang/gcc46
On 07/31/2012 08:57, Gerald Pfeifer wrote: On Sun, 29 Jul 2012, Doug Barton wrote: lang/gcc and lang/gcc46 should be fully compatible, without rebuilds necessary. Only when lang/gcc is going to move to GCC 4.7 later this year would I consider that. IMO this highlights the issue that unversioned instances of ports that really need versioning (like gcc) are a bad idea. It's much better for users to be able to tie their installations to a particular version, and then only update when they need to. The fact that someday in the future users who innocently upgrade lang/gcc will suddenly find that everything relying on libgcc at runtime is now broken pretty much speaks for itself. The fact that I would consider that, was not supposed to imply breakage. :-) I was more thinking better optimization and other benefits. I'm not asking you to agree with me that the current situation is broken. I'm merely pointing out that it *is* broken, and pointing out solid, non-broken examples that we already have. In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y run-times quite successfully and without any breakage more than once. And we've got many, quite many, users. Just to be clear, you compile stuff with gcc 4.6, that is linked against libgcc, and then you update to 4.7, with a new libgcc, and everything still works? If so, that's great, I'm glad to hear that it's not a problem. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with that). I don't know of any magic solutions in the works that will solve the separation of libgcc from the compiler. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46
On Sun, 29 Jul 2012, Doug Barton wrote: lang/gcc and lang/gcc46 should be fully compatible, without rebuilds necessary. Only when lang/gcc is going to move to GCC 4.7 later this year would I consider that. IMO this highlights the issue that unversioned instances of ports that really need versioning (like gcc) are a bad idea. It's much better for users to be able to tie their installations to a particular version, and then only update when they need to. The fact that someday in the future users who innocently upgrade lang/gcc will suddenly find that everything relying on libgcc at runtime is now broken pretty much speaks for itself. The fact that I would consider that, was not supposed to imply breakage. :-) I was more thinking better optimization and other benefits. In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y run-times quite successfully and without any breakage more than once. And we've got many, quite many, users. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with 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: lang/gcc46 building stuff in $TMPDIR
On Sun, 29 Jul 2012, Doug Barton wrote: My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. That could be done, but has one significant drawback: those of us who have /tmp on fastest storage, and $WRKDIR on slower storage, could lose a lot of speed. Have you measured that? 1:15:27 for a full build of lang/gcc48 when /tmp was used, versus 1:34:25 on the same system when TMPDIR was set to a network drive. This is just one scenario, and it may go both ways. It does show that having temporary files on fast storage is significant. [i386 host, build including Java, storage on spindles.] Finally, you indicated that you also saw Java create a large temporary file. If you want to avoid building Java, the GCC ports have an option to disable Java. Reducing functionality to handle build infrastructure problems is not a desirable solution. But thanks for the response in any case. :) Reducing functionality if that cuts the cost of building in half and you do not actually use that functionality (only a single port does, from what I know) actually looks quite desirable to me. ;-) 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: lang/gcc46 building stuff in $TMPDIR
On Sat, 9 Jun 2012, Doug Barton wrote: Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. That could be done, but has one significant drawback: those of us who have /tmp on fastest storage, and $WRKDIR on slower storage, could lose a lot of speed. Also, while I understand your situation, I am very hesitant to change any defaults given that I have not seen any other user reports, not even upstream. Note: according to the GCC documentation If `TMPDIR' is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Does it make a difference for you if you set TMPDIR to some location where you have more storage? On Tue, 10 Jul 2012, Doug Barton wrote: Just tried building the latest, same error. Did I misunderstand that something was supposed to be different? I believe lang/gcc47 has seen a split of one large, automatically generated, source file which is what you may have run into. So going for that (and I plan on moving lang/gcc to GCC 4.7 in the not too far future) could be one option. Another might be reducing the amount of parallel building on your system. Finally, you indicated that you also saw Java create a large temporary file. If you want to avoid building Java, the GCC ports have an option to disable Java. Let me actually take this as a trigger to convert this to the new options framework. 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: lang/gcc46 building stuff in $TMPDIR
On 07/29/2012 13:50, Gerald Pfeifer wrote: On Sat, 9 Jun 2012, Doug Barton wrote: Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. That could be done, but has one significant drawback: those of us who have /tmp on fastest storage, and $WRKDIR on slower storage, could lose a lot of speed. Have you measured that? Also, while I understand your situation, I am very hesitant to change any defaults given that I have not seen any other user reports, not even upstream. It's doubtful that others have a tiny /tmp like I do, but reproducing the problem is trivial. Note: according to the GCC documentation If `TMPDIR' is set, it specifies the directory to use for temporary files. GCC uses temporary files to hold the output of one stage of compilation which is to be used as input to the next stage: for example, the output of the preprocessor, which is the input to the compiler proper. Does it make a difference for you if you set TMPDIR to some location where you have more storage? Obviously. :) On Tue, 10 Jul 2012, Doug Barton wrote: Just tried building the latest, same error. Did I misunderstand that something was supposed to be different? I believe lang/gcc47 has seen a split of one large, automatically generated, source file which is what you may have run into. I haven't gotten into 47 yet. Another might be reducing the amount of parallel building on your system. Finally, you indicated that you also saw Java create a large temporary file. If you want to avoid building Java, the GCC ports have an option to disable Java. Let me actually take this as a trigger to convert this to the new options framework. Reducing functionality to handle build infrastructure problems is not a desirable solution. But thanks for the response in any case. :) Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46
On Tue, 13 Dec 2011, b. f. wrote:
Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not
seem like this should be too difficult. Just a matter of the right
person having the time. Would ports specifying gcc46 need to be
touched?
Gerald had planned to do this after the ports tree had been completely
unfrozen. It is likely that only a few dependent ports will have to be
changed. You can make this change now, simply by removing lang/gcc46
and installing lang/gcc, and then rebuilding all dependent ports (this
last step may not be necessary in many cases, but it is better to be
safe).
lang/gcc and lang/gcc46 should be fully compatible, without rebuilds
necessary. Only when lang/gcc is going to move to GCC 4.7 later this
year would I consider that.
Or you can try something like the attached patch, which will fix the
dependency accounting -- but you will then have to replace
_GCC_BUILD_DEPENDS with _GCC_PORT_DEPENDS (the latter will then be a
misnomer) in math/atlas, math/atlas-devel, math/gotoblas, math/R,
net-p2p/eiskaltdcpp-* (and soon perhaps also lang/libobjc2, if it is
altered to use USE_GCC, which seems likely).
Sadly there are a number of ports using _GCC_BUILD_DEPENDS even though
by virtual of its name this is an internal (to bsd.gcc.mk) variable. I
am keeping this for now and will address this in a better manner and
work with the maintainer(s) of affected ports.
For the time being, my patch below is an extended version of what
Brendan shared and addresses (or tries to) issues he mentioned.
Gerald
Index: bsd.gcc.mk
===
--- bsd.gcc.mk (revision 301695)
+++ bsd.gcc.mk (working copy)
@@ -178,29 +178,36 @@
. if ${_USE_GCC} == ${_GCCVERSION_${v}_V}
. if ${OSVERSION} ${_GCCVERSION_${v}_L} || ${OSVERSION}
${_GCCVERSION_${v}_R}
V:=${_GCCVERSION_${v}_V:S/.//}
-_GCC_BUILD_DEPENDS:= gcc${V}
_GCC_PORT_DEPENDS:=gcc${V}
+. if ${_USE_GCC} == ${GCC_DEFAULT_VERSION}
+_GCC_PORT:=gcc
+. else
+_GCC_PORT:=gcc${V}
+. endif
CC:= gcc${V}
CXX:= g++${V}
CPP:= cpp${V}
. if ${_USE_GCC} != 3.4
-CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
-LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+CFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
+LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.if defined (USE_FORTRAN)
.if ${USE_FORTRAN} == yes
-FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_BUILD_DEPENDS}
+FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/${_GCC_PORT_DEPENDS}
.endif
.endif
+# The following is for the sakes of some ports which use this without
+# ever telling us; to be fixed.
+_GCC_BUILD_DEPENDS:= ${_GCC_PORT_DEPENDS}
. endif
. endif
. endif
.endfor
.undef V
-.if defined(_GCC_BUILD_DEPENDS)
-BUILD_DEPENDS+=
${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+.if defined(_GCC_PORT_DEPENDS)
+BUILD_DEPENDS+=${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 3.4
-RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_BUILD_DEPENDS}
+RUN_DEPENDS+= ${_GCC_PORT_DEPENDS}:${PORTSDIR}/lang/${_GCC_PORT}
. if ${_USE_GCC} != 4.2
# Later GCC ports already depend on binutils; make sure whatever we
# build leverages this as well.
___
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: lang/gcc46
On 07/29/2012 16:55, Gerald Pfeifer wrote: lang/gcc and lang/gcc46 should be fully compatible, without rebuilds necessary. Only when lang/gcc is going to move to GCC 4.7 later this year would I consider that. IMO this highlights the issue that unversioned instances of ports that really need versioning (like gcc) are a bad idea. It's much better for users to be able to tie their installations to a particular version, and then only update when they need to. The fact that someday in the future users who innocently upgrade lang/gcc will suddenly find that everything relying on libgcc at runtime is now broken pretty much speaks for itself. Perl is the shining example of how the versioning strategy works well, lang/python and lang/php5 are examples of where it's not meeting our users' needs. Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) ___ 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: lang/gcc46 building stuff in $TMPDIR
On 06/09/2012 09:33, Doug Barton wrote: On 06/06/2012 23:15, Gerald Pfeifer wrote: On Wed, 6 Jun 2012, Doug Barton wrote: I purposely have a tiny /tmp, and while building gcc46 today it filled up with stuff from the gcc build. Is there any way to modify this process so that it keeps everything in WRKDIR? GCC in general should put all its build stuff in WRKDIR and only stash really temporary things (coming from an individual invocation of GCC such as assembly files if any) in /tmp for short periods of time. I am not aware of anything we could do beyond what I already have in the port, but then this is the first time I hear about this, in the context of FreeBSD and also upstream. Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. Just tried building the latest, same error. Did I misunderstand that something was supposed to be different? Doug -- If you're never wrong, you're not trying hard enough ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On Sat, 9 Jun 2012, Doug Barton wrote: In an ideal world, we would have separate packages for the runtime libs and the build tools so that packages could be more portable, but I would imagine that would be a lot of work. I looked into that last year and found that the FreeBSD ports infrastructure was not exactly helpful. Ideally I would want something like gcc46-runtime and gcc46-java and gcc46 itself, where -runtime is a hard dependency for gcc46 and -java optional. Short of building lang/gcc46 a couple of times via slave ports and packaging different aspects by virtue of different slave ports, or having gcc46 also include the contents of gcc46-runtime, the introduction of a gcc46-DONT-USE-JUST-USED-FOR-SUBPACKAGES dummy port was the only idea I came up with. None of the three approaches really convinced me. On Sun, 10 Jun 2012, Baptiste Daroussin wrote: Yes that would be a lot of but it is the way we are doing. the upcoming stagedir will open the door to easy package splitting and then allow easily to split gcc into something like gcc-libs and gcc package or something like that. Lovely. Looking forward to that! (Chris also indicated he had an idea, let's see. Whatever works. ;-) 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 08/06/2012 15:12, Alan Hicks wrote:
On 08/06/2012 11:09, Heino Tiedemann wrote:
Maciej Suszkomac...@suszko.eu wrote:
Heino Tiedemannrotkaps_spam_t...@gmx.de wrote:
What ist the meaning of
,
| Use GCC 4.6 to fix build on newer FreeBSD versions
`
What meians newer FreeBSD versions here?
http://www.freshports.org/www/firefox/
And what means
,
| Don't depend on GCC 4.6 if clang is used
`
How an I use clang?
http://www.freshports.org/www/firefox/
I just simply built www/firefox with those flags to make:
CC=clang CXX=clang++ CPP=clang-cpp
If you use portupgrade, this should work:
portupgrade -m 'CC=clang CXX=clang++ CPP=clang-cpp' firefox\*
does not work :(
clang++ -o nsUTF8UtilsSSE2.o -c -fvisibility=hidden
-DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNlude
-I../../../dist/include/nsprpub -I/usr/local/include
-I/usr/local/include/nspr -I/usr -I/usr/local/include -fno-rtti
-Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-unknown-warning-option
-Wno-retur-std=gnu++0x -ffunction-sections -fdata-sections -pipe
-DNDEBUG -DTRIMMED -fno-omit-frame-/../../mozilla-config.h
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
In file included from /usr/include/clang/3.0/xmmintrin.h:31:
/usr/include/clang/3.0/mmintrin.h:28:2: error: #error MMX instruction
set not enabled
#error MMX instruction set not enabled
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
/usr/include/clang/3.0/xmmintrin.h:417:19: error: unknown type name
'__m64'
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/xmmintrin.h:417:25: error: expected unqualified-id
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
/usr/include/clang/3.0/emmintrin.h:42:19: error: unknown type name
'__m128d'
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/emmintrin.h:42:27: error: expected unqualified-id
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:4:
../../../dist/include/nsUTF8Utils.h:90:10: error: use of undeclared
identifier 'UTF8traits'
if ( UTF8traits::isASCII(c) )
^
../../../dist/include/nsUTF8Utils.h:146:10: error: use of undeclared
identifier 'UTF8traits'
if ( UTF8traits::is2byte(c) )
^
../../../dist/include/nsUTF8Utils.h:152:15: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is3byte(c) )
^
../../../dist/include/nsUTF8Utils.h:158:15: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is4byte(c) )
^
../../../dist/include/nsUTF8Utils.h:164:15: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is5byte(c) )
^
../../../dist/include/nsUTF8Utils.h:170:15: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is6byte(c) )
^
../../../dist/include/nsUTF8Utils.h:186:10: error: use of undeclared
identifier 'UTF8traits'
if ( UTF8traits::isInSeq(c) )
^
../../../dist/include/nsUTF8Utils.h:393:18: error: use of undeclared
identifier 'UTF8traits'
if ( UTF8traits::isASCII(*p) )
^
../../../dist/include/nsUTF8Utils.h:395:23: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is2byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:397:23: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is3byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:399:23: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is4byte(*p) ) {
^
../../../dist/include/nsUTF8Utils.h:442:23: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is5byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:444:23: error: use of undeclared
identifier 'UTF8traits'
else if ( UTF8traits::is6byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:686:24: error: no member named
'supports_sse2' in namespace 'mozilla'
if (mozilla::supports_sse2())
~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
gmake[5]: *** [nsUTF8UtilsSSE2.o] Error 1
gmake[5]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src'
gmake[4]: *** [libs] Error 2
gmake[4]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/xpcom/string'
gmake[3]: *** [libs] Error 2
gmake[3]: Leaving directory
`/usr/ports/www/firefox/work/mozilla-release/xpcom'
gmake[2]: *** [libs_tier_platform] Error 2
gmake[2]: Leaving directory `/usr/ports/www/firefox/work/mozilla-release'
gmake[1]: ***
Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On Sat, Jun 09, 2012 at 08:27:11PM -0700, Doug Barton wrote: On 06/06/2012 12:18, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 It's very common for binaries built with gcc to link to libgcc, and/or libstdc++: ldd firefox-bin | grep gcc libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x802b19000) libgcc_s.so.1 = /usr/local/lib/gcc46/libgcc_s.so.1 (0x8033a5000) In an ideal world, we would have separate packages for the runtime libs and the build tools so that packages could be more portable, but I would imagine that would be a lot of work. Doug Yes that would be a lot of but it is the way we are doing. the upcoming stagedir will open the door to easy package splitting and then allow easily to split gcc into something like gcc-libs and gcc package or something like that. regards, Bapt pgpgPjlR3EHvk.pgp Description: PGP signature
Re: lang/gcc46 building stuff in $TMPDIR
On 06/06/2012 23:15, Gerald Pfeifer wrote: On Wed, 6 Jun 2012, Doug Barton wrote: I purposely have a tiny /tmp, and while building gcc46 today it filled up with stuff from the gcc build. Is there any way to modify this process so that it keeps everything in WRKDIR? GCC in general should put all its build stuff in WRKDIR and only stash really temporary things (coming from an individual invocation of GCC such as assembly files if any) in /tmp for short periods of time. I am not aware of anything we could do beyond what I already have in the port, but then this is the first time I hear about this, in the context of FreeBSD and also upstream. Are you saying you actually noticed some leftovers in /tmp, or that there just has been more at certain points in time than you would expect? I finally had time to watch this closely, and found the culprit(s). While building the port creates a lot of files in /tmp (I think it's actually $TMP, not $TMPDIR). A lot of them are *.s files, most of which are small, but one of which grew to over 64M, which is what caused my build to fail. It also creates a variety of other files, including .o, .c, .ld, .le, .zip, etc. The java OPTION also creates some pretty big jar directories, I had one grow to 49M, which didn't crash my build, but might blow up someone with a smaller /tmp. My suggestion would be to create a directory in $WRKDIR and assign $TMP (or whatever the right envar is) to it. Doug -- This .signature sanitized for your protection ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 06/06/2012 12:18, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 It's very common for binaries built with gcc to link to libgcc, and/or libstdc++: ldd firefox-bin | grep gcc libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x802b19000) libgcc_s.so.1 = /usr/local/lib/gcc46/libgcc_s.so.1 (0x8033a5000) In an ideal world, we would have separate packages for the runtime libs and the build tools so that packages could be more portable, but I would imagine that would be a lot of work. Doug -- This .signature sanitized for your protection ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
Heino Tiedemann rotkaps_spam_t...@gmx.de wrote: What ist the meaning of , | Use GCC 4.6 to fix build on newer FreeBSD versions ` What meians newer FreeBSD versions here? http://www.freshports.org/www/firefox/ And what means , | Don't depend on GCC 4.6 if clang is used ` How an I use clang? http://www.freshports.org/www/firefox/ I just simply built www/firefox with those flags to make: CC=clang CXX=clang++ CPP=clang-cpp If you use portupgrade, this should work: portupgrade -m 'CC=clang CXX=clang++ CPP=clang-cpp' firefox\* ...of course if you have clang in your base system. #v+ tlhscd@arsenic:/ $ uname -mv FreeBSD 9.0-STABLE #1 r236436: Sat Jun 2 19:14:50 CEST 2012 r...@arsenic.lan:/usr/obj/usr/src/sys/ARSENIC amd64 tlhscd@arsenic:/ $ firefox --version Mozilla Firefox 13.0 #v- -- regards, Maciej Suszko. signature.asc Description: PGP signature
Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
Maciej Suszko mac...@suszko.eu wrote:
Heino Tiedemann rotkaps_spam_t...@gmx.de wrote:
What ist the meaning of
,
| Use GCC 4.6 to fix build on newer FreeBSD versions
`
What meians newer FreeBSD versions here?
http://www.freshports.org/www/firefox/
And what means
,
| Don't depend on GCC 4.6 if clang is used
`
How an I use clang?
http://www.freshports.org/www/firefox/
I just simply built www/firefox with those flags to make:
CC=clang CXX=clang++ CPP=clang-cpp
If you use portupgrade, this should work:
portupgrade -m 'CC=clang CXX=clang++ CPP=clang-cpp' firefox\*
does not work :(
clang++ -o nsUTF8UtilsSSE2.o -c -fvisibility=hidden -DMOZ_GLUE_IN_PROGRAM
-DMOZILLA_INTERNlude -I../../../dist/include/nsprpub -I/usr/local/include
-I/usr/local/include/nspr -I/usr -I/usr/local/include -fno-rtti
-Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-unknown-warning-option
-Wno-retur-std=gnu++0x -ffunction-sections -fdata-sections -pipe -DNDEBUG
-DTRIMMED -fno-omit-frame-/../../mozilla-config.h
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
In file included from /usr/include/clang/3.0/xmmintrin.h:31:
/usr/include/clang/3.0/mmintrin.h:28:2: error: #error MMX instruction set not
enabled
#error MMX instruction set not enabled
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
/usr/include/clang/3.0/xmmintrin.h:417:19: error: unknown type name '__m64'
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/xmmintrin.h:417:25: error: expected unqualified-id
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
/usr/include/clang/3.0/emmintrin.h:42:19: error: unknown type name '__m128d'
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/emmintrin.h:42:27: error: expected unqualified-id
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:4:
../../../dist/include/nsUTF8Utils.h:90:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isASCII(c) )
^
../../../dist/include/nsUTF8Utils.h:146:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::is2byte(c) )
^
../../../dist/include/nsUTF8Utils.h:152:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is3byte(c) )
^
../../../dist/include/nsUTF8Utils.h:158:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is4byte(c) )
^
../../../dist/include/nsUTF8Utils.h:164:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is5byte(c) )
^
../../../dist/include/nsUTF8Utils.h:170:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is6byte(c) )
^
../../../dist/include/nsUTF8Utils.h:186:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isInSeq(c) )
^
../../../dist/include/nsUTF8Utils.h:393:18: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isASCII(*p) )
^
../../../dist/include/nsUTF8Utils.h:395:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is2byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:397:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is3byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:399:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is4byte(*p) ) {
^
../../../dist/include/nsUTF8Utils.h:442:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is5byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:444:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is6byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:686:24: error: no member named
'supports_sse2' in namespace 'mozilla'
if (mozilla::supports_sse2())
~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
gmake[5]: *** [nsUTF8UtilsSSE2.o] Error 1
gmake[5]: Leaving directory
Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
When compiling with clang, try adding -Qunused-arguments to the compiler
flags.
Something like
# Add -Qunused-arguments to CFLAGS if clang/clang++ is used.
.if ${CC:T:Mclang} == clang || ${CXX:T:Mclang++} == clang++
CFLAGS+=-Qunused-arguments
.endif
in /etc/make.conf should do it.
Regards!
--
Niclas Zeising
___
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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 08/06/2012 11:09, Heino Tiedemann wrote:
Maciej Suszkomac...@suszko.eu wrote:
Heino Tiedemannrotkaps_spam_t...@gmx.de wrote:
What ist the meaning of
,
| Use GCC 4.6 to fix build on newer FreeBSD versions
`
What meians newer FreeBSD versions here?
http://www.freshports.org/www/firefox/
And what means
,
| Don't depend on GCC 4.6 if clang is used
`
How an I use clang?
http://www.freshports.org/www/firefox/
I just simply built www/firefox with those flags to make:
CC=clang CXX=clang++ CPP=clang-cpp
If you use portupgrade, this should work:
portupgrade -m 'CC=clang CXX=clang++ CPP=clang-cpp' firefox\*
does not work :(
clang++ -o nsUTF8UtilsSSE2.o -c -fvisibility=hidden -DMOZ_GLUE_IN_PROGRAM
-DMOZILLA_INTERNlude -I../../../dist/include/nsprpub -I/usr/local/include
-I/usr/local/include/nspr -I/usr -I/usr/local/include -fno-rtti
-Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtid-offsetof
-Wno-variadic-macros -Werror=return-type -Wno-unknown-warning-option
-Wno-retur-std=gnu++0x -ffunction-sections -fdata-sections -pipe -DNDEBUG
-DTRIMMED -fno-omit-frame-/../../mozilla-config.h
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
In file included from /usr/include/clang/3.0/xmmintrin.h:31:
/usr/include/clang/3.0/mmintrin.h:28:2: error: #error MMX instruction set not
enabled
#error MMX instruction set not enabled
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
In file included from /usr/include/clang/3.0/emmintrin.h:31:
/usr/include/clang/3.0/xmmintrin.h:417:19: error: unknown type name '__m64'
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/xmmintrin.h:417:25: error: expected unqualified-id
static __inline__ __m64 __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:3:
/usr/include/clang/3.0/emmintrin.h:42:19: error: unknown type name '__m128d'
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
/usr/include/clang/3.0/emmintrin.h:42:27: error: expected unqualified-id
static __inline__ __m128d __attribute__((__always_inline__, __nodebug__))
^
In file included from
/usr/ports/www/firefox/work/mozilla-release/xpcom/string/src/nsUTF8UtilsSSE2.cpp:4:
../../../dist/include/nsUTF8Utils.h:90:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isASCII(c) )
^
../../../dist/include/nsUTF8Utils.h:146:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::is2byte(c) )
^
../../../dist/include/nsUTF8Utils.h:152:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is3byte(c) )
^
../../../dist/include/nsUTF8Utils.h:158:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is4byte(c) )
^
../../../dist/include/nsUTF8Utils.h:164:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is5byte(c) )
^
../../../dist/include/nsUTF8Utils.h:170:15: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is6byte(c) )
^
../../../dist/include/nsUTF8Utils.h:186:10: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isInSeq(c) )
^
../../../dist/include/nsUTF8Utils.h:393:18: error: use of undeclared identifier
'UTF8traits'
if ( UTF8traits::isASCII(*p) )
^
../../../dist/include/nsUTF8Utils.h:395:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is2byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:397:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is3byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:399:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is4byte(*p) ) {
^
../../../dist/include/nsUTF8Utils.h:442:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is5byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:444:23: error: use of undeclared identifier
'UTF8traits'
else if ( UTF8traits::is6byte(*p) )
^
../../../dist/include/nsUTF8Utils.h:686:24: error: no member named
'supports_sse2' in namespace 'mozilla'
if (mozilla::supports_sse2())
~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
gmake[5]: *** [nsUTF8UtilsSSE2.o] Error 1
gmake[5]: Leaving
Re: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
On 06/06/2012 02:18 PM, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 snip Required To Run: archivers/zip, lang/gcc46,... Just a shot in the dark for lang/gcc46, I'd say it's because Firefox dynamically links to a newer version of libgcc that is only available when it is installed. Its runtime dependency on archivers/zip can be explained by the fact that Firefox now packs its hundreds of GUI files (chrome) into a giant zip file (named omni.ja), for which it requires a zip library to read. You're welcome to tweak the Makefile to remove the runtime dependency and test it to see how badly it breaks; I've done the same to keep Perl and Python off my embedded system images when installing glib et alia. Glib only requires the languages for scripts used when compiling software, which is unlikely to occur on an embedded system. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net cyber...@cyberleo.net Furry Peace! - http://.fur.com/peace/ ___ 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: firefox 13.0,1 needs lang/gcc46 -- to RUN?!
CyberLeo Kitsana cyber...@cyberleo.net wrote: On 06/06/2012 02:18 PM, Heino Tiedemann wrote: Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 snip Required To Run: archivers/zip, lang/gcc46,... Just a shot in the dark for lang/gcc46, I'd say it's because Firefox dynamically links to a newer version of libgcc that is only available when it is installed. Its runtime dependency on archivers/zip can be explained by the fact that Firefox now packs its hundreds of GUI files (chrome) into a giant zip file (named omni.ja), for which it requires a zip library to read. You're welcome to tweak the Makefile to remove the runtime dependency and test it to see how badly it breaks; I've done the same to keep Perl and Python off my embedded system images when installing glib et alia. Glib only requires the languages for scripts used when compiling software, which is unlikely to occur on an embedded system. What ist the meaning of , | Use GCC 4.6 to fix build on newer FreeBSD versions ` What meians newer FreeBSD versions here? http://www.freshports.org/www/firefox/ And what means , | Don't depend on GCC 4.6 if clang is used ` How an I use clang? http://www.freshports.org/www/firefox/ Heino ___ 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
firefox 13.0,1 needs lang/gcc46 -- to RUN?!
Hi, Why this ports needs his compiler to RUN?! firefox 13.0,1 Required To Build: devel/nspr, graphics/cairo, archivers/unzip, archivers/zip, devel/yasm, devel/gmake, lang/gcc46, devel/binutils, x11/printproto, x11/libSM, x11-toolkits/libXt, x11/libXi, x11/libXext, x11/libX11, x11/libXinerama, x11/libICE, x11/xproto, lang/perl5.8, devel/autoconf213, textproc/intltool, devel/pkg-config, devel/desktop-file-utils Required To Run: archivers/zip, lang/gcc46,... Heino ___ 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
lang/gcc46 building stuff in $TMPDIR
I purposely have a tiny /tmp, and while building gcc46 today it filled up with stuff from the gcc build. Is there any way to modify this process so that it keeps everything in WRKDIR? Doug -- This .signature sanitized for your protection ___ 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: lang/gcc46
On Tue, Dec 13, 2011 at 06:08:44PM +0800, Gerald Pfeifer wrote: On Mon, 12 Dec 2011, Kevin Oberman wrote: Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not seem like this should be too difficult. Just a matter of the right person having the time. Would ports specifying gcc46 need to be touched? Nope. All transparent. USE_GCC=4.6+ or USE_FORTRAN=yes both will automagically just pull in lang/gcc instead of lang/gcc46 by default. That's the plan. It's taken a bit longer than I had hoped (for a number of reasons), but we are nearly there. ;-) Gerald Hi Gerald, Thanks for the explanation. Regarding of gcc in tinderbox, how can I tell tinderbox to use lang/gcc instead of a weekly-update lang/gcc46 when it encounters USE_GCC=4.6? Regards, -- Sunpoet Po-Chuan Hsieh sunpoet at sunpoet.net sunpoet at FreeBSD.org 4096R/CC57E36B 8AD8 68F2 7D2B 0A10 7E9B 8CC0 DC44 247E CC57 E36B http://people.FreeBSD.org/~sunpoet/pgpkeys.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: lang/gcc46
On Tuesday 13 December 2011 12:01:48 Kevin Oberman wrote: On Tue, Dec 13, 2011 at 8:30 AM, Jason Hellenthal jh...@dataix.net wrote: On Tue, Dec 13, 2011 at 06:05:40PM +0800, Gerald Pfeifer wrote: On Tue, 13 Dec 2011, Sunpoet Po-Chuan Hsieh wrote: We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. Actually, it's even better. :-) Replace lang/gcc46 by lang/gcc on your local systems, Kevin and Jason, and that (not lang/gcc46) will be used henceforth. There is a small issue in that this will not be recorded properly as a dependency when you build packages, but apart from that (if you use ports or ensure the lang/gcc package is present wherever you install things built that way, you should be good. Gerald Thanks Gerald and everyone else. Much appreciated. -- ;s =; Yes, thanks! % portmaster -o lang/gcc lang/gcc46 seems to have worked just fine! I did and I don't have problems... Thank you. Mitja http://jpgmag.com/people/lumiwa ___ 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: lang/gcc46
On Tue, Dec 13, 2011 at 12:11:21AM +, b. f. wrote: We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. changed. You can make this change now, simply by removing lang/gcc46 and installing lang/gcc, and then rebuilding all dependent ports (this last step may not be necessary in many cases, but it is better to be safe). This works fine for me on ia64. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: lang/gcc46
On Mon, 12 Dec 2011, Kevin Oberman wrote: Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not seem like this should be too difficult. Just a matter of the right person having the time. Would ports specifying gcc46 need to be touched? Nope. All transparent. USE_GCC=4.6+ or USE_FORTRAN=yes both will automagically just pull in lang/gcc instead of lang/gcc46 by default. That's the plan. It's taken a bit longer than I had hoped (for a number of reasons), but we are nearly there. ;-) 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: lang/gcc46
On Tue, 13 Dec 2011, Sunpoet Po-Chuan Hsieh wrote: We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. Actually, it's even better. :-) Replace lang/gcc46 by lang/gcc on your local systems, Kevin and Jason, and that (not lang/gcc46) will be used henceforth. There is a small issue in that this will not be recorded properly as a dependency when you build packages, but apart from that (if you use ports or ensure the lang/gcc package is present wherever you install things built that way, you should be good. 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: lang/gcc46
--- On Mon, 12/12/11, Kevin Oberman kob6...@gmail.com wrote: Hi Gerald, As a request once again similiar to one I have made in the past... Would it be possible yet to slow down the update process for the gcc46 port ? This is turning out to be quite the pain in the U-Know-What with version flapping and rebuilding because a port depends on it. If I am correct it is updated weekly. I caught the tail end of the previous update and the day after it was bumped to the next snapshot version by the time both of those were finished the port had once again been bumped to _1. Is there anything that could be done to stabalize this ... ? At this point I am left for the manual intervention of using +IGNOREME files or excluding by whatever means neccesary as weekly updates seem completely unneccesary now that alot of ports are shifting to depend on gcc46. Can a gcc46-devel port be branched for those that absolutely need the weekly updates ? +1 gcc46 is used by so many ports that I am continually re-building it and on slow machines, this takes a while. How about a gcc46-devel port that gets the regular updates and let gcc46 stay stable when there are not major fixes? - R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com Now I see I accidentally sent my reply only to Kevin Oberman and not the list. Composing a message with vi editor is easier than webmail! I have to recompose this message since I failed to save. I wondered why the ports collection used development snapshots of gcc rather than stable releases. On my older computer, dating to 2001, with 256 MB RAM, building ports and portupgrades that depended on gcc-4.5.3 snapshot would bog down after about four hours due to exhausting virtual memory. It seems to make more sense to use stable gcc releases when needed as build dependencies, and keep the current weekly snapshots for testing and development purposes. Tom ___ 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: lang/gcc46
On Tuesday 13 December 2011 12:01:48 Kevin Oberman wrote: On Tue, Dec 13, 2011 at 8:30 AM, Jason Hellenthal jh...@dataix.net wrote: On Tue, Dec 13, 2011 at 06:05:40PM +0800, Gerald Pfeifer wrote: On Tue, 13 Dec 2011, Sunpoet Po-Chuan Hsieh wrote: We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. Actually, it's even better. :-) Replace lang/gcc46 by lang/gcc on your local systems, Kevin and Jason, and that (not lang/gcc46) will be used henceforth. There is a small issue in that this will not be recorded properly as a dependency when you build packages, but apart from that (if you use ports or ensure the lang/gcc package is present wherever you install things built that way, you should be good. Gerald Thanks Gerald and everyone else. Much appreciated. -- ;s =; Yes, thanks! % portmaster -o lang/gcc lang/gcc46 seems to have worked just fine! I like to do Mitjaportmaster -o lang/gcc lang/gcc46 but do I need to rebuild all ports which I use gcc46, please? http://jpgmag.com/people/lumiwa ___ 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: lang/gcc46
On Tue, 13 Dec 2011, ajtiM wrote: I like to do Mitjaportmaster -o lang/gcc lang/gcc46 but do I need to rebuild all ports which I use gcc46, please? This should not be necessary, just replacing lang/gcc46 by lang/gcc should work. (Note: should. I am very confident it does, but as b.f. stated earlier in the thread, if you want to be 100% sure rebuilding all dependent ports is always the safer approach.) 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: lang/gcc46
On Tue, 13 Dec 2011, Thomas Mueller wrote: I wondered why the ports collection used development snapshots of gcc rather than stable releases. All you _should_ need to run anything from the FreeBSD Ports Collection is either the system compiler (GCC or clang) or lang/gcc all of which are updated very rarely. Any other version of lang/gcc you need to use is indicative of an issue with some other port (short of the GNUstep ports which we are in the process of addressing now that lang/gcc also provide Objective-C). In case you are interested, I have been spending quite some effort over the last years to minimize the number of such ports and here is the list of remaining ones: cad/salome/Makefile.ext USE_GCC=4.4 cad/sceptre/Makefile USE_FORTRAN=g77 graphics/p5-PGPLOT/Makefile USE_FORTRAN=g77 science/elmer-matc/Makefile USE_FORTRAN=g77 science/elmerpost/MakefileUSE_FORTRAN=g77 Without these, lang/gcc44 and lang/gcc34, respectively, could be obsoleted and removed. 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
lang/gcc46
Hi Gerald, As a request once again similiar to one I have made in the past... Would it be possible yet to slow down the update process for the gcc46 port ? This is turning out to be quite the pain in the U-Know-What with version flapping and rebuilding because a port depends on it. If I am correct it is updated weekly. I caught the tail end of the previous update and the day after it was bumped to the next snapshot version by the time both of those were finished the port had once again been bumped to _1. Is there anything that could be done to stabalize this ... ? At this point I am left for the manual intervention of using +IGNOREME files or excluding by whatever means neccesary as weekly updates seem completely unneccesary now that alot of ports are shifting to depend on gcc46. Can a gcc46-devel port be branched for those that absolutely need the weekly updates ? Thanks, -- ;s =; pgp1rKoc41J2J.pgp Description: PGP signature
Re: lang/gcc46
On Mon, Dec 12, 2011 at 9:36 AM, Jason Hellenthal jh...@dataix.net wrote: Hi Gerald, As a request once again similiar to one I have made in the past... Would it be possible yet to slow down the update process for the gcc46 port ? This is turning out to be quite the pain in the U-Know-What with version flapping and rebuilding because a port depends on it. If I am correct it is updated weekly. I caught the tail end of the previous update and the day after it was bumped to the next snapshot version by the time both of those were finished the port had once again been bumped to _1. Is there anything that could be done to stabalize this ... ? At this point I am left for the manual intervention of using +IGNOREME files or excluding by whatever means neccesary as weekly updates seem completely unneccesary now that alot of ports are shifting to depend on gcc46. Can a gcc46-devel port be branched for those that absolutely need the weekly updates ? +1 gcc46 is used by so many ports that I am continually re-building it and on slow machines, this takes a while. How about a gcc46-devel port that gets the regular updates and let gcc46 stay stable when there are not major fixes? - R. Kevin Oberman, Network Engineer E-mail: kob6...@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: lang/gcc46
On Mon, Dec 12, 2011 at 10:11 AM, Sunpoet Po-Chuan Hsieh sunp...@freebsd.org wrote: On Mon, Dec 12, 2011 at 10:03:14AM -0800, Kevin Oberman wrote: On Mon, Dec 12, 2011 at 9:36 AM, Jason Hellenthal jh...@dataix.net wrote: Hi Gerald, As a request once again similiar to one I have made in the past... Would it be possible yet to slow down the update process for the gcc46 port ? This is turning out to be quite the pain in the U-Know-What with version flapping and rebuilding because a port depends on it. If I am correct it is updated weekly. I caught the tail end of the previous update and the day after it was bumped to the next snapshot version by the time both of those were finished the port had once again been bumped to _1. Is there anything that could be done to stabalize this ... ? At this point I am left for the manual intervention of using +IGNOREME files or excluding by whatever means neccesary as weekly updates seem completely unneccesary now that alot of ports are shifting to depend on gcc46. Can a gcc46-devel port be branched for those that absolutely need the weekly updates ? +1 gcc46 is used by so many ports that I am continually re-building it and on slow machines, this takes a while. How about a gcc46-devel port that gets the regular updates and let gcc46 stay stable when there are not major fixes? We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not seem like this should be too difficult. Just a matter of the right person having the time. Would ports specifying gcc46 need to be touched? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@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: lang/gcc46
On Mon, Dec 12, 2011 at 10:03:14AM -0800, Kevin Oberman wrote: On Mon, Dec 12, 2011 at 9:36 AM, Jason Hellenthal jh...@dataix.net wrote: Hi Gerald, As a request once again similiar to one I have made in the past... Would it be possible yet to slow down the update process for the gcc46 port ? This is turning out to be quite the pain in the U-Know-What with version flapping and rebuilding because a port depends on it. If I am correct it is updated weekly. I caught the tail end of the previous update and the day after it was bumped to the next snapshot version by the time both of those were finished the port had once again been bumped to _1. Is there anything that could be done to stabalize this ... ? At this point I am left for the manual intervention of using +IGNOREME files or excluding by whatever means neccesary as weekly updates seem completely unneccesary now that alot of ports are shifting to depend on gcc46. Can a gcc46-devel port be branched for those that absolutely need the weekly updates ? +1 gcc46 is used by so many ports that I am continually re-building it and on slow machines, this takes a while. How about a gcc46-devel port that gets the regular updates and let gcc46 stay stable when there are not major fixes? We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. ___ 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: lang/gcc46
We have lang/gcc already. This port is created for perferred gcc releases (4.6.2 currently). What we're waiting for is a bsd.gcc.mk update to allow users build ports with lang/gcc instead of lang/gcc46. Ahh. I see the issue. I have not looked at bsd.gcc.mk, but it does not seem like this should be too difficult. Just a matter of the right person having the time. Would ports specifying gcc46 need to be touched? The solution to a great many problems is a matter of the right person having the time. Gerald had planned to do this after the ports tree had been completely unfrozen. It is likely that only a few dependent ports will have to be changed. You can make this change now, simply by removing lang/gcc46 and installing lang/gcc, and then rebuilding all dependent ports (this last step may not be necessary in many cases, but it is better to be safe). This may result in some false accounting of dependencies in your package database, but you can alter this if you need to, or use one of the alternative dependency accounting mechanisms in portmaster or portupgrade. Or you can try something like the attached patch, which will fix the dependency accounting -- but you will then have to replace _GCC_BUILD_DEPENDS with _GCC_PORT_DEPENDS (the latter will then be a misnomer) in math/atlas, math/atlas-devel, math/gotoblas, math/R, net-p2p/eiskaltdcpp-* (and soon perhaps also lang/libobjc2, if it is altered to use USE_GCC, which seems likely). Also, you will have to patch the CSUFF lines in print/pdftk. Gerald's eventual changes will probably be similar, but cleaner. For example, he may change the names to more accurately reflect their new roles, and define a variable indicating which directory contains the shared libraries needed at runtime, for the benefit of the aforementioned ports, french/aster, graphics/visionworkbench, etc., so that they are less likely to require modifications if the internals of bsd.gcc.mk change again. b. bsd.gcc.mk.diff Description: Binary data ___ 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
