Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mon, Mar 11, 2013 at 02:18:51PM -0700, Steve Kargl wrote: On Mon, Mar 11, 2013 at 10:05:47PM +0100, Dimitry Andric wrote: On 2013-03-11 20:00, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 $ echo 'sub/foo.barx' | env -i grep sub/foo.bar $ echo 'sub/foolbarx' | env -i grep sub/foo.bar $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar' sub/foo.barx $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar sub/foo.barx A buggy shortcut? No, after some digging in and debugging of the bsdgrep code, I found out it is a regression caused by r246917, which is a fix for bin/175213: [patch] bsdgrep(1) segfaults upon malicious input. If you revert it, bsdgrep starts working correctly again. First, I can report that bootstrapping gcc-4.8.0 works if I use gnugrep instead of bsdgrep. The above explains why I had previously seen the failure as I was using an older bsdgrep. Second, an apology is owed to the clang gang as I attributed the problem to clang as it showed up on my system after converted everything over to clang. I think it would be best to back out r246917 for now, until the regression can be fixed properly. Having bsdgrep crash is bad, but not returning any results while it should is even worse... I tend to agree with your assessment that r246817 should be reverted, because I hit this issue in configure scripts and there is a large amount of software that uses autotool for configuration. Sorry about this, I will revert it and revisit the problem. I've been using bsdgrep by default for a while and somehow haven't run into this. -Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
Am 03/11/13 11:17, schrieb Dimitry Andric: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? I have build port lang/gcc and lang/gcc46 recently on another box running the same configuration files like the boxes which fail (/etc/make.conf and /etc/src.conf). When removing /etc/make.conf and /etc/src.conf as requested, first thing I realize is that perl 5.14 wants to be installed - while I use throughout all systems perl 5.16. Having the default /etc/make.conf with only the PERL specific adaption PER_VERSION=5.16.2 gives a quite short journey into compiling lang/gcc with the following error: cc -c -DHAVE_CONFIG_H -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I. -I.././../gcc-4.6.3/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic .././../gcc-4.6.3/libiberty/strverscmp.c -o strverscmp.o rm -f ./libiberty.a pic/./libiberty.a /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o /usr/local/bin/ranlib ./libiberty.a if [ x-fpic != x ]; then \ cd pic; \ /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o; \ /usr/local/bin/ranlib ./libiberty.a; \ cd ..; \ else true; fi gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/libiberty' gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 03/11/2013 11:17, Dimitry Andric wrote: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org FWIW, Yesterday, I built lang/gcc on a 10.0-CURRENT amd64 svn 247236, WITH_CLANG_IS_CC, and got the same error than the OP. NO non-default CFLAGS. The build succeeded with USE_GCC=any I tried to restore the bootstrap phase by partially reverting r302041, and the build errored with clang AND with the base gcc, at another place (some double definitions building libcpp). Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 2013-03-11 11:58, Hartmann, O. wrote: Am 03/11/13 11:17, schrieb Dimitry Andric: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? I have build port lang/gcc and lang/gcc46 recently on another box running the same configuration files like the boxes which fail (/etc/make.conf and /etc/src.conf). When removing /etc/make.conf and /etc/src.conf as requested, first thing I realize is that perl 5.14 wants to be installed - while I use throughout all systems perl 5.16. Having the default /etc/make.conf with only the PERL specific adaption PER_VERSION=5.16.2 gives a quite short journey into compiling lang/gcc with the following error: cc -c -DHAVE_CONFIG_H -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I. -I.././../gcc-4.6.3/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic .././../gcc-4.6.3/libiberty/strverscmp.c -o strverscmp.o rm -f ./libiberty.a pic/./libiberty.a /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o /usr/local/bin/ranlib ./libiberty.a if [ x-fpic != x ]; then \ cd pic; \ /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o; \ /usr/local/bin/ranlib ./libiberty.a; \ cd ..; \ else true; fi gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/libiberty' gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Do you, by any chance, use BSD grep? Regards! -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mon, 2013-03-11 at 12:00 +0100, Niclas Zeising wrote: On 2013-03-11 11:58, Hartmann, O. wrote: Am 03/11/13 11:17, schrieb Dimitry Andric: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? I have build port lang/gcc and lang/gcc46 recently on another box running the same configuration files like the boxes which fail (/etc/make.conf and /etc/src.conf). When removing /etc/make.conf and /etc/src.conf as requested, first thing I realize is that perl 5.14 wants to be installed - while I use throughout all systems perl 5.16. Having the default /etc/make.conf with only the PERL specific adaption PER_VERSION=5.16.2 gives a quite short journey into compiling lang/gcc with the following error: cc -c -DHAVE_CONFIG_H -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I. -I.././../gcc-4.6.3/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic .././../gcc-4.6.3/libiberty/strverscmp.c -o strverscmp.o rm -f ./libiberty.a pic/./libiberty.a /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o /usr/local/bin/ranlib ./libiberty.a if [ x-fpic != x ]; then \ cd pic; \ /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o; \ /usr/local/bin/ranlib ./libiberty.a; \ cd ..; \ else true; fi gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/libiberty' gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Do you, by any chance, use BSD grep? Regards! Yes, I do. But I use it on ALL systems, even on that box, which is compiling lang/gcc. But that specific box is Ivy-Bridge architecture, the others are all C2D (if, and only if the tuning of the compiler CLANG is miscompiling code affecting this issue ...). Oliver signature.asc Description: This is a digitally signed message part
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 03/11/2013 12:00, Niclas Zeising wrote: On 2013-03-11 11:58, Hartmann, O. wrote: Am 03/11/13 11:17, schrieb Dimitry Andric: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. What happens if you remove make.conf and src.conf, do the gcc ports then build successfully? I have build port lang/gcc and lang/gcc46 recently on another box running the same configuration files like the boxes which fail (/etc/make.conf and /etc/src.conf). When removing /etc/make.conf and /etc/src.conf as requested, first thing I realize is that perl 5.14 wants to be installed - while I use throughout all systems perl 5.16. Having the default /etc/make.conf with only the PERL specific adaption PER_VERSION=5.16.2 gives a quite short journey into compiling lang/gcc with the following error: cc -c -DHAVE_CONFIG_H -O2 -pipe -I/usr/local/include -fno-strict-aliasing -I. -I.././../gcc-4.6.3/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic .././../gcc-4.6.3/libiberty/strverscmp.c -o strverscmp.o rm -f ./libiberty.a pic/./libiberty.a /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o /usr/local/bin/ranlib ./libiberty.a if [ x-fpic != x ]; then \ cd pic; \ /usr/local/bin/ar rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./sort.o ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./mempcpy.o ./strverscmp.o; \ /usr/local/bin/ranlib ./libiberty.a; \ cd ..; \ else true; fi gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/libiberty' gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Do you, by any chance, use BSD grep? Regards! TILT !! I remade my world (same source, but WITH_BSD_GREP (and WITH_BSD_PATCH) commented out in src.conf), and now lang/gcc can be built/installed without error with clang. BTW, I already had to force the use of gnugrep in some scripts, because bsdgrep do not support constructs like: ...| grep -f - ... Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mon, Mar 11, 2013 at 11:17:51AM +0100, Dimitry Andric wrote: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? Note, I said explicitly said *bootstrap*. I can build 4.6, 4.7, and 4.8. I cannot *bootstrap* these compilers. The entire build log from 'gmake bootstrap | tee gcc-4.8.0.log' is here http://troutmask.apl.washington.edu/gcc-4.8.0.log The last few lines are checking whether /home/sgk/gcc/obj4x/./prev-gcc/xgcc -B/home/sgk/gcc/obj4x/./prev-gcc/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/lib/ -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/include -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/sys-includesupports -fno-rtti... yes checking dependency style of /home/sgk/gcc/obj4x/./prev-gcc/xg++ -B/home/sgk/gcc/obj4x/./prev-gcc/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -nostdinc++ -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include/x86_64-unknown-freebsd10.0 -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include -I/home/sgk/gcc/gcc4x/libstdc++-v3/libsupc++ -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage2-libcpp] Error 1 gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake: *** [bootstrap] Error 2 I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. No. Here's my make.conf. KERNCONF=SPEW CPUTYPE?=opteron FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MALLOC_PRODUCTION=YES WITHOUT_LIB32=YES WITHOUT_MODULES=YES WITHOUT_NLS=YES WITH_BSD_GREP=YES WITH_PROFILE=YES WITH_PKGNG=yes PRINTERDEVICE=ps # # Crap for ports. # DISABLE_MAKE_JOBS=YES WITH_GHOSTSCRIPT_VER=8 # # added by use.perl 2013-02-19 12:45:06 PERL_VERSION=5.12.4 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 03/11/13 14:13, Steve Kargl wrote: On Mon, Mar 11, 2013 at 11:17:51AM +0100, Dimitry Andric wrote: On 2013-03-10 00:39, Steve Kargl wrote: ... If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. I have built the lang/gcc47 and lang/gcc48 ports just now, and they compiled without any issues. What is the exact error you have been getting? Note, I said explicitly said *bootstrap*. I can build 4.6, 4.7, and 4.8. I cannot *bootstrap* these compilers. The entire build log from 'gmake bootstrap | tee gcc-4.8.0.log' is here http://troutmask.apl.washington.edu/gcc-4.8.0.log The last few lines are checking whether /home/sgk/gcc/obj4x/./prev-gcc/xgcc -B/home/sgk/gcc/obj4x/./prev-gcc/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/lib/ -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/include -isystem /home/sgk/work/4x/x86_64-unknown-freebsd10.0/sys-includesupports -fno-rtti... yes checking dependency style of /home/sgk/gcc/obj4x/./prev-gcc/xg++ -B/home/sgk/gcc/obj4x/./prev-gcc/ -B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/ -nostdinc++ -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs -B/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include/x86_64-unknown-freebsd10.0 -I/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/include -I/home/sgk/gcc/gcc4x/libstdc++-v3/libsupc++ -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs -L/home/sgk/gcc/obj4x/prev-x86_64-unknown-freebsd10.0/libstdc++-v3/libsupc++/.libs... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage2-libcpp] Error 1 gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj4x' gmake: *** [bootstrap] Error 2 I think there must be a common problem you and Oliver have in your build environment, most likely non-default CFLAGS. No. Here's my make.conf. KERNCONF=SPEW CPUTYPE?=opteron FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MALLOC_PRODUCTION=YES WITHOUT_LIB32=YES WITHOUT_MODULES=YES WITHOUT_NLS=YES WITH_BSD_GREP=YES WITH_PROFILE=YES WITH_PKGNG=yes PRINTERDEVICE=ps # # Crap for ports. # DISABLE_MAKE_JOBS=YES WITH_GHOSTSCRIPT_VER=8 # # added by use.perl 2013-02-19 12:45:06 PERL_VERSION=5.12.4 This is most likely due to a incompatibility between bsd grep and gnu grep. Try to switch to gnu grep, and the problem will most likely go away. Regards! -- Niclas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 2013-03-11 14:15, Niclas Zeising wrote: On 03/11/13 14:13, Steve Kargl wrote: ... No. Here's my make.conf. KERNCONF=SPEW CPUTYPE?=opteron FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MALLOC_PRODUCTION=YES WITHOUT_LIB32=YES WITHOUT_MODULES=YES WITHOUT_NLS=YES WITH_BSD_GREP=YES WITH_PROFILE=YES WITH_PKGNG=yes PRINTERDEVICE=ps # # Crap for ports. # DISABLE_MAKE_JOBS=YES WITH_GHOSTSCRIPT_VER=8 # # added by use.perl 2013-02-19 12:45:06 PERL_VERSION=5.12.4 This is most likely due to a incompatibility between bsd grep and gnu grep. Try to switch to gnu grep, and the problem will most likely go away. Yes, this is definitely due to a BSD grep bug. The depcomp tests create a file sub/conftest.Po, containing: sub/conftest.o: sub/conftest.c sub/conftst1.h sub/conftst2.h \ sub/conftst3.h sub/conftst4.h sub/conftst5.h sub/conftst6.h sub/conftst1.h: sub/conftst2.h: sub/conftst3.h: sub/conftst4.h: sub/conftst5.h: sub/conftst6.h: Then it runs grep sub/conftest.o sub/conftest.Po, which fails with BSD grep, and succeeds with GNU grep. BSD grep does something very strange here: $ echo 'foo.bar' | grep foo.bar foo.bar $ echo 'foo.barx' | grep foo.bar foo.barx $ echo 'sub/foo.bar' | grep sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 So why does it not match in the last case? GNU grep works: $ echo 'sub/foo.barx' | gnugrep sub/foo.bar sub/foo.barx ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mon, 2013-03-11 at 17:29 +0100, Dimitry Andric wrote: On 2013-03-11 14:15, Niclas Zeising wrote: On 03/11/13 14:13, Steve Kargl wrote: ... No. Here's my make.conf. KERNCONF=SPEW CPUTYPE?=opteron FFLAGS+= -O2 -pipe -march=native -mtune=native -funroll-loops -ftree-vectorize MALLOC_PRODUCTION=YES WITHOUT_LIB32=YES WITHOUT_MODULES=YES WITHOUT_NLS=YES WITH_BSD_GREP=YES WITH_PROFILE=YES WITH_PKGNG=yes PRINTERDEVICE=ps # # Crap for ports. # DISABLE_MAKE_JOBS=YES WITH_GHOSTSCRIPT_VER=8 # # added by use.perl 2013-02-19 12:45:06 PERL_VERSION=5.12.4 This is most likely due to a incompatibility between bsd grep and gnu grep. Try to switch to gnu grep, and the problem will most likely go away. Yes, this is definitely due to a BSD grep bug. The depcomp tests create a file sub/conftest.Po, containing: sub/conftest.o: sub/conftest.c sub/conftst1.h sub/conftst2.h \ sub/conftst3.h sub/conftst4.h sub/conftst5.h sub/conftst6.h sub/conftst1.h: sub/conftst2.h: sub/conftst3.h: sub/conftst4.h: sub/conftst5.h: sub/conftst6.h: Then it runs grep sub/conftest.o sub/conftest.Po, which fails with BSD grep, and succeeds with GNU grep. BSD grep does something very strange here: $ echo 'foo.bar' | grep foo.bar foo.bar $ echo 'foo.barx' | grep foo.bar foo.barx $ echo 'sub/foo.bar' | grep sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 So why does it not match in the last case? GNU grep works: $ echo 'sub/foo.barx' | gnugrep sub/foo.bar sub/foo.barx After disabling WITH_BSD_GREP and rebuild of the system, it seems that the machines in question now build lang/gcc. signature.asc Description: This is a digitally signed message part
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
11.03.2013 18:57, O. Hartmann пишет: On Mon, 2013-03-11 at 17:29 +0100, Dimitry Andric wrote: On 2013-03-11 14:15, Niclas Zeising wrote: BSD grep does something very strange here: $ echo 'foo.bar' | grep foo.bar foo.bar $ echo 'foo.barx' | grep foo.bar foo.barx $ echo 'sub/foo.bar' | grep sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 So why does it not match in the last case? GNU grep works: $ echo 'sub/foo.barx' | gnugrep sub/foo.bar sub/foo.barx After disabling WITH_BSD_GREP and rebuild of the system, it seems that the machines in question now build lang/gcc. So how about resurrecting http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/167921 ? Looks like BSD_GREP still has some problems with slashes. http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2013-03-10-amd64/ has some good pointers on where to start. I'm not that familiar with C to dive in. -- Sphinx of black quartz, judge my vow. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
Dimitry Andric d...@freebsd.org writes: $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 $ echo 'sub/foo.barx' | env -i grep sub/foo.bar $ echo 'sub/foolbarx' | env -i grep sub/foo.bar $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar' sub/foo.barx $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar sub/foo.barx A buggy shortcut? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On 2013-03-11 20:00, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 $ echo 'sub/foo.barx' | env -i grep sub/foo.bar $ echo 'sub/foolbarx' | env -i grep sub/foo.bar $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar' sub/foo.barx $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar sub/foo.barx A buggy shortcut? No, after some digging in and debugging of the bsdgrep code, I found out it is a regression caused by r246917, which is a fix for bin/175213: [patch] bsdgrep(1) segfaults upon malicious input. If you revert it, bsdgrep starts working correctly again. I think it would be best to back out r246917 for now, until the regression can be fixed properly. Having bsdgrep crash is bad, but not returning any results while it should is even worse... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mon, Mar 11, 2013 at 10:05:47PM +0100, Dimitry Andric wrote: On 2013-03-11 20:00, Jan Beich wrote: Dimitry Andric d...@freebsd.org writes: $ echo 'sub/foo.barx' | grep sub/foo.bar $ echo $? 1 $ echo 'sub/foo.barx' | env -i grep sub/foo.bar $ echo 'sub/foolbarx' | env -i grep sub/foo.bar $ echo 'sub/foo.barx' | env -i grep 'sub/foo\.bar' sub/foo.barx $ echo 'sub/foo.barx' | env -i grep -o sub/foo.bar sub/foo.bar $ echo 'sub/foo.barx' | env -i grep --color=no sub/foo.bar sub/foo.barx A buggy shortcut? No, after some digging in and debugging of the bsdgrep code, I found out it is a regression caused by r246917, which is a fix for bin/175213: [patch] bsdgrep(1) segfaults upon malicious input. If you revert it, bsdgrep starts working correctly again. First, I can report that bootstrapping gcc-4.8.0 works if I use gnugrep instead of bsdgrep. The above explains why I had previously seen the failure as I was using an older bsdgrep. Second, an apology is owed to the clang gang as I attributed the problem to clang as it showed up on my system after converted everything over to clang. I think it would be best to back out r246917 for now, until the regression can be fixed properly. Having bsdgrep crash is bad, but not returning any results while it should is even worse... I tend to agree with your assessment that r246817 should be reverted, because I hit this issue in configure scripts and there is a large amount of software that uses autotool for configuration. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build either lang/gcc or lang/gcc46 with the very same error shown below. The box is compiled with CLANG (buildworld/kernel). It doesn't matter whether I compile those ports with cc (which referes to CLANG 3.2) or USE_GCC=any, which should use the legacy compiler gcc or the installed lang/gcc (which seems to be outdated). Any attempt ends up with the very same error as shown below. This problem is sticky for a while now and I do not know what to do. I don't dare to delete the package in case the problem is then still present and I couldn't build the port again (I have to many scientific packages which do not compile properly with CLANG). Does anyone has an idea? Can I rescue the old installed lang/gcc as a package somehow to attempt a reinstallation in case deletion and recompiling the port will fail? Regards, Oliver [...] cc -O2 -pipe -O3 -march=native -I/usr/local/include -fno-strict-aliasing -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a echo timestamp full-stamp srcdir=../.././../gcc-4.6.3/fixincludes /bin/sh ../.././../gcc-4.6.3/fixincludes/mkfixinc.sh x86_64-portbld-freebsd10.0 sed -e 's/@gcc_version@/4.6.3/' mkheaders.almost mkheadersT mv -f mkheadersT mkheaders gmake[3]: Leaving directory `/usr/ports/lang/gcc/work/build/build-x86_64-portbld-freebsd10.0/fixincludes' Configuring stage 1 in ./libcpp configure: creating cache ./config.cache checking build system type... x86_64-portbld-freebsd10.0 checking host system type... x86_64-portbld-freebsd10.0 checking target system type... x86_64-portbld-freebsd10.0 checking whether gmake sets $(MAKE)... yes checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for x86_64-portbld-freebsd10.0-gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking for x86_64-portbld-freebsd10.0-ranlib... /usr/local/bin/ranlib checking how to run the C preprocessor... cpp checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for aclocal... aclocal checking for autoconf... autoconf checking for autoheader... autoheader checking whether cc supports -W... yes checking whether cc supports -Wall... yes checking whether cc supports -Wwrite-strings... yes checking whether cc supports -Wmissing-format-attribute... yes checking whether cc supports -Wstrict-prototypes... yes checking whether cc supports -Wmissing-prototypes... yes checking whether cc supports -Wold-style-definition... yes checking whether cc supports -Wc++-compat... yes checking whether cc supports -pedantic -Wno-long-long... yes checking dependency style of cc... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage1-libcpp] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Stop in /usr/ports/lang/gcc. === make failed for lang/gcc === Aborting update ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Mar 9, 2013, at 16:36 , Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build either lang/gcc or lang/gcc46 with the very same error shown below. … checking whether cc supports -pedantic -Wno-long-long... yes checking dependency style of cc... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage1-libcpp] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 What is the actual error in the resulting config.log file? Unfortunately autoconf error message are virtually information-free… My first guess would be that you have non-default CFLAGS in your build environment, which confuse gcc's build stages. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
Am 03/09/13 17:02, schrieb Dimitry Andric: On Mar 9, 2013, at 16:36 , Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build either lang/gcc or lang/gcc46 with the very same error shown below. … checking whether cc supports -pedantic -Wno-long-long... yes checking dependency style of cc... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage1-libcpp] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 What is the actual error in the resulting config.log file? Unfortunately autoconf error message are virtually information-free… My first guess would be that you have non-default CFLAGS in your build environment, which confuse gcc's build stages. Hello. CFLAGS settings are either root@thor:/usr/ports/lang/gcc # make -VCFLAGS -O2 -pipe -march=native -I/usr/local/include -fno-strict-aliasing or root@thor:/usr/ports/lang/gcc # make -VCFLAGS -O2 -pipe -O3 -march=native -I/usr/local/include -fno-strict-aliasing There are several config.log files: ./work/build/config.log ./work/build/lto-plugin/config.log ./work/build/gcc/config.log ./work/build/intl/config.log ./work/build/libcpp/config.log ./work/build/build-x86_64-portbld-freebsd10.0/libiberty/config.log ./work/build/build-x86_64-portbld-freebsd10.0/fixincludes/config.log ./work/build/libiberty/config.log Most recent touched is ./work/build/libcpp/config.log and since libcpp occurs in the error, it is the requested log file. I can not see anything useful in that file - I'm sorry :-( It is attached to this post. If you need further material, feel free to ask. By the way, I copied my /etc/make.conf and /etc/src.conf to another CURRENT machine which has the very same revision status (as well as the /usr/src AND /usr/ports, both boxes are up to date even with portmaster run this morning). I do not see the problem on this other machine. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: lang/gcc fails to build on CURRENT with error: configure: error: no usable dependency style found
On Sat, Mar 09, 2013 at 05:02:56PM +0100, Dimitry Andric wrote: On Mar 9, 2013, at 16:36 , Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I have one specific FreeBSD 10.0-CURRENT box (FreeBSD 10.0-CURRENT #0 r248061: Fri Mar 8 19:44:30 CET 2013 amd64) which rejects to build either lang/gcc or lang/gcc46 with the very same error shown below. ? checking whether cc supports -pedantic -Wno-long-long... yes checking dependency style of cc... none configure: error: no usable dependency style found gmake[2]: *** [configure-stage1-libcpp] Error 1 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 What is the actual error in the resulting config.log file? Unfortunately autoconf error message are virtually information-free? If you have a clang built FreeBSD-current, then it is no longer possible to *bootstrap* gcc-4.6.x, gcc-4.7.x, nor the upcoming gcc-4.8.0. AFAICT, the problem is related to /usr/bin/cpp. I haven't tried earlier versions of gcc. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
