Re: [toolchain] gcc5-devel question
On 03/01/16 15:33, Gerald Pfeifer wrote: On Tue, 1 Mar 2016, William A. Mahaffey III wrote: When I run gcc5 from the CLI or under make as a regular user, it reports no Graphite support compiled in. When I update the gcc5-devel port, it reports Graphite enabled: [root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig ===> The following configuration options are available for gcc5-devel-5.3.1.s20160223: BOOTSTRAP=on: Build using a full bootstrap GRAPHITE=on: Support for Graphite loop optimizations JAVA=on: Java platform support ===> Use 'make config' to modify these settings [root@devbox, gcc5-devel, 10:24:51am] 505 % This appears odd. Just to make sure, in both cases it's the gcc5-devel port / package? Or might one be gcc5, and the other gcc5-devel? That should not make a difference (cf. `diff gcc5/Makefile gcc5-devel/Makefile`), but might if there are local changes on your system somewhere. Best of my knowlege, yes. That's why I included some of the other info in my OP. When I did the pkg upgrade, the /usr/local/bin/gcc5 upgraded to something dated Feb 27. When I build the port (make install), I get some error trying to install it, but it builds OK & leaves everything in a deep 'staging' directory. The binaries are different. pkg output: [root@devbox, /etc, 4:00:55pm] 512 % grep gcc5 LIST.installed.txt gcc5-devel-5.3.1.s20160223 GNU Compiler Collection 5 [root@devbox, /etc, 4:01:04pm] 513 % pkg info | grep -i gcc5 gcc5-devel-5.3.1.s20160223 GNU Compiler Collection 5 [root@devbox, /etc, 4:01:14pm] 514 % uname -a FreeBSD devbox 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed Jan 13 17:55:39 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [root@devbox, /etc, 4:01:19pm] 515 % Checking the actual files (as regular user, from earlier today): [wam@devbox, pre, 10:34:26am] 576 % !566 find /usr/local/bin/ -name gcc\* -exec ls -CFltr {} + -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/gcc48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-ranlib48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-nm48* -r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/gcc-ar48* lrwxr-xr-x 1 root wheel 20 Nov 30 21:35 /usr/local/bin/gcc@ -> /usr/local/bin/gcc48 -r-xr-xr-x 3 root wheel 846360 Feb 20 05:07 /usr/local/bin/gcc49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ranlib49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-nm49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ar49* -r-xr-xr-x 3 root wheel 895144 Feb 27 23:00 /usr/local/bin/gcc5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-ranlib5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-nm5* -r-xr-xr-x 2 root wheel 25944 Feb 27 23:00 /usr/local/bin/gcc-ar5* [wam@devbox, pre, 10:34:33am] 577 % ( ll /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc* ) -r-xr-xr-x 2 root wheel 25944 Mar 1 10:27 /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-ar5* -r-xr-xr-x 2 root wheel 25912 Mar 1 10:27 /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-nm5* -r-xr-xr-x 2 root wheel 25912 Mar 1 10:27 /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-ranlib5* -r-xr-xr-x 3 root wheel 895144 Mar 1 10:27 /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5* [wam@devbox, pre, 10:34:48am] 578 % diff /usr/local/bin/gcc5 /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5 Files /usr/local/bin/gcc5 and /usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5 differ [wam@devbox, pre, 10:35:03am] 579 % Is it intentional that the port & pkg have different support options (specifically Graphite) ? Nope. Unless you changed it locally. ;-) Gerald Where is that info stored ? When I do a 'ls -ltr' on the port directory, the Makefile shows up as dated Feb 27: [root@devbox, gcc5-devel, 4:05:55pm] 517 % ( lltr ) total 1060 -rw-r--r-- 1 root wheel 239 Aug 23 2014 pkg-descr -rw-r--r-- 1 root wheel 2869 Sep 26 06:09 pkg-plist -rw-r--r-- 1 root wheel 140 Feb 27 16:23 distinfo -rw-r--r-- 1 root wheel 5342 Feb 27 16:23 Makefile drwxr-xr-x 2 root wheel 6 Mar 1 09:29 files/ drwxr-xr-x 5 root wheel17 Mar 1 10:27 work/ -rw-r--r-- 1 root wheel 12157916 Mar 1 10:27 LIST [root@devbox, gcc5-devel, 4:05:56pm] 517 % I thought that would trump anything else, no ? -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-too
gcc5-devel question
I did a full pkg upgrade on my FreeBSD 9.3R developement box this A.M. This upgraded gcc5-devel, as it should have. My system gcc5 seems to come from the pkg: [root@devbox, /etc, 10:22:49am] 494 % pkg query '%Fp' gcc5-devel | grep 'local/bin/gcc' /usr/local/bin/gcc-ar5 /usr/local/bin/gcc-nm5 /usr/local/bin/gcc-ranlib5 /usr/local/bin/gcc5 [root@devbox, /etc, 10:22:54am] 495 % ll -tr /usr/local/bin/gcc* -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/gcc48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-ranlib48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-nm48* -r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/gcc-ar48* lrwxr-xr-x 1 root wheel 20 Nov 30 21:35 /usr/local/bin/gcc@ -> /usr/local/bin/gcc48 -r-xr-xr-x 3 root wheel 846360 Feb 20 05:07 /usr/local/bin/gcc49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ranlib49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-nm49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ar49* -r-xr-xr-x 3 root wheel 895144 Feb 27 23:00 /usr/local/bin/gcc5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-ranlib5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-nm5* -r-xr-xr-x 2 root wheel 25944 Feb 27 23:00 /usr/local/bin/gcc-ar5* [root@devbox, /etc, 10:22:56am] 496 % which gcc5 /usr/local/bin/gcc5 [root@devbox, /etc, 10:23:49am] 497 % When I run gcc5 from the CLI or under make as a regular user, it reports no Graphite support compiled in. When I update the gcc5-devel port, it reports Graphite enabled: [root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig ===> The following configuration options are available for gcc5-devel-5.3.1.s20160223: BOOTSTRAP=on: Build using a full bootstrap GRAPHITE=on: Support for Graphite loop optimizations JAVA=on: Java platform support ===> Use 'make config' to modify these settings [root@devbox, gcc5-devel, 10:24:51am] 505 % Is it intentional that the port & pkg have different support options (specifically Graphite) ? -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC5: pkg vs. ports
On 02/01/16 10:53, William A. Mahaffey III wrote: On 02/01/16 10:48, Kubilay Kocak wrote: If you need further help, freebsd-ports is the most appropriate list, feel free to reply there:) ./koobs Very well, I'll move this over there, sorry for the noise & thanks :-) Eek, when I try to subscribe to the ports list, I get some sort of error: freebsd-ports Subscription results You must GET the form before submitting it. freebsd-ports <https://lists.freebsd.org/mailman/listinfo/freebsd-ports> list run by moderators at freebsd.org <mailto:freebsd-ports-ow...@freebsd.org> freebsd-ports administrative interface <https://lists.freebsd.org/mailman/admin/freebsd-ports> (requires authorization) Overview of all freebsd.org mailing lists <https://lists.freebsd.org/mailman/listinfo> No clue here, anyone ? All I filled in was e-mail address & name, no passwords, but that's what I have done for other lists & it worked -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC5: pkg vs. ports
On 02/01/16 10:48, Kubilay Kocak wrote: If you need further help, freebsd-ports is the most appropriate list, feel free to reply there:) ./koobs Very well, I'll move this over there, sorry for the noise & thanks :-) -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC5: pkg vs. ports
On 02/01/16 10:40, Kubilay Kocak wrote: On 2/02/2016 3:24 AM, William A. Mahaffey III wrote: On 02/01/16 10:18, Kubilay Kocak wrote: Hi William, You may be seeing a previously saved config, try make rmconfig then check again, or look at OPTIONS_DEFAULT inside Makefile You're correct, if graphite *is* a default option, the package should have it . Only other thing I can think of is a silent graphite build failure that isn't fatal, resulting in a built but incomplete package. Unlikely all else being equal though Let us know what you find ./koobs On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" mailto:w...@hiwaay.net>> wrote: I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it doesn't have graphite support enabled, so no auto-parallelization. When I checked the port w/ make showconfig. it shows graphite enabled. I am recompiling it as I write this, but I thought the pkg was/is configured from the port & would have graphite enabled by default, w/ no recompile needed on my part, no ? I have the various other pkg's req'd for graphite support pkg-installed (& just updated this A.M.), so I thought I was ready to go. Not a huge issue, but recompiling the compiler shoots about an hour on my box, would be sweet to avoid that. TIA for any clues & have a good one. -- William A. Mahaffey III The *ports* version looks AOK, Makefile dated Jan 31, & 'make showconfig' says graphite is ready to go. When it gets done, I'll try to compile some code w/ it & verify it is AOK. I just didn't know why the *pkg* version was different. William, I've just had a quick look, and if you're using the lang/gcc5 port, it appears the GRAPHITE option defaults to OFF: https://svnweb.freebsd.org/ports/head/lang/gcc5/Makefile?revision=403073&view=markup#l48 This explains why that (gcc5) package doesn't have it enabled. Also see the last revision commit log: https://svnweb.freebsd.org/ports?view=revision&revision=403073 ./koobs Actually, when I did a 'make install' from the '/usr/ports/lang/gcc5-devel' diredctory, the 1st thing it did was go download the files from kernel.org & proceed: Beginning background make install Initiated at 09:43:52 AM MCST on Monday, February 1, 2016 Making GCC 5.3.1.s20160126 for x86_64-portbld-freebsd9.3 [c,c++,objc,fortran,java] ===> License GPLv3 GPLv3RLE accepted by the user ===> Found saved configuration for gcc5-devel-5.2.1.s20151124 ===> gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/sbin/pkg - found => gcc-5-20160126.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch http://mirrors.kernel.org/sources.redhat.com/gcc/snapshots/5-20160126/gcc-5-20160126.tar.bz2 gcc-5-20160126.tar.bz2 87 MB0 Bps ===> Fetching all distfiles required by gcc5-devel-5.3.1.s20160126 for building ===> Extracting for gcc5-devel-5.3.1.s20160126 => SHA256 Checksum OK for gcc-5-20160126.tar.bz2. ===> Patching for gcc5-devel-5.3.1.s20160126 ===> Applying extra patch /usr/ports/lang/gcc5-devel/files/java-patch-hier ===> Applying FreeBSD patches for gcc5-devel-5.3.1.s20160126 ===> gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/bin/as - found ===> gcc5-devel-5.3.1.s20160126 depends on executable: gmake - found ===> gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/share/java/ecj-4.5.jar - found ===> gcc5-devel-5.3.1.s20160126 depends on executable: zip - found ===> gcc5-devel-5.3.1.s20160126 depends on file: /usr/local/bin/as - found ===> gcc5-devel-5.3.1.s20160126 depends on package: perl5>=5.20<5.21 - found ===> gcc5-devel-5.3.1.s20160126 depends on shared library: libgmp.so - found (/usr/local/lib/libgmp.so) ===> gcc5-devel-5.3.1.s20160126 depends on shared library: libmpfr.so - found (/usr/local/lib/libmpfr.so) ===> gcc5-devel-5.3.1.s20160126 depends on shared library: libmpc.so - found (/usr/local/lib/libmpc.so) ===> gcc5-devel-5.3.1.s20160126 depends on shared library: libiconv.so - found (/usr/local/lib/libiconv.so) ===> gcc5-devel-5.3.1.s20160126 depends on shared library: libisl.so - found (/usr/local/lib/libisl.so) ===> Configuring for gcc5-devel-5.3.1.s20160126 cd /usr/ports/lang/gcc5-devel/work/gcc-5-20160126 ; contrib/gcc_update --touch configure: loading site script /usr/ports/Templates/config.site When I look in /usr/ports/distfiles, I see: [root@devbox, gcc5-devel, 10:48:56am] 410 % lltr /usr/ports/distfiles/ total 617025 -rw-r--r-- 1 root wheel 1118845 Sep 23 2008 zip30.tar.gz -rw-r--r-- 1 root wheel 10658 Jun 17 2013 dialog4ports-0.1.5.tar.gz -rw-r--r--
Re: GCC5: pkg vs. ports
On 02/01/16 10:18, Kubilay Kocak wrote: Hi William, You may be seeing a previously saved config, try make rmconfig then check again, or look at OPTIONS_DEFAULT inside Makefile You're correct, if graphite *is* a default option, the package should have it . Only other thing I can think of is a silent graphite build failure that isn't fatal, resulting in a built but incomplete package. Unlikely all else being equal though Let us know what you find ./koobs On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" <mailto:w...@hiwaay.net>> wrote: I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it doesn't have graphite support enabled, so no auto-parallelization. When I checked the port w/ make showconfig. it shows graphite enabled. I am recompiling it as I write this, but I thought the pkg was/is configured from the port & would have graphite enabled by default, w/ no recompile needed on my part, no ? I have the various other pkg's req'd for graphite support pkg-installed (& just updated this A.M.), so I thought I was ready to go. Not a huge issue, but recompiling the compiler shoots about an hour on my box, would be sweet to avoid that. TIA for any clues & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org <mailto:freebsd-toolchain@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org <mailto:freebsd-toolchain-unsubscr...@freebsd.org>" My build failed right at the end: # Add target libraries and include files to packaging list. /bin/rm -f -f /usr/ports/lang/gcc5-devel/work/PLIST.lib cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d lib/gcc5 ]; then /usr/bin/find lib/gcc5 -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d libexec/gcc5 ]; then /usr/bin/find libexec/gcc5 -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gcj ]; then /usr/bin/find include/gcj -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/gnu ]; then /usr/bin/find include/gnu -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/java ]; then /usr/bin/find include/java -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work/stage/usr/local ; if [ -d include/javax ]; then /usr/bin/find include/javax -type f -o -type l >>/usr/ports/lang/gcc5-devel/work/PLIST.lib ; fi cd /usr/ports/lang/gcc5-devel/work ; /usr/bin/sed -i -e "/PLIST.lib/ r PLIST.lib" /usr/ports/lang/gcc5-devel/work/.PLIST.mktmp > Compressing man pages (compress-man) ===> Installing ldconfig configuration file ===> Installing for gcc5-devel-5.3.1.s20160126 ===> Checking if gcc5-devel already installed ===> An older version of gcc5-devel is already installed (gcc5-devel-5.3.1.s20160119) You may wish to ``make deinstall'' and install this port again by ``make reinstall'' to upgrade it properly. If you really wish to overwrite the old port of gcc5-devel without deleting it first, set the variable "FORCE_PKG_REGISTER" in your environment or the "make install" command line. *** [check-already-installed] Error code 1 Stop in /usr/ports/lang/gcc5-devel. *** [install] Error code 1 Stop in /usr/ports/lang/gcc5-devel. 2983.69 real 9852.39 user 807.15 sys Completed at 10:33:36 AM MCST on Monday, February 1, 2016 i.e. it wouldn't overwrite the pkg-installed version (I think). I (think I) recall having to do a 'make FORCE_PKG_REGISTER=1 install' or some such before, or just use the version down in the stage directory -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GCC5: pkg vs. ports
On 02/01/16 10:18, Kubilay Kocak wrote: Hi William, You may be seeing a previously saved config, try make rmconfig then check again, or look at OPTIONS_DEFAULT inside Makefile You're correct, if graphite *is* a default option, the package should have it . Only other thing I can think of is a silent graphite build failure that isn't fatal, resulting in a built but incomplete package. Unlikely all else being equal though Let us know what you find ./koobs On 2 Feb 2016 3:06 AM, "William A. Mahaffey III" <mailto:w...@hiwaay.net>> wrote: I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it doesn't have graphite support enabled, so no auto-parallelization. When I checked the port w/ make showconfig. it shows graphite enabled. I am recompiling it as I write this, but I thought the pkg was/is configured from the port & would have graphite enabled by default, w/ no recompile needed on my part, no ? I have the various other pkg's req'd for graphite support pkg-installed (& just updated this A.M.), so I thought I was ready to go. Not a huge issue, but recompiling the compiler shoots about an hour on my box, would be sweet to avoid that. TIA for any clues & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org <mailto:freebsd-toolchain@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org <mailto:freebsd-toolchain-unsubscr...@freebsd.org>" The *ports* version looks AOK, Makefile dated Jan 31, & 'make showconfig' says graphite is ready to go. When it gets done, I'll try to compile some code w/ it & verify it is AOK. I just didn't know why the *pkg* version was different. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
GCC5: pkg vs. ports
I just did a full 'pkg upgrade' on my FBSD 9.3R box, which installed the newest GCC5. I also updated ports. When I used the pkg-provided GCC5, it doesn't have graphite support enabled, so no auto-parallelization. When I checked the port w/ make showconfig. it shows graphite enabled. I am recompiling it as I write this, but I thought the pkg was/is configured from the port & would have graphite enabled by default, w/ no recompile needed on my part, no ? I have the various other pkg's req'd for graphite support pkg-installed (& just updated this A.M.), so I thought I was ready to go. Not a huge issue, but recompiling the compiler shoots about an hour on my box, would be sweet to avoid that. TIA for any clues & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] gcc5-devel question
On 12/23/15 05:56, Gerald Pfeifer wrote: Hi William, On Thu, 10 Dec 2015, William A. Mahaffey III wrote: However, pkg did reinstall gcc5-devel-5.2.1.s20151124 due to changed options. I cd'ed to /usr/ports/lang/gcc5-devel & poked around a bit. I saw no files or directories dated today, the latest was dated Dec 02, the last time I upgraded & did a 'make install'. I did a find in /usr/ports & /usr/ports/lang/gcc5-devel was all there was. Did the compiler indeed get reinstalled ? If so, where :-) ? the location should not have changed, nor should have any packaging (additional files, say). 1st, thanks for your reply. This question was/is stupidly worded :-). What I was/am asking is whether the pkg-installed version of this compiler is compiled for Graphite support OOTB. The answer appears to be 'no'. I just pkg-upgraded to the newest version & it is now called 5.3.1: [29/33] Upgrading gcc5-devel from 5.2.1.s20151124 to 5.3.1.s20151208... [29/33] Extracting gcc5-devel-5.3.1.s20151208: .. done However, when queried from the command line, it doesn't mention 'libisl' (req'd for Graphite support) & when I try to compile code using Graphite optimization (-floop-parallelize-all for me) it fails w/ an error message saying Graphite support not available: f951: sorry, unimplemented: Graphite loop optimizations cannot be used (ISL is not available)(-fgraphite, -fgraphite-identity, -floop-block, -floop-interchange, -floo p-strip-mine, -floop-parallelize-all, -floop-unroll-and-jam, and -ftree-loop-linear) libisl is indeed available, pkg installed & ready to go. When I upgraded ports (portsnap fetch update) this A.M., nothing got upgraded, everything still dated 12/09 or earlier (when I last rebuilt it to turn on Graphite support, which apparently worked AOK) except for the log files from my compile. The port showed/shows Graphite enabled by default (I think). So, another question is whether the pkg & port have different build configurations ? Also, when I did a 'make showconfig', it showed graphite support ready to go (*yipp*, kudos), but no executable that I could locate on short notice. Do I still need to compile it up, or is there an executable ready to go somewhere not-so-obvious to me :-) ? Graphite support means additional optimizations GCC can perform (if you specify the respective options). You need to build the lang/gcc* ports that support Graphite with the respective option (GRAPHITE) enabled. It is off by default, and thus not part of packages. When I last compiled it up last week, I did a 'make install FORCE_PKG_REGISTER=1' which overwrote /usr/local/bin/gcc5 (not a huge issue, but still ), how do I tell it to install the executable under a different name ? BTW, I am *NOT* particularly familiar w/ the 'GNU way', so pardon me if this is a bit noobish :-/ TIA & have a good one. I am not aware of the FreeBSD packaging system supporting the renaming of individual files within a package. You could try to install into a different location and then tweak things there, I guess. Gerald -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
gcc5-devel questions
s.c StringUtils.c Array.c Ids.c IntA.c UintA.c RealA.c PtrA.c PtrStack.c String.c Words.c LabelledData.c Gauss.c Getopt.c TimeStamp.c convection.c cfd.c TaggedM.c VTK.c XML.c BLAS.c SVD.c SysUtils.c VectorIO.c ArrayIDs.c SegIDs.c simplex.c runge.c cc1: warning: command line option '-fpermissive' is valid for C++/ObjC++ but not for C Cutils.c:1:0: sorry, unimplemented: Graphite loop optimizations cannot be used (ISL is not available)(-fgraphite, -fgraphite-identity, -floop-block, -floop-interchange, -floop-strip-mine, -floop-parallelize-all, -floop-unroll-and-jam, and -ftree-loop-linear) i.e. no Graphite support. As seen below, the pkg-installed gcc5 & the port-compiled version are identical: [root@devbox, gcc5-devel, 10:03:47am] 919 % diff /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-5.2.1 /usr/local/bin/gcc5 [root@devbox, gcc5-devel, 10:03:48am] 919 % The isl pkg is indeed installed: [root@devbox, gcc5-devel, 10:04:43am] 920 % lltr /usr/local/lib/*isl* -rw-r--r-- 1 root wheel 3939 Nov 5 22:11 /usr/local/lib/libisl.so.15.0.0-gdb.py -rwxr-xr-x 1 root wheel 1837643 Nov 5 22:11 /usr/local/lib/libisl.so.15.0.0* lrwxr-xr-x 1 root wheel 16 Nov 5 22:11 /usr/local/lib/libisl.so.15@ -> libisl.so.15.0.0 lrwxr-xr-x 1 root wheel 16 Nov 5 22:11 /usr/local/lib/libisl.so@ -> libisl.so.15.0.0 -rw-r--r-- 1 root wheel 2840094 Nov 5 22:11 /usr/local/lib/libisl.a -rwxr-xr-x 1 root wheel 191941 Nov 6 00:04 /usr/local/lib/libcloog-isl.so.4.0.0* lrwxr-xr-x 1 root wheel 21 Nov 6 00:04 /usr/local/lib/libcloog-isl.so.4@ -> libcloog-isl.so.4.0.0 lrwxr-xr-x 1 root wheel 21 Nov 6 00:04 /usr/local/lib/libcloog-isl.so@ -> libcloog-isl.so.4.0.0 -rw-r--r-- 1 root wheel 257274 Nov 6 00:04 /usr/local/lib/libcloog-isl.a /usr/local/lib/cloog-isl: total 5 -rw-r--r-- 1 root wheel 813 Nov 6 00:04 cloog-isl-config.cmake /usr/local/lib/isl: total 5 -rw-r--r-- 1 root wheel 670 Nov 6 00:04 isl-config.cmake [root@devbox, gcc5-devel, 10:04:44am] 920 % Why are the port-compiled gcc5-devel & the pkg-installed gcc5 identical ? How do I get the gcc5-devel to recompile (not just relink) to recover Graphite support ? -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: gcc5-devel question
On 12/10/15 10:35, William A. Mahaffey III wrote: I just did a 'pkg upgrade -y' when I noticed upgraded LibGL available. I was hoping it might include static versions of libGL/GLU/GLw, but no such luck. However, pkg did reinstall gcc5-devel-5.2.1.s20151124 due to changed options. I cd'ed to /usr/ports/lang/gcc5-devel & poked around a bit. I saw no files or directories dated today, the latest was dated Dec 02, the last time I upgraded & did a 'make install'. I did a find in /usr/ports & /usr/ports/lang/gcc5-devel was all there was. Did the compiler indeed get reinstalled ? If so, where :-) ? Also, when I did a 'make showconfig', it showed graphite support ready to go (*yipp*, kudos), but no executable that I could locate on short notice. Do I still need to compile it up, or is there an executable ready to go somewhere not-so-obvious to me :-) ? When I last compiled it up last week, I did a 'make install FORCE_PKG_REGISTER=1' which overwrote /usr/local/bin/gcc5 (not a huge issue, but still ), how do I tell it to install the executable under a different name ? BTW, I am *NOT* particularly familiar w/ the 'GNU way', so pardon me if this is a bit noobish :-/ TIA & have a good one. A bit more info, sorry for the omissions: [wam@devbox, utils, 11:00:55am] 4458 % ( lltr /usr/local/bin/*gcc* ) -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ranlib48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-nm48* -r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ar48* -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-4.8.5* -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/gcc48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-ranlib48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-nm48* -r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/gcc-ar48* lrwxr-xr-x 1 root wheel 20 Nov 30 21:35 /usr/local/bin/gcc@ -> /usr/local/bin/gcc48 -r-xr-xr-x 1 root wheel 25704 Nov 30 21:55 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ranlib* -r-xr-xr-x 1 root wheel 25704 Nov 30 21:55 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-nm* -r-xr-xr-x 1 root wheel 25736 Nov 30 21:55 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ar* -r-xr-xr-x 2 root wheel 742608 Nov 30 21:55 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-5.2.0* -r-xr-xr-x 2 root wheel 742608 Nov 30 21:55 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc* -r-xr-xr-x 3 root wheel 895144 Dec 9 02:05 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc5* -r-xr-xr-x 2 root wheel 25912 Dec 9 02:05 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ranlib5* -r-xr-xr-x 2 root wheel 25912 Dec 9 02:05 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-nm5* -r-xr-xr-x 2 root wheel 25944 Dec 9 02:05 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ar5* -r-xr-xr-x 3 root wheel 895144 Dec 9 02:05 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-5.2.1* -r-xr-xr-x 3 root wheel 895144 Dec 9 02:05 /usr/local/bin/gcc5* -r-xr-xr-x 2 root wheel 25912 Dec 9 02:05 /usr/local/bin/gcc-ranlib5* -r-xr-xr-x 2 root wheel 25912 Dec 9 02:05 /usr/local/bin/gcc-nm5* -r-xr-xr-x 2 root wheel 25944 Dec 9 02:05 /usr/local/bin/gcc-ar5* -r-xr-xr-x 3 root wheel 846360 Dec 9 05:58 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ranlib49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-nm49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-ar49* -r-xr-xr-x 3 root wheel 846360 Dec 9 05:58 /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-4.9.4* -r-xr-xr-x 3 root wheel 846360 Dec 9 05:58 /usr/local/bin/gcc49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/gcc-ranlib49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/gcc-nm49* -r-xr-xr-x 2 root wheel 25464 Dec 9 05:58 /usr/local/bin/gcc-ar49* [wam@devbox, utils, 11:01:02am] 4459 % diff /usr/local/bin/x86_64-portbld-freebsd9.3-gcc-5.2.1 /usr/local/bin/gcc5 [wam@devbox, utils, 11:01:18am] 4460 % uname -a FreeBSD devbox 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 10:11:50 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, utils, 11:02:04am] 4461 % -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. _
gcc5-devel question
I just did a 'pkg upgrade -y' when I noticed upgraded LibGL available. I was hoping it might include static versions of libGL/GLU/GLw, but no such luck. However, pkg did reinstall gcc5-devel-5.2.1.s20151124 due to changed options. I cd'ed to /usr/ports/lang/gcc5-devel & poked around a bit. I saw no files or directories dated today, the latest was dated Dec 02, the last time I upgraded & did a 'make install'. I did a find in /usr/ports & /usr/ports/lang/gcc5-devel was all there was. Did the compiler indeed get reinstalled ? If so, where :-) ? Also, when I did a 'make showconfig', it showed graphite support ready to go (*yipp*, kudos), but no executable that I could locate on short notice. Do I still need to compile it up, or is there an executable ready to go somewhere not-so-obvious to me :-) ? When I last compiled it up last week, I did a 'make install FORCE_PKG_REGISTER=1' which overwrote /usr/local/bin/gcc5 (not a huge issue, but still ), how do I tell it to install the executable under a different name ? BTW, I am *NOT* particularly familiar w/ the 'GNU way', so pardon me if this is a bit noobish :-/ TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: ongoing link issues
On 12/09/15 12:03, Dimitry Andric wrote: On 09 Dec 2015, at 17:50, William A. Mahaffey III wrote: I am still trying to statically link my inhouse code. I switched to using g++5 in the link line: ... g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -static-libgcc -static-libstdc++ -Bstatic -lgfortran -static-libgfortran && \rm -f Main.o [wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:52:04am] 920 % uname -a Instead of all the complicated stuff above, can't you simply use -static while linking? I'm not sure why you want a half-dynamic, half-static executable? If you want to link *some* of the libraries statically, you must enclose these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair. For example: -Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic Also, you should probably link using gcc5 instead of g++5, otherwise the latter might add its own -lstdc++ arguments. -Dimitry I went ahead & tried the -Wl,-Bstatic & -Wl,-Bdynamic (I show output from successful dynamic link & problematic static link for comparison): . . . chmod: /usr/local/bin/PreBFCGL.opteron.TEST.R8: No such file or directory *** [/usr/local/bin/PreBFCGL.opteron.TEST.R8] Error code 1 (ignored) ar xv /home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R8/opteron/libmaiPre.a Main.o x - Main.o g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.R8 -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc /pre/../lib/R8/opteron -L/home/wam/lib/R8 -L/usr/lib64/openmotif -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/l ib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif -lStdHash -lgfortran -l gomp -lgcc -lmpi -ltet -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm && \rm -f Main.o chmod -fv go+rx,a-w /usr/local/bin/PreBFCGL.opteron.TEST.R8 /usr/local/bin/PreBFCGL.opteron.TEST.R8 Done with /usr/local/bin/PreBFCGL.opteron.TEST.R8. MakePRE: Everything usual up to Date. Everything MemLibs up to date. Everything HashLibs up to date. Everything DumpLibs up to date. Everything BCLibs up to date. Everything allLibs up to date. chmod: /usr/local/bin/PreBFCGL.opteron.TEST.static: No such file or directory *** [/usr/local/bin/PreBFCGL.opteron.TEST.static] Error code 1 (ignored) ar xv /home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron/libmaiPre.a Main.o x - Main.o g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered /bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif -lStdHash -static-libstdc++ -Wl,-Bstatic -lgfortran -lgomp -lgcc -Wl,-Bdynamic -lmpi -ltet -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljp eg -lpng -lz -lm && \rm -f Main.o /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): In function `write_float': /usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1306: undefined reference to `sig nbitq' /usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1306: undefined reference to `fin iteq' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): In function `determine_en_precision': /usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1213: undefined reference to `fin iteq' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): In function `write_float': /usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/
Re: ongoing link issues
On 12/09/15 12:03, Dimitry Andric wrote: On 09 Dec 2015, at 17:50, William A. Mahaffey III wrote: I am still trying to statically link my inhouse code. I switched to using g++5 in the link line: ... g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -static-libgcc -static-libstdc++ -Bstatic -lgfortran -static-libgfortran && \rm -f Main.o [wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found [wam@kabini1, ~, 10:52:04am] 920 % uname -a Instead of all the complicated stuff above, can't you simply use -static while linking? I'm not sure why you want a half-dynamic, half-static executable? If you want to link *some* of the libraries statically, you must enclose these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair. For example: -Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic Also, you should probably link using gcc5 instead of g++5, otherwise the latter might add its own -lstdc++ arguments. -Dimitry Thanks for your reply. I tried '-static' earlier (see posts last week) & the linker couldn't find static libraries for LibGL, libGLU & libGLw. I also tried gcc5 to link (see earlier posts today) & it seemed to still dynamically link libstdc++, even w/ the '-static-libstdc++' argument. Your suggestion to use the explicit linker arguments -Bstatic & -Bdynamic is the next thing to try, however they will require a bit more mods to my Makefile & I thought my attempts using various '-static-lib' should/would work, based on my read of the man pages. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
ongoing link issues
ilder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@kabini1, ~, 10:52:07am] 921 % I'm sure it's pilot error, but I (think I) have iterated all combinations of (-static)-libgcc, (-static)-libstdc++ (-static)libgfortran & nothing seems to work *Any* clues appreciated :-/ TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
More static link questions
eBFCGL.bdver1.TEST.static /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by /usr/local/bin/PreBFCGL.bdver1.TEST.static not found [wam@kabini1, ~, 10:04:05am] 910 % uname -a FreeBSD kabini1.local 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22 01:54:44 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@kabini1, ~, 10:06:43am] 911 % I found that I needed both the '-lstdc++ -static-libstdc++' in the link line or the C++ stuff didn't get linked in (i.e., '-static-libstdc++' alone doesn't link). The man page for gcc5 carefully mentions using 'g++' to link C++ code, while mentioning GCC for other static-linker options, is that my problem here ? If not, any clues what is :-) ? TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: mixed language link problems
On 12/06/15 10:33, William A. Mahaffey III wrote: I am using gcc5-devel to maintain some inhouse mixed-language (C++ main & some lower stuff, *LOTTA* ANSI C, bits of FORTRAN77) program. I am getting the following link errors trying to link up a fully static version of the code to use on other machines which have minimal dev. environments installed: ar xv /home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron/libmaiPre.a Main.o x - Main.o g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static -static-libgcc -Wl,-s,--allow-multiple-definition Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../ lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-gr oup -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -Bstatic -lgfortran && \rm -f Main.o /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__getf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__addtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__eqtf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__lttf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__gttf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__subtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__divtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__multf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__netf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatsitf@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__letf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatunditf@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatditf@GCC_4.6.0' collect2: error: ld returned 1 exit status 1 error *** [/usr/local/bin/PreBFCGL.opteron.TEST.static] Error code 1 (continuing) `usual' not remade because of errors. It looks to me like the gcc5 driver is looking in the wrong place for some FORTRAN libraries, *OR* the operator forgot some link-time incantations to make this work. This set of args works on another box on my LAN, Linux, FC14 (soon to be updated to CentOS 6), Intel compiler suite, FWIW. What do I need to do to get this to link ? TIA & have a good one. *Eek* always forget: [wam@devbox, TEST, 10:18:06am] 1654 % uname -a FreeBSD devbox 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 10:11:50 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, TEST, 10:36:50am] 1655 % -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
mixed language link problems
I am using gcc5-devel to maintain some inhouse mixed-language (C++ main & some lower stuff, *LOTTA* ANSI C, bits of FORTRAN77) program. I am getting the following link errors trying to link up a fully static version of the code to use on other machines which have minimal dev. environments installed: ar xv /home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron/libmaiPre.a Main.o x - Main.o g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static -static-libgcc -Wl,-s,--allow-multiple-definition Main.o -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../ lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-gr oup -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -Bstatic -lgfortran && \rm -f Main.o /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__getf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__addtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__eqtf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__lttf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__gttf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__subtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__divtf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__multf3@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__netf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatsitf@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__letf2@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatunditf@GCC_4.6.0' /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.so: undefined reference to `__floatditf@GCC_4.6.0' collect2: error: ld returned 1 exit status 1 error *** [/usr/local/bin/PreBFCGL.opteron.TEST.static] Error code 1 (continuing) `usual' not remade because of errors. It looks to me like the gcc5 driver is looking in the wrong place for some FORTRAN libraries, *OR* the operator forgot some link-time incantations to make this work. This set of args works on another box on my LAN, Linux, FC14 (soon to be updated to CentOS 6), Intel compiler suite, FWIW. What do I need to do to get this to link ? TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: gcc5 question
On 12/02/15 18:33, Gerald Pfeifer wrote: On Thu, 3 Dec 2015, Dimitry Andric wrote: I just did a pkg-upgrade of gcc5, & upgraded the port as well. I noticed that a 'make showconfig' in the port now shows Graphite support enabled by default. However, a 'gcc -v --help' on the pkg installed version shows no libisl, req'd for Graphite support (I think). Is the pkg built differently from the port ? TIA & have a good one. I've tried building the port with the GRAPHITE option enabled, but it died with various compilation errors about missing isl types, even while isl was installed. So I'm not sure about the state of this support. :-) Gerald, any idea? I suppose the option is expected to work? If you have an up-to-date lang/gcc5 port, you should not be able to specify GRAPHITE any longer. Somehow my testing must have been flawed (even though I recall it explicitly tested, so perhaps a typo when specifying the option) and this will be fixed when updating to GCC 5.3, hopefully in the next few days. Give lang/gcc5-devel a try, which is close to what GCC 5.3 is going to be. That one should work. I tested it again yesterday, just to be sure. Gerald ___ freebsd-questi...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" It was/is indeed gcc5-devel, & I am compiling it up now, so all is well AFA it does indeed appear to compile OK & work (I have gotten some inhouse to compile up today, to test it overnight). Sorry for the confusion :-/. On a related topic, it would be sweet if the devel compiler were installed in /usr/local/bin, w/ a slightly different name (gcc5X, gcc5d, maybe gcc521(X|d), you get the picture), for convenient back-to-back comparisons if req'd -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
gcc5 question
I just did a pkg-upgrade of gcc5, & upgraded the port as well. I noticed that a 'make showconfig' in the port now shows Graphite support enabled by default. However, a 'gcc -v --help' on the pkg installed version shows no libisl, req'd for Graphite support (I think). Is the pkg built differently from the port ? TIA & have a good one. *K* I meant gcc5-devel, sorry :-/ -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
gcc5 question
I just did a pkg-upgrade of gcc5, & upgraded the port as well. I noticed that a 'make showconfig' in the port now shows Graphite support enabled by default. However, a 'gcc -v --help' on the pkg installed version shows no libisl, req'd for Graphite support (I think). Is the pkg built differently from the port ? TIA & have a good one. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [Re-post from users]: gmake question
On 12/01/15 07:35, William A. Mahaffey III wrote: I am using gmake under FreeBSD 9.3R to (try to) maintain some inhouse mixed language code (ANSI C, some c++, FORTRAN 77). I have a utility library which I use to hold C & c++ object files, using the 'target::' syntax. This works AOK under Linux (gmake 3.8.2), puts both types of objects in the same library smooth as silk. However under FreeBSD (gmake 4.1.2), it only puts the 1st group of objects in, either the C or c++ depending on which is 1st in the makefile. When I try the 'target:' syntax, it wound up deleting some of my source files (!). I reproduce the relevant parts of the makefile below: . . . . force: clean all depend: @makedepend -- $(CFLAGS) -- -f Makefile $(SRCS) @\rm -f Makefile.bak @cp -p Makefile MakeUtils @echo MakeUtils: Done with $@. iccdepend: @icc $(IFLAGS) -c -MM -MF depends.inc $(SRCS) @echo MakeUtils: Done with $@. $(LIB):: $(CPPSRC) $(CC) $(CPPFLAGS) -c $? ar ruv $@ ${?:.cpp=.o} && rm -f ${?:.cpp=.o} @echo MakeUtils: Done with $@. $(LIB):: $(SRCS) $(CC) $(CFLAGS) -c $? ar ruv $@ ${?:.c=.o} && rm -f ${?:.c=.o} @echo MakeUtils: Done with $@. # DO NOT DELETE THIS LINE -- make depend depends on it. CPPSRC lists the c++ files & SRCS lists the C files. Is this supposed to work under FreeBSD 9.3R & this version of gmake ? TIA for any pointers & have a good one. BTW: [wam@devbox, pre, 8:08:13pm] 2846 % uname -a FreeBSD devbox 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 10:11:50 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, pre, 8:08:16pm] 2847 % grep make /etc/LIST.installed.txt automake-1.15_1GNU Standards-compliant Makefile generator automake-wrapper-20131203 Wrapper script for GNU automake gmake-4.1_2GNU version of 'make' utility libxklavier-5.3_1,1Utility library to make XKB stuff easier makedepend-1.0.5,1 Dependency generator for makefiles [wam@devbox, pre, 8:08:53pm] 2848 % Update: I went ahead & downloaded & installed (in /usr/local/bin) GNU make 3.8.2 & it indeed works as expected & as I interpret the online docs. Bug in make 4.1.2 ? Any more info wanted, just ask -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Re-post from users]: gmake question
I am using gmake under FreeBSD 9.3R to (try to) maintain some inhouse mixed language code (ANSI C, some c++, FORTRAN 77). I have a utility library which I use to hold C & c++ object files, using the 'target::' syntax. This works AOK under Linux (gmake 3.8.2), puts both types of objects in the same library smooth as silk. However under FreeBSD (gmake 4.1.2), it only puts the 1st group of objects in, either the C or c++ depending on which is 1st in the makefile. When I try the 'target:' syntax, it wound up deleting some of my source files (!). I reproduce the relevant parts of the makefile below: . . . . force: clean all depend: @makedepend -- $(CFLAGS) -- -f Makefile $(SRCS) @\rm -f Makefile.bak @cp -p Makefile MakeUtils @echo MakeUtils: Done with $@. iccdepend: @icc $(IFLAGS) -c -MM -MF depends.inc $(SRCS) @echo MakeUtils: Done with $@. $(LIB):: $(CPPSRC) $(CC) $(CPPFLAGS) -c $? ar ruv $@ ${?:.cpp=.o} && rm -f ${?:.cpp=.o} @echo MakeUtils: Done with $@. $(LIB):: $(SRCS) $(CC) $(CFLAGS) -c $? ar ruv $@ ${?:.c=.o} && rm -f ${?:.c=.o} @echo MakeUtils: Done with $@. # DO NOT DELETE THIS LINE -- make depend depends on it. CPPSRC lists the c++ files & SRCS lists the C files. Is this supposed to work under FreeBSD 9.3R & this version of gmake ? TIA for any pointers & have a good one. BTW: [wam@devbox, pre, 8:08:13pm] 2846 % uname -a FreeBSD devbox 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 10:11:50 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, pre, 8:08:16pm] 2847 % grep make /etc/LIST.installed.txt automake-1.15_1GNU Standards-compliant Makefile generator automake-wrapper-20131203 Wrapper script for GNU automake gmake-4.1_2GNU version of 'make' utility libxklavier-5.3_1,1Utility library to make XKB stuff easier makedepend-1.0.5,1 Dependency generator for makefiles [wam@devbox, pre, 8:08:53pm] 2848 % -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-questi...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] amd64-gcc question
On 11/20/15 16:29, Gerald Pfeifer wrote: On Sun, 15 Nov 2015, Gerald Pfeifer wrote: I just committed changes to lang/gcc6-devel and lang/gcc5-devel to add support for Graphite with a new option GRAPHITE. This is off by default, but you can enable it, rebuild the port, and then have what you've been looking for. lang/gcc5, which tracks upstream releases, now also has this. I am not planning to push this into older releases of GCC since Graphite support there is sufficiently different (and less mature). Gerald Roger that, thanks :-). I am having other problems which I am taking up w/ GNU, so we'll see what happens. Thanks again. -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] GCC 4.8.5 compiler bug
On 11/17/15 17:56, Gerald Pfeifer wrote: Hi William, On Tue, 17 Nov 2015, William A. Mahaffey III wrote: I have found & apparently isolated what looks like a compiler bug in (pkg-installed, box-stock) gcc48 under FreeBSD 9.3R, see attached. I also prepped a tarball w/ the files that produced the problem for me. Do I post that here or to GNU ? TIA & have a good one GCC 4.8 is a little old, and most likely won't attract attention by upstream developers. Does this reproduce with newer version such as GCC 5? If so, that would make a report with higher chances of getting addressed. If not, can you use such a newer version? Gerald Yes (occurred on 5.2.1 originally), that's why I bumped back to 4.8.5, I thought the newer development version might have some new 'features' that were acting up .... -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
GCC 4.8.5 compiler bug
I have found & apparently isolated what looks like a compiler bug in (pkg-installed, box-stock) gcc48 under FreeBSD 9.3R, see attached. I also prepped a tarball w/ the files that produced the problem for me. Do I post that here or to GNU ? TIA & have a good one -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. [wam@devbox, utils, 9:24:17am] 770 % make gcc48 -DNDEBUG -DUNDER_SCORE_SYS -DLOSE_GAMMAL -I../include -I../Properties -I../TEST -I../pre -I/usr/local/include -march=opteron -mtune=opteron -O3 -fprefetch-loop-arrays -fopt-info-loop-optimized -march=opteron -mtune=opteron -DP64_BIT -c gauss.cpp gauss.cpp: In function 'int testGauss(char*, int, uint)': gauss.cpp:332:43: error: 'PrintdGM' was not declared in this scope PrintdGM (stderr, "A", A, FALSE, 10, N, N), PrintdA (stderr, "B", B, 10, N), fprintf (stderr, "\n"), fflush (NULL); ^ gauss.cpp:332:76: error: 'PrintdA' was not declared in this scope PrintdGM (stderr, "A", A, FALSE, 10, N, N), PrintdA (stderr, "B", B, 10, N), fprintf (stderr, "\n"), fflush (NULL); ^ gauss.cpp: In function 'int TestGaussCPP(char*, float, int, uint)': gauss.cpp:342:38: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", 2, 2); ^ gauss.cpp:343:38: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", 2, 3); ^ gauss.cpp:344:38: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", 2, 4); ^ gauss.cpp:345:38: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", 2, 9); ^ gauss.cpp:346:45: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", chatty, 100); ^ gauss.cpp:347:45: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", chatty, 200); ^ gauss.cpp:348:45: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", chatty, 500); ^ gauss.cpp:349:46: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", chatty, 1000); ^ gauss.cpp:350:46: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] testGauss ("TestGauss(C++)", chatty, 2000); ^ *** [../lib/opteron/libutils.a] Error code 1 (continuing) `usual' not remade because of errors. 1 error [wam@devbox, utils, 9:24:22am] 771 % uname -a FreeBSD devbox 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22 01:54:44 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, utils, 9:24:25am] 772 % gcc48 --version gcc48 (FreeBSD Ports Collection) 4.8.5 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. [wam@devbox, utils, 9:24:27am] 773 % ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] amd64-gcc question
On 11/15/15 13:58, Gerald Pfeifer wrote: On Thu, 12 Nov 2015, William A. Mahaffey III wrote: I pkg-installed amd64-gcc over the weekend hoping for Graphite (auto-loop parallelization) support, but no go. When you say "amd64-gcc" where did you obtain that from? As a FreeBSD port/package, or somewhere else? I pkg-installed it originally, but as of last Monday, there was a port as well, I did a 'portsnap fetch update' (all box-stock ports configs) & there it was just did a 'portsnap fetch upgrade' & there is now a port for amd64-gcc, but it includes no files & no pkg-descr file. This is a little weird. I have packaged GCC 4.6 (lang/gcc46), GCC 4.7 (lang/gcc47), GCC 4.8 (lang/gcc48), GCC 4.9 (lang/gcc49), GCC 5 (lang/gcc5 and lang/gcc5-devel) and GCC 6 snapshot (lang/gcc6-devel) as well as the "canonical" version of GCC (lang/gcc, currently GCC 4.8 and in the process of being moved to GCC 4.9). All of these build and package on amd64, feature pkg-descr, etc. And as a FreeBSD user leveraging the official FreeBSD Ports Collection is the recommended approach. None of them would be called amd64-gcc or similar, though. amd64-gcc-5.2.0 amd64-xtoolchain-gcc-0.1 is what pkg calls them I have gotten as far as running 'make showconfig' in the various gcc* & amd64-gcc directories to see what info I could get on default config options. In all cases they gave options & said to run 'make config' to change options. I didn't even see a 'config:' entry in the Makefiles (probably included from elsewhere, but I didn't chase it). Let's focus on lang/gcc5-devel, which is the most reasonable version to enable Graphite for right now since GCC 5 is the current release series and hence most stable, but also advanced, and the -devel port is more suitable for making changes like this than the "production" variant. And indeed lang/gcc5-devel/Makefile already had the following lines, which is how options handling actually works: OPTIONS_DEFINE= BOOTSTRAP OPTIONS_DEFINE_i386=JAVA OPTIONS_DEFINE_amd64= JAVA OPTIONS_DEFAULT=BOOTSTRAP OPTIONS_DEFAULT_i386= JAVA OPTIONS_DEFAULT_amd64= JAVA I see no configure files for any of the gcc ports (I have the entire ports tree downloaded & local, & freshly updated as of a few min. ago). What is the canonical/BPP (FreeBSD 9.3R) way of recompiling a port with different config flags ? I did find ports/pkgs for the 2 main components apparently needed for Graphite support (cloog & ppl) & pkg-installed them over the weekend, so I am ready to go on that front. If you check out the GCC release notes at https://gcc.gnu.org/gcc-5/changes.html you will find that "The Graphite framework for loop optimizations no longer requires the CLooG library, only ISL version 0.14 (recommended) or 0.12.2." I just committed changes to lang/gcc6-devel and lang/gcc5-devel to add support for Graphite with a new option GRAPHITE. This is off by default, but you can enable it, rebuild the port, and then have what you've been looking for. Gerald *Excellent*, thanks muchly :-). I'll buy you a beer next time we meet ;-) -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: amd64-gcc question
On 11/14/15 18:36, William A. Mahaffey III wrote: On 11/12/15 08:20, William A. Mahaffey III wrote: Howdy, new to this list. I posted this to FreeBSD-users & was advised to try this list or the GNU GCC list, so here goes: I pkg-installed amd64-gcc over the weekend hoping for Graphite (auto-loop parallelization) support, but no go. I looked around over the weekend & found that there was no port for that package, only the pkg. I just did a 'portsnap fetch upgrade' & there is now a port for amd64-gcc, but it includes no files & no pkg-descr file. I determined over the weekend that the gcc's from about V4.3 on can indeed be built w/ Graphite support, but you need to do it manually. I found a post dated 2010 from someone who did it under linux: http://openwall.info/wiki/internal/gcc-local-build. I see no configure files for any of the gcc ports (I have the entire ports tree downloaded & local, & freshly updated as of a few min. ago). What is the canonical/BPP (FreeBSD 9.3R) way of recompiling a port with different config flags ? I did find ports/pkgs for the 2 main components apparently needed for Graphite support (cloog & ppl) & pkg-installed them over the weekend, so I am ready to go on that front. I have gotten as far as running 'make showconfig' in the various gcc* & amd64-gcc directories to see what info I could get on default config options. In all cases they gave options & said to run 'make config' to change options. I didn't even see a 'config:' entry in the Makefiles (probably included from elsewhere, but I didn't chase it). I only want to make the minimum # of config mods necessary (trusting that pkg/port maintainers probably know more than I about their various pkg's & ports) to add the cloog & ppl support & recompile. I have been using pkg almost exclusively to maintain my (now 3) FreeBSD 9.3R boxen, except for recompiling the linux-c6 flash plugin for this box whenever it get upgraded, so I have *no* experience with getting more nitty-gritty w/ FreeBSD ports than that :-/. TIA & have a good one. BTW: [wam@devbox, pre, 8:19:58am] 676 % uname -a FreeBSD devbox 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22 01:54:44 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, pre, 8:20:00am] 677 % sysctl -A | grep -A1 -B1 model hw.machine: amd64 hw.model: AMD A8-6500 APU with Radeon(tm) HD Graphics hw.ncpu: 4 -- dev.rgephy.0.%location: phyno=1 dev.rgephy.0.%pnpinfo: oui=0xe04c model=0x0 rev=0x0 dev.rgephy.0.%parent: miibus0 [wam@devbox, pre, 8:20:12am] 678 % Updated info & a question or 2: [wam@devbox, pre, 1:07:58pm] 876 % ^8^9^ gcc49 -v --help Using built-in specs. COLLECT_GCC=gcc49 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.3/4.9.4/lto-wrapper Usage: gcc49 [options] file... Options: -pass-exit-codes Exit with highest error code from a phase --help Display this information --target-helpDisplay target specific command line options --help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...] Display specific types of command line options --versionDisplay compiler version information -dumpspecs Display all of the built in spec strings -dumpversion Display the version of the compiler -dumpmachine Display the compiler's target processor -print-search-dirs Display the directories in the compiler's search path -print-libgcc-file-name Display the name of the compiler's companion library -print-file-name= Display the full path to library -print-prog-name= Display the full path to compiler component -print-multiarch Display the target's normalized GNU triplet, used as a component in the library path -print-multi-directory Display the root directory for versions of libgcc -print-multi-lib Display the mapping between command line options and multiple library search directories -print-multi-os-directory Display the relative path to OS libraries -print-sysroot Display the target libraries directory -print-sysroot-headers-suffix Display the sysroot suffix used to find headers -Wa,Pass comma-separated on to the assembler -Wp,Pass comma-separated on to the preprocessor -Wl,Pass comma-separated on to the linker -Xassembler Pass on to the assembler -Xpreprocessor Pass on to the preprocessor -XlinkerPass on to the linker -save-temps Do not delete intermediate files -save-temps=Do not delete intermediate files -no-canonical-prefixes Do not canonicalize
Re: amd64-gcc question
On 11/12/15 08:20, William A. Mahaffey III wrote: Howdy, new to this list. I posted this to FreeBSD-users & was advised to try this list or the GNU GCC list, so here goes: I pkg-installed amd64-gcc over the weekend hoping for Graphite (auto-loop parallelization) support, but no go. I looked around over the weekend & found that there was no port for that package, only the pkg. I just did a 'portsnap fetch upgrade' & there is now a port for amd64-gcc, but it includes no files & no pkg-descr file. I determined over the weekend that the gcc's from about V4.3 on can indeed be built w/ Graphite support, but you need to do it manually. I found a post dated 2010 from someone who did it under linux: http://openwall.info/wiki/internal/gcc-local-build. I see no configure files for any of the gcc ports (I have the entire ports tree downloaded & local, & freshly updated as of a few min. ago). What is the canonical/BPP (FreeBSD 9.3R) way of recompiling a port with different config flags ? I did find ports/pkgs for the 2 main components apparently needed for Graphite support (cloog & ppl) & pkg-installed them over the weekend, so I am ready to go on that front. I have gotten as far as running 'make showconfig' in the various gcc* & amd64-gcc directories to see what info I could get on default config options. In all cases they gave options & said to run 'make config' to change options. I didn't even see a 'config:' entry in the Makefiles (probably included from elsewhere, but I didn't chase it). I only want to make the minimum # of config mods necessary (trusting that pkg/port maintainers probably know more than I about their various pkg's & ports) to add the cloog & ppl support & recompile. I have been using pkg almost exclusively to maintain my (now 3) FreeBSD 9.3R boxen, except for recompiling the linux-c6 flash plugin for this box whenever it get upgraded, so I have *no* experience with getting more nitty-gritty w/ FreeBSD ports than that :-/. TIA & have a good one. BTW: [wam@devbox, pre, 8:19:58am] 676 % uname -a FreeBSD devbox 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22 01:54:44 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, pre, 8:20:00am] 677 % sysctl -A | grep -A1 -B1 model hw.machine: amd64 hw.model: AMD A8-6500 APU with Radeon(tm) HD Graphics hw.ncpu: 4 -- dev.rgephy.0.%location: phyno=1 dev.rgephy.0.%pnpinfo: oui=0xe04c model=0x0 rev=0x0 dev.rgephy.0.%parent: miibus0 [wam@devbox, pre, 8:20:12am] 678 % Updated info & a question or 2: [wam@devbox, pre, 1:07:58pm] 876 % ^8^9^ gcc49 -v --help Using built-in specs. COLLECT_GCC=gcc49 COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc49/gcc/x86_64-portbld-freebsd9.3/4.9.4/lto-wrapper Usage: gcc49 [options] file... Options: -pass-exit-codes Exit with highest error code from a phase --help Display this information --target-helpDisplay target specific command line options --help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...] Display specific types of command line options --versionDisplay compiler version information -dumpspecs Display all of the built in spec strings -dumpversion Display the version of the compiler -dumpmachine Display the compiler's target processor -print-search-dirs Display the directories in the compiler's search path -print-libgcc-file-name Display the name of the compiler's companion library -print-file-name= Display the full path to library -print-prog-name= Display the full path to compiler component -print-multiarch Display the target's normalized GNU triplet, used as a component in the library path -print-multi-directory Display the root directory for versions of libgcc -print-multi-lib Display the mapping between command line options and multiple library search directories -print-multi-os-directory Display the relative path to OS libraries -print-sysroot Display the target libraries directory -print-sysroot-headers-suffix Display the sysroot suffix used to find headers -Wa,Pass comma-separated on to the assembler -Wp,Pass comma-separated on to the preprocessor -Wl,Pass comma-separated on to the linker -Xassembler Pass on to the assembler -Xpreprocessor Pass on to the preprocessor -XlinkerPass on to the linker -save-temps Do not delete intermediate files -save-temps=Do not delete intermediate files -no-canonical-prefixes Do not canonicalize paths when building relative prefixes
amd64-gcc question
Howdy, new to this list. I posted this to FreeBSD-users & was advised to try this list or the GNU GCC list, so here goes: I pkg-installed amd64-gcc over the weekend hoping for Graphite (auto-loop parallelization) support, but no go. I looked around over the weekend & found that there was no port for that package, only the pkg. I just did a 'portsnap fetch upgrade' & there is now a port for amd64-gcc, but it includes no files & no pkg-descr file. I determined over the weekend that the gcc's from about V4.3 on can indeed be built w/ Graphite support, but you need to do it manually. I found a post dated 2010 from someone who did it under linux: http://openwall.info/wiki/internal/gcc-local-build. I see no configure files for any of the gcc ports (I have the entire ports tree downloaded & local, & freshly updated as of a few min. ago). What is the canonical/BPP (FreeBSD 9.3R) way of recompiling a port with different config flags ? I did find ports/pkgs for the 2 main components apparently needed for Graphite support (cloog & ppl) & pkg-installed them over the weekend, so I am ready to go on that front. I have gotten as far as running 'make showconfig' in the various gcc* & amd64-gcc directories to see what info I could get on default config options. In all cases they gave options & said to run 'make config' to change options. I didn't even see a 'config:' entry in the Makefiles (probably included from elsewhere, but I didn't chase it). I only want to make the minimum # of config mods necessary (trusting that pkg/port maintainers probably know more than I about their various pkg's & ports) to add the cloog & ppl support & recompile. I have been using pkg almost exclusively to maintain my (now 3) FreeBSD 9.3R boxen, except for recompiling the linux-c6 flash plugin for this box whenever it get upgraded, so I have *no* experience with getting more nitty-gritty w/ FreeBSD ports than that :-/. TIA & have a good one. BTW: [wam@devbox, pre, 8:19:58am] 676 % uname -a FreeBSD devbox 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat Aug 22 01:54:44 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 [wam@devbox, pre, 8:20:00am] 677 % sysctl -A | grep -A1 -B1 model hw.machine: amd64 hw.model: AMD A8-6500 APU with Radeon(tm) HD Graphics hw.ncpu: 4 -- dev.rgephy.0.%location: phyno=1 dev.rgephy.0.%pnpinfo: oui=0xe04c model=0x0 rev=0x0 dev.rgephy.0.%parent: miibus0 [wam@devbox, pre, 8:20:12am] 678 % -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ freebsd-questi...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org" ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"