-current build failure in compiler_rt/dist/lib/msan/msan_interceptors.cc
Hi!
Yesterday evening's current with:
build.sh -j 32 -x -V MKDEBUG=yes -V MKDEBUGLIB=yes -V MKLLVM=yes -T
/usr/obj/tools.gcc -m amd64 -O /usr/obj/src.amd64 -D
/usr/obj/amd64.gcc.20191022 -R /usr/obj/amd64.gcc.20191022.release distribution
gives me:
--- msan_interceptors.o ---
In file included from
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:18:
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
error: 'void __interceptor___libc_thr_keycreate(void*, void (*)(void*))'
alias between functions of incompatible types 'void(void*, void (*)(void*))'
and 'int(__sanitizer::__sanitizer_pthread_key_t*, void (*)(void*))' {aka 'int
(unsigned int*, void (*)(void*))'} [-Werror=attribute-alias]
# define WRAP(x) __interceptor_ ## x
^~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
note: in expansion of macro 'WRAP'
ret_type WRAP(func)(__VA_ARGS__)
^~~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1060:1:
note: in expansion of macro 'INTERCEPTOR'
INTERCEPTOR(void, __libc_thr_keycreate, void *m, void (*dtor)(void *value)) \
^~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:140:18:
note: aliased declaration here
# define WRAP(x) __interceptor_ ## x
^~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/interception/interception.h:227:12:
note: in expansion of macro 'WRAP'
ret_type WRAP(func)(__VA_ARGS__)
^~~~
/usr/src/sys/external/bsd/compiler_rt/dist/lib/msan/msan_interceptors.cc:1049:1:
note: in expansion of macro 'INTERCEPTOR'
INTERCEPTOR(int, pthread_key_create, __sanitizer_pthread_key_t *key,
^~~
Thomas
daily CVS update output
Updating src tree: P src/distrib/sets/lists/xcomp/mi U src/distrib/sets/lists/xetc/md.x68k P src/distrib/sets/lists/xetc/mi P src/share/mk/bsd.own.mk P src/sys/arch/arm/dts/socfpga_cyclone5_de0_nano_soc.dts P src/sys/arch/arm/imx/fdt/imx6_platform.c P src/sys/dev/ic/ssdfb.c P src/sys/dev/ic/ssdfbvar.h P src/sys/dev/ic/wdc.c P src/sys/dev/usb/uvideo.c P src/sys/external/bsd/drm/dist/shared-core/r128_drv.h Updating xsrc tree: P xsrc/external/mit/xedit/dist/lisp/pathname.c Killing core files: Updating release-7 src tree (netbsd-7): Updating release-7 xsrc tree (netbsd-7): Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.2 P external/bsd/pkg_install/dist/add/perform.c P external/bsd/pkg_install/dist/add/pkg_add.1 P external/bsd/pkg_install/dist/admin/audit.c P external/bsd/pkg_install/dist/admin/main.c P external/bsd/pkg_install/dist/admin/pkg_admin.1 P external/bsd/pkg_install/dist/create/util.c P external/bsd/pkg_install/dist/delete/pkg_delete.c P external/bsd/pkg_install/dist/info/main.c P external/bsd/pkg_install/dist/lib/lib.h P external/bsd/pkg_install/dist/lib/license.c P external/bsd/pkg_install/dist/lib/parse-config.c P external/bsd/pkg_install/dist/lib/pkcs7.c P external/bsd/pkg_install/dist/lib/pkg_io.c P external/bsd/pkg_install/dist/lib/version.h P external/bsd/pkg_install/dist/lib/vulnerabilities-file.c P sys/fs/ntfs/ntfs_subr.c P sys/fs/ntfs/ntfs_vfsops.c Updating release-8 xsrc tree (netbsd-8): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41822399 Oct 23 03:11 ls-lRA.gz
Converting termcap entries to terminfo entries
hello. I'm in the process of building NetBSD-9.0 systems in an effort to consider upgrading from my fleet of NetBSD-5.2 systems to NetBSD-9. As a long time window(1) user, I have a termcap entry for the window terminal type that I use on systems that I ssh into from window(1) panes. It is my practice to put a termcap and a terminfo database in my home directory on such systems, so that regardless of whether a program at the far end wants termcap or terminfo, it will be able to draw on the screen in full screen mode. what I need is a way of converting the termcap entries I have into a terminfo source file that tic(1) can compile into a .cdb file which can be used on NetBSD-9 systems. I have an older version of captoinfo(1) from the ncurses pkg, but it produces binary terminfo output unsuitable for the tic(1) program. I'm fuly aware that window(1) has been deprecated in favor of tmux(1), but I haven't climbed the learning curve of tmux(1) yet and I'm not sure it does everything I get from the window(1) program. So, can someone tell me what program I should use to convert termcap files into terminfo source files suitable for the new terminfo libraries in NetBSD-8 and 9? -thanks -brian
heads-up: planned changes in nvmm
[I am not subscribed to this list, so if you want to answer, make sure to CC me.] I will soon commit a set of changes in NVMM, which will require a full rebuild and reinstallation of: the kernel NVMM driver, the libnvmm API, the libnvmm ATF tests, and the qemu-nvmm package if you're using it. You can cherry-pick each change, but it will be easier to just do a full distribution rebuild and reinstall. Overall it is no different than what I've been doing over the last six months. This time, however, the changes will also be pulled up to 9beta afterwards. I will push my changes in -current and update the qemu-nvmm package in several rounds probably over several days, and then will pull up to 9beta. In the meantime, do not upgrade your qemu-nvmm package if you're on 9beta.
Re: Tar extract behaviour changed
On Tue, Oct 22, 2019 at 08:00:35PM +0200, Christian Groessler wrote: > "tar" had an option to delete files which it is about to extract before > extraction. Wouldn't this solve the "symlink" issue at hand? What am I > missing? See the SECURITY section in the man page. Both -U and -P are ways to dealing with this, but with different end result. Joerg
Re: Tar extract behaviour changed
On 2019-10-22 17:43, Robert Elz wrote: Date:Tue, 22 Oct 2019 14:33:27 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Well, one of the use cases is when we don't have enough disk space in the | same partition, so that will not work out. No, I meant symlinks in the archive, not pre-existing ones. While I suppose there are uses for archives containing symlinks aimed all over the place, I'd tend to assume they're only for locally created archives (and so could be extracted with an option to allow them) - archives from elsewhere cannot expect to know where other (non-archive) files are to be located on every system that might extract the archive, so symlinks in the archive that don't (at least potentially) refer to other files in the archive are not usually going to be of any use. So the test would be, before creating a symlink from the archive, whether the target starts with / or enough ../ sequences to escape the root of the extraction (or any /../ sequence inside the symlink - that should never be needed) if any of those is found, and not exprssly permitted then the symlmk should not be extracted. Of course, anything named explicitly on the command line is also OK, If I do tar xf archive /etc/passwd that should do exactly what I told it to do, as should tar xf archive some/symlink(whatever the target is) (and the equiv for the pax & cpio interfaces, but perhaps not when reading the list of files from stdin, haven't really considered that case). Sorry for appearing dense, I briefly followed this thread. "tar" had an option to delete files which it is about to extract before extraction. Wouldn't this solve the "symlink" issue at hand? What am I missing? regards, chris
Re: Failure to build current tools amd64
Hi! Update: it was an update build that did not work. Retrying without -u and waiting for some time... succeeded. I hate that :) Riccardo Riccardo Mottola wrote: Hi all! I did update CVS yesterday and started a nice build from tools, but it fails with: (upgrade unprivileged build) ./build.sh -U -u tools [...] c++ -fno-PIE -c -DIN_GCC_FRONTEND -O -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/c -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../include -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libcpp/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libbacktrace -DNETBSD_TOOLS -DTARGET_SYSTEM_ROOT=0 -DTARGET_SYSTEM_ROOT_RELOCATABLE -o c/c-parser.o -MT c/c-parser.o -MMD -MP -MF c/.deps/c-parser.TPo /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/c/c-parser.c nbgmake[1]: *** No rule to make target `/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/c/c-array-notation.c', needed by `c/c-array-notation.o'. Stop. nbgmake[1]: Leaving directory `/usr/obj/tools/gcc/build/gcc' nbgmake: *** [all-gcc] Error 2 *** Failed target: .build_done *** Failed command: (cd build && /usr/bin/env -i gcc_cv_libc_provides_ssp=yes gcc_cv_as_sparc_gotdata_op=no AR=ar AWK=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbawk CC=cc CFLAGS=-O CONFIG_SHELL=/bin/sh CPPFLAGS= CXX=c++ CXXFLAGS=-O INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r LDFLAGS= LEX=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nblex FLEX=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nblex M4=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbm4 MAKE=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbgmake PATH="/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin:$PATH" RANLIB=ranlib YACC=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbyacc MACHINE= MAKEINFO=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbmakeinfo LIBGCC= LIBGCC1= LIBGCC1_TEST= LIBGCC2= INSTALL_LIBGCC= EXTRA_PARTS= CPPFLAGS=-DNETBSD_TOOLS\ -DTARGET_SYSTEM_ROOT=0\ \ -DTARGET_SYSTEM_ROOT_RELOCATABLE AR=ar RANLIB=ranlib BISON=true DESTDIR= INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r /usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbgmake -e MACHINE= MAKEINFO=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbmakeinfo LIBGCC= LIBGCC1= LIBGCC1_TEST= LIBGCC2= INSTALL_LIBGCC= EXTRA_PARTS= CPPFLAGS=-DNETBSD_TOOLS\ -DTARGET_SYSTEM_ROOT=0\ \ -DTARGET_SYSTEM_ROOT_RELOCATABLE AR=ar RANLIB=ranlib BISON=true DESTDIR= INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r all-gcc) *** Error code 2 did I have just a back CVS checkout .
undefined reference in system library on netbsd-9/sparc
Building "sysutils/apcupsd" on NetBSD/sparc-9.0_BETA fails linking with: [...] LDsrc/apcupsd ld: /usr/lib/libsupc++.a(eh_throw.o):(.text+0x78): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' I have an old binary package from the last time I built apcupsd on sparc. It reports OS_VERSION of 8.99.26. So whatever the gcc/g++ version and libraries in use at that time, it worked fine. Clues? -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: Tar extract behaviour changed
Date:Tue, 22 Oct 2019 14:33:27 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Well, one of the use cases is when we don't have enough disk space in the | same partition, so that will not work out. No, I meant symlinks in the archive, not pre-existing ones. While I suppose there are uses for archives containing symlinks aimed all over the place, I'd tend to assume they're only for locally created archives (and so could be extracted with an option to allow them) - archives from elsewhere cannot expect to know where other (non-archive) files are to be located on every system that might extract the archive, so symlinks in the archive that don't (at least potentially) refer to other files in the archive are not usually going to be of any use. So the test would be, before creating a symlink from the archive, whether the target starts with / or enough ../ sequences to escape the root of the extraction (or any /../ sequence inside the symlink - that should never be needed) if any of those is found, and not exprssly permitted then the symlmk should not be extracted. Of course, anything named explicitly on the command line is also OK, If I do tar xf archive /etc/passwd that should do exactly what I told it to do, as should tar xf archive some/symlink(whatever the target is) (and the equiv for the pax & cpio interfaces, but perhaps not when reading the list of files from stdin, haven't really considered that case). kre
Re: Tar extract behaviour changed
In article <19306.1571753...@jinx.noi.kre.to>, Robert Elz wrote: >Date:Tue, 22 Oct 2019 14:27:39 +0200 >From:Joerg Sonnenberger >Message-ID: <20191022122739.ga86...@bec.de> > > | Extraction of entries in streamable formats happens in isolation. The > | archiver has no knowledge about pre-existing symlinks or whether the > | archive itself just created the symlink. > >It should be able to deduce something from the ctime of the symlink >if it wanted - if that predates the start of the extraction, then the >symlink was there in advance, if after, then (most probably) the archive >contained the symlink. That's a good idea :-) >chris...@astron.com said: > | because then we would have to normalize and check all symlinks in the > | archive (and do what? allow only the symlink pointing to an empty directory > | case? > >only allow symlinks pointing inside the tree being extracted most likely. Well, one of the use cases is when we don't have enough disk space in the same partition, so that will not work out. >But in both cases, when the archive is untrusted, avoiding all of this >is best, when it is trusted (particularly when the user created it themselves) >things ought to be more flexible. Right. christos
Re: Tar extract behaviour changed
On Tue, Oct 22, 2019 at 07:26:05AM +0200, Martin Husemann wrote: > On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote: > > Date:Mon, 21 Oct 2019 21:20:25 +0200 > > From:Joerg Sonnenberger > > Message-ID: <20191021192025.ga33...@bec.de> > > > > | That said, I don't really see a point in > > | allowing one form of arbitrary file replacement and not another. > > > > If we're thinking of it purely as protection against potentially > > malicious archives obtained from some random internet site, then > > nor do I > > I am not sure. Clearly / and .. are protecting against malicious archives. > But in my view a directory entry in the (potential malicious) archive > overwriting an existing symlink is something where the explicit wish of the > user running the extraction is not honored. Extraction of entries in streamable formats happens in isolation. The archiver has no knowledge about pre-existing symlinks or whether the archive itself just created the symlink. Joerg
Re: Tar extract behaviour changed
In article <20191022052605.ga...@mail.duskware.de>,
Martin Husemann wrote:
>On Tue, Oct 22, 2019 at 06:37:44AM +0700, Robert Elz wrote:
>> Date:Mon, 21 Oct 2019 21:20:25 +0200
>> From:Joerg Sonnenberger
>> Message-ID: <20191021192025.ga33...@bec.de>
>>
>> | That said, I don't really see a point in
>> | allowing one form of arbitrary file replacement and not another.
>>
>> If we're thinking of it purely as protection against potentially
>> malicious archives obtained from some random internet site, then
>> nor do I
>
>I am not sure. Clearly / and .. are protecting against malicious archives.
>But in my view a directory entry in the (potential malicious) archive
>overwriting an existing symlink is something where the explicit wish of the
>user running the extraction is not honored.
>
>The attack vector here would be someone modifying my file system
>placing malicious symlinks somewhere and later me running the
>extraction of the archive - which is very different from not trusting
>the archive in the first place.
>
Actually a malicious archive can first create the malicious symlink that
points outside the intended extraction tree and then overwrite the
destination. It is much harder to protect against, because then we would
have to normalize and check all symlinks in the archive (and do what?
allow only the symlink pointing to an empty directory case? -- the whole
thing sounds too complicated)
>The other open question is: given that we only have -P, we need to either:
>
> - make sysinst list all directories in the archive and check them for
> existing symlinks, then ask the user wether the existing symlink should
> be kept (and then add -P to the tar command line) or
> - simply use -P always on set extractions (where we already know that no
> .. or / should exist and we kind of trust the archives anyway)
>
>The current state silently breaks existing valid setups ("valid" of course
>in my view, as I personally ran into one that I created myself).
It is simple enough to add extra flags, but as joerg@ implied, it is more
security theater. It does protect against accidents though (tars created
with / files by).
christos
Re: -current panics on boot in atabus_alloc_drives()
Thanks, looks like some drivers probe channels without holding the channel lock. Should be easy to fix. christos > On Oct 22, 2019, at 3:56 AM, Andreas Gustafsson wrote: > > Christos, > > Both i386 and amd64 are failing to install on the testbed due to the > install kernel panicing on boot. The amd64 console log contains a > backtrace: > > [ 1.0264751] panic: lock error: Mutex: mutex_vector_exit,742: exiting > unheld spin mutex: lock 0xc83161f0 cpu 0 lwp 0xc217e7c90540 > [ 1.0264751] cpu0: Begin traceback... > [ 1.2751115] vpanic() at netbsd:vpanic+0x160 > [ 1.2751115] snprintf() at netbsd:snprintf > [ 1.3032327] lockdebug_abort() at netbsd:lockdebug_abort+0xee > [ 1.3032327] mutex_vector_exit() at netbsd:mutex_vector_exit+0xbd > [ 1.3032327] atabus_alloc_drives() at netbsd:atabus_alloc_drives+0x61 > [ 1.3231953] wdc_drvprobe() at netbsd:wdc_drvprobe+0x40 > [ 1.3432056] atabusconfig() at netbsd:atabusconfig+0x65 > [ 1.3432056] atabus_thread() at netbsd:atabus_thread+0x7e > [ 1.3432056] cpu0: End traceback... > > This is from: > > http://releng.netbsd.org/b5reports/amd64/2019/2019.10.21.19.00.11/install.log > > On i386, the only kernel commits between the last sucesss and the failure > were: > > 2019.10.21.18.37.47 christos src/sys/dev/ata/ata.c 1.152 > 2019.10.21.18.58.57 christos src/sys/dev/ata/ata.c 1.153 > 2019.10.21.19.00.11 christos src/sys/dev/pci/satalink.c 1.57 > > -- > Andreas Gustafsson, g...@gson.org
-current panics on boot in atabus_alloc_drives()
Christos, Both i386 and amd64 are failing to install on the testbed due to the install kernel panicing on boot. The amd64 console log contains a backtrace: [ 1.0264751] panic: lock error: Mutex: mutex_vector_exit,742: exiting unheld spin mutex: lock 0xc83161f0 cpu 0 lwp 0xc217e7c90540 [ 1.0264751] cpu0: Begin traceback... [ 1.2751115] vpanic() at netbsd:vpanic+0x160 [ 1.2751115] snprintf() at netbsd:snprintf [ 1.3032327] lockdebug_abort() at netbsd:lockdebug_abort+0xee [ 1.3032327] mutex_vector_exit() at netbsd:mutex_vector_exit+0xbd [ 1.3032327] atabus_alloc_drives() at netbsd:atabus_alloc_drives+0x61 [ 1.3231953] wdc_drvprobe() at netbsd:wdc_drvprobe+0x40 [ 1.3432056] atabusconfig() at netbsd:atabusconfig+0x65 [ 1.3432056] atabus_thread() at netbsd:atabus_thread+0x7e [ 1.3432056] cpu0: End traceback... This is from: http://releng.netbsd.org/b5reports/amd64/2019/2019.10.21.19.00.11/install.log On i386, the only kernel commits between the last sucesss and the failure were: 2019.10.21.18.37.47 christos src/sys/dev/ata/ata.c 1.152 2019.10.21.18.58.57 christos src/sys/dev/ata/ata.c 1.153 2019.10.21.19.00.11 christos src/sys/dev/pci/satalink.c 1.57 -- Andreas Gustafsson, g...@gson.org
Re: Tar extract behaviour changed
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
> On 22. Oct 2019, at 07:26, Martin Husemann wrote:
>
> The current state silently breaks existing valid setups ("valid" of course
> in my view, as I personally ran into one that I created myself).
It breaks chrooted services, I got non-working "unbound" and "nsd".
Suppose this will hurt a bunch of installations when they
go from -8 to -9.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
signature.asc
Description: Message signed with OpenPGP
Failure to build current tools amd64
Hi all! I did update CVS yesterday and started a nice build from tools, but it fails with: (upgrade unprivileged build) ./build.sh -U -u tools [...] c++ -fno-PIE -c -DIN_GCC_FRONTEND -O -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Ic -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/c -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../include -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libcpp/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/include -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libdecnumber/dpd -I../libdecnumber -I/usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/../libbacktrace -DNETBSD_TOOLS -DTARGET_SYSTEM_ROOT=0 -DTARGET_SYSTEM_ROOT_RELOCATABLE -o c/c-parser.o -MT c/c-parser.o -MMD -MP -MF c/.deps/c-parser.TPo /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/gcc/c/c-parser.c nbgmake[1]: *** No rule to make target `/usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/c/c-array-notation.c', needed by `c/c-array-notation.o'. Stop. nbgmake[1]: Leaving directory `/usr/obj/tools/gcc/build/gcc' nbgmake: *** [all-gcc] Error 2 *** Failed target: .build_done *** Failed command: (cd build && /usr/bin/env -i gcc_cv_libc_provides_ssp=yes gcc_cv_as_sparc_gotdata_op=no AR=ar AWK=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbawk CC=cc CFLAGS=-O CONFIG_SHELL=/bin/sh CPPFLAGS= CXX=c++ CXXFLAGS=-O INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r LDFLAGS= LEX=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nblex FLEX=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nblex M4=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbm4 MAKE=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbgmake PATH="/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin:$PATH" RANLIB=ranlib YACC=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbyacc MACHINE= MAKEINFO=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbmakeinfo LIBGCC= LIBGCC1= LIBGCC1_TEST= LIBGCC2= INSTALL_LIBGCC= EXTRA_PARTS= CPPFLAGS=-DNETBSD_TOOLS\ -DTARGET_SYSTEM_ROOT=0\ \ -DTARGET_SYSTEM_ROOT_RELOCATABLE AR=ar RANLIB=ranlib BISON=true DESTDIR= INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r /usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbgmake -e MACHINE= MAKEINFO=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/nbmakeinfo LIBGCC= LIBGCC1= LIBGCC1_TEST= LIBGCC2= INSTALL_LIBGCC= EXTRA_PARTS= CPPFLAGS=-DNETBSD_TOOLS\ -DTARGET_SYSTEM_ROOT=0\ \ -DTARGET_SYSTEM_ROOT_RELOCATABLE AR=ar RANLIB=ranlib BISON=true DESTDIR= INSTALL=/usr/src/obj/tooldir.NetBSD-9.99.11-amd64/bin/x86_64--netbsd-install\ -c\ -p\ -r all-gcc) *** Error code 2 did I have just a back CVS checkout .
