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-toolchain
To unsubscribe, send any mail to
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: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" <w...@hiwaay.net
<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: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"
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: 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" <w...@hiwaay.net
<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=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=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-- 1 root wheel 1327342 Oct 5 2014 make-4.1.tar.bz2
-rw-r--r-- 1 root wheel 85807011 Oct 28
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
.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"
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"
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: ongoing link issues
On 12/09/15 12:03, Dimitry Andric wrote: On 09 Dec 2015, at 17:50, William A. Mahaffey III <w...@hiwaay.net> 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/write_float.d
Re: ongoing link issues
On 12/09/15 12:03, Dimitry Andric wrote: On 09 Dec 2015, at 17:50, William A. Mahaffey III <w...@hiwaay.net> 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"
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"
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"
[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"
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: 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 paths when building
relative
prefixes to other gcc
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/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 to other gcc components
-pipeUse pipes rather than inte
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"
