Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 01:28:53PM -0500, Greg Troxel wrote: > This appears to be a broken tar issue surounding hardlinks and Christos > has backed it out. So perhaps update and rebuild and try again. Yes - the reason pax worked is that it didn't use libarchive. On a "broken" box: # ldd /bin/pax /bin/pax: -lutil.7 => /lib/libutil.so.7 -lc.12 => /lib/libc.so.12 # ldd /bin/tar /bin/tar: -larchive.4 => /usr/lib/libarchive.so.4 -lbz2.1 => /usr/lib/libbz2.so.1 -lc.12 => /lib/libc.so.12 -lcrypto.14 => /lib/libcrypto.so.14 -lcrypt.1 => /lib/libcrypt.so.1 -lexpat.2 => /usr/lib/libexpat.so.2 -llzma.2 => /lib/liblzma.so.2 -lpthread.1 => /lib/libpthread.so.1 -lz.1 => /lib/libz.so.1 Cheers, Patrick
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 18:28, Greg Troxel wrote: > > This appears to be a broken tar issue surounding hardlinks and Christos > has backed it out. So perhaps update and rebuild and try again. I vaguely remember similar discussion sometimes ago. > > I can see why you refer to 9.33.37 as a version of NetBSD, but really it > is not a name for a specific version. That last number is increased > when there is an internal ABI change, but many other things happen > within the operating system that do not change that version number. So > it is probably best to give the time at which you updated. I understand; that bsd-own.mk change has happened in the interval between my last 9.99.36 and first 9.99.37 build; it is not related to the reason the bump to .37 was done . > > > Thanks, Chavdar --
Re: net/net-snmp build failure on 9.99.37
This appears to be a broken tar issue surounding hardlinks and Christos has backed it out. So perhaps update and rebuild and try again. I can see why you refer to 9.33.37 as a version of NetBSD, but really it is not a name for a specific version. That last number is increased when there is an internal ABI change, but many other things happen within the operating system that do not change that version number. So it is probably best to give the time at which you updated.
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > > To complete the analysis, I tried to upgrade a 9.99.36 system to > > 9.99.37 by booting off the ISO file I previously used for the clean > > installation described above. > > > > It failed in a similar was as with sysupgrade : > > > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > > 91 > > (the clean installation returns 0). > > > > It gets less clear after this... But at the moment I can't see how to > > upgrade to 9.99.37. > > I just hit the same thing without using sysupgrade. > > Essentially tar built in I'm not sure which window can't unpack symlinks. > > On a couple of days old -current/amd64 > > grab base.tar.xz > tar -tzvf base.tar.xz | grep rebootsee that it's a symlink > tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero > length file > cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine Prior to 9.99.37 we have: $ ls -li /bin/tar /bin/pax /bin/cpio 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/cpio 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/pax 13081639 -r-xr-xr-x 3 root wheel 166288 Jan 12 17:00 /bin/tar Hardlinks; in 9.99.37 we have: ~ ls -li /bin/tar /bin/cpio /bin/pax 181767 -r-xr-xr-x 1 root wheel 50288 Jan 14 03:10 /bin/cpio 181784 -r-xr-xr-x 1 root wheel 166288 Jan 14 03:57 /bin/pax 181796 -r-xr-xr-x 1 root wheel 82352 Jan 14 03:10 /bin/tar different files, but pax is the same as on 9.99.36, at least sizewise. So the easiest way to sort oneself out of this is to hard-link /bin/pax to the others and carry on the update. > > Oddly - now repeat the tar, and also find that it is fine. > > So the work around seems to be "use pax". The surpise is that then tar is > fixed. > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 15:43, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > > To complete the analysis, I tried to upgrade a 9.99.36 system to > > 9.99.37 by booting off the ISO file I previously used for the clean > > installation described above. > > > > It failed in a similar was as with sysupgrade : > > > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > > 91 > > (the clean installation returns 0). > > > > It gets less clear after this... But at the moment I can't see how to > > upgrade to 9.99.37. > > I just hit the same thing without using sysupgrade. > > Essentially tar built in I'm not sure which window can't unpack symlinks. > > On a couple of days old -current/amd64 > > grab base.tar.xz > tar -tzvf base.tar.xz | grep rebootsee that it's a symlink > tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero > length file > cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine > > Oddly - now repeat the tar, and also find that it is fine. > > So the work around seems to be "use pax". The surpise is that then tar is > fixed. And I find the following: (on the system with many - 92 - zero length files in *bin directories): nbuild# ls -l bin/test -r-xr-xr-x 1 root wheel 0 Jan 14 03:57 bin/test test is zero length nbuild# /bin/tar xopf ../base.tar.xz ./bin extracting the whole ./bin over *existing* directory nbuild# ls -l bin/test -r-xr-xr-x 1 root wheel 0 Jan 14 03:57 bin/test # test is still zero length nbuild# mv bin bin.old # hiding the whole bin directory nbuild# /bin/tar xopf ../base.tar.xz ./bin ksh: /bin/tar: not found # me stpid nbuild# /bin.old/tar xopf ../base.tar.xz ./bin # extracting in a fresh place nbuild# ls -l bin/test -r-xr-xr-x 2 root wheel 18808 Jan 14 03:57 bin/test# now test is ok. So there is apparently some bsdtar bug here, > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 03:20:46PM +, Chavdar Ivanov wrote: > To complete the analysis, I tried to upgrade a 9.99.36 system to > 9.99.37 by booting off the ISO file I previously used for the clean > installation described above. > > It failed in a similar was as with sysupgrade : > > ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l > 91 > (the clean installation returns 0). > > It gets less clear after this... But at the moment I can't see how to > upgrade to 9.99.37. I just hit the same thing without using sysupgrade. Essentially tar built in I'm not sure which window can't unpack symlinks. On a couple of days old -current/amd64 grab base.tar.xz tar -tzvf base.tar.xz | grep rebootsee that it's a symlink tar -xzpvf base.tar.xz -C /see that /sbin/reboot is a zero length file cd / && pax -r -v -z -pe -f base.tar.xzsee that /sbin/reboot is fine Oddly - now repeat the tar, and also find that it is fine. So the work around seems to be "use pax". The surpise is that then tar is fixed. Cheers, Patrick
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 14:20, Chavdar Ivanov wrote:
>
> On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
> >
> > On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > > Clean installation from the same ISO file is fine, so it probably was
> > > sysupgrade failure induced by the different tar.
> >
> > You did quite some detective work! (Yes, I don't use sysupgrade...)
>
> It's one of the things you get accustomed to, I have been using it for
> ages without many problems; occasionally they do occur, e.g. in
> September some bump in the shared libraries stopped the final
> etcupdate stages from completing properly; in that case it was enough
> to repeat the process and all was well. In this case I probably will
> update manually.
>
> BTW in case anybody is interested, I tried the abovementioned ISO -
> 9.99.37 - to install as a guest under XCP-NG, which one should have
> been aware by this time is the fully functional free version of what
> used to be XenServer. Using UEFI mode I was even able to get X running
> with the modesetting driver (obviously the DRI{2} bits do not load).
> The only problem so far is with the mouse; the cursor somehow only
> goes along the edges of the screen in a rather unpredictable manner -
> both on the Xorchestra console and the Xcp-ng center.
To complete the analysis, I tried to upgrade a 9.99.36 system to
9.99.37 by booting off the ISO file I previously used for the clean
installation described above.
It failed in a similar was as with sysupgrade :
ls -l /sbin /bin /usr/sbin /usr/bin | egrep 'wheel[ \t]*0' | wc -l
91
(the clean installation returns 0).
It gets less clear after this... But at the moment I can't see how to
upgrade to 9.99.37.
>
>
> >
> >
> > Cheers,
> >
> > Patrick
>
>
>
> --
>
--
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 13:41, Patrick Welche wrote:
>
> On Tue, Jan 14, 2020 at 01:28:15PM +, Chavdar Ivanov wrote:
> > Clean installation from the same ISO file is fine, so it probably was
> > sysupgrade failure induced by the different tar.
>
> You did quite some detective work! (Yes, I don't use sysupgrade...)
It's one of the things you get accustomed to, I have been using it for
ages without many problems; occasionally they do occur, e.g. in
September some bump in the shared libraries stopped the final
etcupdate stages from completing properly; in that case it was enough
to repeat the process and all was well. In this case I probably will
update manually.
BTW in case anybody is interested, I tried the abovementioned ISO -
9.99.37 - to install as a guest under XCP-NG, which one should have
been aware by this time is the fully functional free version of what
used to be XenServer. Using UEFI mode I was even able to get X running
with the modesetting driver (obviously the DRI{2} bits do not load).
The only problem so far is with the mouse; the cursor somehow only
goes along the edges of the screen in a rather unpredictable manner -
both on the Xorchestra console and the Xcp-ng center.
>
>
> Cheers,
>
> Patrick
--
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:45, Chavdar Ivanov wrote: > > I was able to downgrade to 9.99.36 using sysupgrade after linking > /usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and > /bin/cpio were also of length 0 on my 9.99.37... > > Unintended consequences. > > On Tue, 14 Jan 2020 at 12:40, Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > > > > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > > > lines... > > > > > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > > > $ ls -l `which gcc` > > > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > > > $ gcc --version > > > gcc (nb1 20190930) 8.3.0 Clean installation from the same ISO file is fine, so it probably was sysupgrade failure induced by the different tar. > > > > I suspect it is the switch to bsdtar - bsd.own.mk change - combined > > with the fact that we both used sysutils/sysupgrade to get to 9.00.37. > > > > cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk > >] 12:30 PM > > Index: bsd.own.mk > > === > > RCS file: /cvsroot/src/share/mk/bsd.own.mk,v > > retrieving revision 1.1169 > > retrieving revision 1.1170 > > diff -u -r1.1169 -r1.1170 > > --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 > > +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 > > @@ -1,4 +1,4 @@ > > -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ > > +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ > > > > # This needs to be before bsd.init.mk > > .if defined(BSD_MK_COMPAT_FILE) > > @@ -1082,6 +1082,7 @@ > > _MKVARS.yes= \ > > MKATF \ > > MKBINUTILS \ > > + MKBSDTAR \ > > MKCOMPLEX MKCVS MKCXX \ > > MKDOC MKDTC \ > > MKDYNAMICROOT \ > > @@ -1205,7 +1206,6 @@ > > MKARGON2 \ > > MKARZERO \ > > MKBSDGREP \ > > - MKBSDTAR \ > > MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ > > MKDEBUG MKDEBUGLIB MKDTRACE \ > > MKEXTSRC \ > > > > (moves MKBSDTAR from those predefined as NO to YES). > > > > > ... > > > > > > > > > Cheers, > > > > > > Patrick > > > > > > > > -- > > > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
I was able to downgrade to 9.99.36 using sysupgrade after linking /usr/bin/tar to /usr/pkg/bin/bsdtar, as /bin/tar /bin/pax and /bin/cpio were also of length 0 on my 9.99.37... Unintended consequences. On Tue, 14 Jan 2020 at 12:40, Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > > lines... > > > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > > $ ls -l `which gcc` > > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > > $ gcc --version > > gcc (nb1 20190930) 8.3.0 > > I suspect it is the switch to bsdtar - bsd.own.mk change - combined > with the fact that we both used sysutils/sysupgrade to get to 9.00.37. > > cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk >] 12:30 PM > Index: bsd.own.mk > === > RCS file: /cvsroot/src/share/mk/bsd.own.mk,v > retrieving revision 1.1169 > retrieving revision 1.1170 > diff -u -r1.1169 -r1.1170 > --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 > +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 > @@ -1,4 +1,4 @@ > -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ > +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ > > # This needs to be before bsd.init.mk > .if defined(BSD_MK_COMPAT_FILE) > @@ -1082,6 +1082,7 @@ > _MKVARS.yes= \ > MKATF \ > MKBINUTILS \ > + MKBSDTAR \ > MKCOMPLEX MKCVS MKCXX \ > MKDOC MKDTC \ > MKDYNAMICROOT \ > @@ -1205,7 +1206,6 @@ > MKARGON2 \ > MKARZERO \ > MKBSDGREP \ > - MKBSDTAR \ > MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ > MKDEBUG MKDEBUGLIB MKDTRACE \ > MKEXTSRC \ > > (moves MKBSDTAR from those predefined as NO to YES). > > > ... > > > > > > Cheers, > > > > Patrick > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:29, Patrick Welche wrote: > > On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > > lines... > > FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: > $ ls -l `which gcc` > -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc > $ gcc --version > gcc (nb1 20190930) 8.3.0 I suspect it is the switch to bsdtar - bsd.own.mk change - combined with the fact that we both used sysutils/sysupgrade to get to 9.00.37. cvs diff -u -r 1.1169 -r 1.1170 bsd.own.mk ] 12:30 PM Index: bsd.own.mk === RCS file: /cvsroot/src/share/mk/bsd.own.mk,v retrieving revision 1.1169 retrieving revision 1.1170 diff -u -r1.1169 -r1.1170 --- bsd.own.mk 14 Dec 2019 10:59:25 - 1.1169 +++ bsd.own.mk 12 Jan 2020 16:11:51 - 1.1170 @@ -1,4 +1,4 @@ -# $NetBSD: bsd.own.mk,v 1.1169 2019/12/14 10:59:25 mrg Exp $ +# $NetBSD: bsd.own.mk,v 1.1170 2020/01/12 16:11:51 christos Exp $ # This needs to be before bsd.init.mk .if defined(BSD_MK_COMPAT_FILE) @@ -1082,6 +1082,7 @@ _MKVARS.yes= \ MKATF \ MKBINUTILS \ + MKBSDTAR \ MKCOMPLEX MKCVS MKCXX \ MKDOC MKDTC \ MKDYNAMICROOT \ @@ -1205,7 +1206,6 @@ MKARGON2 \ MKARZERO \ MKBSDGREP \ - MKBSDTAR \ MKCATPAGES MKCOMPATTESTS MKCOMPATX11 MKCTF \ MKDEBUG MKDEBUGLIB MKDTRACE \ MKEXTSRC \ (moves MKBSDTAR from those predefined as NO to YES). > ... > > > Cheers, > > Patrick --
Re: net/net-snmp build failure on 9.99.37
On Tue, Jan 14, 2020 at 12:22:26PM +, Chavdar Ivanov wrote: > There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 > lines... FWIW, an update build.sh from yesterday, so 9.99.37/amd64, works for me: $ ls -l `which gcc` -r-xr-xr-x 2 root wheel 1045384 Jan 13 17:43 /usr/bin/gcc $ gcc --version gcc (nb1 20190930) 8.3.0 ... Cheers, Patrick
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:22, Rares Aioanei wrote: > > Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are > empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL". I do essentially the same, but with self-built versions. In my case /sbin/reboot appears OK, but /usr/bin/lex is also of length 0. I guess bad update moment. Back to downgrading. > > On Tue, Jan 14, 2020 at 2:18 PM Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > > > Unsure if related or not, but I updated pkgsrc, then ran > > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > > step with "C compiler cannot create executables". I switched to > > > another terminal, wrote a short hello world in C and indeed, gcc > > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > > > That confirms my suspicions as well. At present I am updating an > > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > > confirmed everything works as expected. Next I am bringing it up to > > 9.99.36, testing and finally will do the same with 9.99.37. > > > > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > > > Hi, > > > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > > not cause problems (with the exception of lsof, which I had installed > > > > > some times ago and which does not build any more at all, as it is > > > > > using apparently internal to the kernel interfaces). > > > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > > decided that it has a build dependency of devel/binutils from > > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > > fails to build at the extract stage - as it claims built-in dependency > > > > > on itself: > > > > > root➜pkgsrc/devel/binutils» make clean > > > > > [10[6/1788] > > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > > root➜pkgsrc/devel/binutils» make extract > > > > > [10:18:31] > > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > > => Verifying reinstall for ../../devel/binutils > > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > > ERROR: Circular dependency detected > > > > > *** Error code 1 > > > > > > > > > > Stop. > > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > > *** Error code 1 > > > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > > of failures, but overall OK). The last successful net-snmp build was > > > > > on the 11th of January under 9.99.36: > > > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > > present /etc/mk.conf. > > > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > > dependency of devel/binutils. > > > > > > > > > Chavdar >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 12:18, Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > Unsure if related or not, but I updated pkgsrc, then ran > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > step with "C compiler cannot create executables". I switched to > > another terminal, wrote a short hello world in C and indeed, gcc > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > That confirms my suspicions as well. At present I am updating an > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > confirmed everything works as expected. Next I am bringing it up to > 9.99.36, testing and finally will do the same with 9.99.37. There is no point testing. ktruss gcc on 9.99.37 exits after onlly 130 lines... I will have to downgrade the machine. > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > not cause problems (with the exception of lsof, which I had installed > > > > some times ago and which does not build any more at all, as it is > > > > using apparently internal to the kernel interfaces). > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > decided that it has a build dependency of devel/binutils from > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > fails to build at the extract stage - as it claims built-in dependency > > > > on itself: > > > > root➜pkgsrc/devel/binutils» make clean > > > > [10[6/1788] > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > root➜pkgsrc/devel/binutils» make extract > > > > [10:18:31] > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > => Verifying reinstall for ../../devel/binutils > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > ERROR: Circular dependency detected > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > *** Error code 1 > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > of failures, but overall OK). The last successful net-snmp build was > > > > on the 11th of January under 9.99.36: > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > present /etc/mk.conf. > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > dependency of devel/binutils. > > > > > > > Chavdar > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > -- > > > > > > > -- > --
Re: net/net-snmp build failure on 9.99.37
Meanwhile, I found that at least /usr/bin/gcc and /sbin/reboot are empty files. I upgraded to 9.99.37 via "sysupgrade auto $URL". On Tue, Jan 14, 2020 at 2:18 PM Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > > > Unsure if related or not, but I updated pkgsrc, then ran > > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > > py-setuptools, and gcc3 needs binutils, which fails at the configure > > step with "C compiler cannot create executables". I switched to > > another terminal, wrote a short hello world in C and indeed, gcc > > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > > avail. Also running 9.99.37, amd64, VBox guest, Linux host. > > That confirms my suspicions as well. At present I am updating an > XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and > confirmed everything works as expected. Next I am bringing it up to > 9.99.36, testing and finally will do the same with 9.99.37. > > > > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > > > Hi, > > > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > > not cause problems (with the exception of lsof, which I had installed > > > > some times ago and which does not build any more at all, as it is > > > > using apparently internal to the kernel interfaces). > > > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > > decided that it has a build dependency of devel/binutils from > > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > > fails to build at the extract stage - as it claims built-in dependency > > > > on itself: > > > > root➜pkgsrc/devel/binutils» make clean > > > > [10[6/1788] > > > > ===> Cleaning for binutils-2.26.1nb1 > > > > root➜pkgsrc/devel/binutils» make extract > > > > [10:18:31] > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > > => Verifying reinstall for ../../lang/gcc3-c > > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > > => Full dependency binutils>=2.13.2.1: NOT found > > > > => Verifying reinstall for ../../devel/binutils > > > > ERROR: This package has set PKG_FAIL_REASON: > > > > ERROR: Circular dependency detected > > > > *** Error code 1 > > > > > > > > Stop. > > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > > *** Error code 1 > > > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > > of failures, but overall OK). The last successful net-snmp build was > > > > on the 11th of January under 9.99.36: > > > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > > present /etc/mk.conf. > > > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > > dependency of devel/binutils. > > > > > > > Chavdar > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > -- > > > > > > > -- >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 11:57, Rares Aioanei wrote: > > Unsure if related or not, but I updated pkgsrc, then ran > "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to > py-setuptools, and gcc3 needs binutils, which fails at the configure > step with "C compiler cannot create executables". I switched to > another terminal, wrote a short hello world in C and indeed, gcc > (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does > nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no > avail. Also running 9.99.37, amd64, VBox guest, Linux host. That confirms my suspicions as well. At present I am updating an XCP-NG guest, which was running 9.99.26; I updated first pkgsrc and confirmed everything works as expected. Next I am bringing it up to 9.99.36, testing and finally will do the same with 9.99.37. > > On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > > > Hi, > > > > > > I bumped up my development machine to 9.99.37; after that I usually > > > rebuild pkgtools/osabi and all that depend on it; this usually does > > > not cause problems (with the exception of lsof, which I had installed > > > some times ago and which does not build any more at all, as it is > > > using apparently internal to the kernel interfaces). > > > > > > This time it failed to build net/net-snmp, as it for some reason > > > decided that it has a build dependency of devel/binutils from > > > lang/gcc3 (which I do not have built and installed so far).;binutils > > > fails to build at the extract stage - as it claims built-in dependency > > > on itself: > > > root➜pkgsrc/devel/binutils» make clean > > > [10[6/1788] > > > ===> Cleaning for binutils-2.26.1nb1 > > > root➜pkgsrc/devel/binutils» make extract > > > [10:18:31] > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > > ===> Installing dependencies for binutils-2.26.1nb1 > > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > > => Tool dependency bison>=1.0: found bison-3.4.2 > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > > => Verifying reinstall for ../../lang/gcc3-c > > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > > => Full dependency binutils>=2.13.2.1: NOT found > > > => Verifying reinstall for ../../devel/binutils > > > ERROR: This package has set PKG_FAIL_REASON: > > > ERROR: Circular dependency detected > > > *** Error code 1 > > > > > > Stop. > > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > > *** Error code 1 > > > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > > 5th of January and pkg_rolling-replace was carried out (with a number > > > of failures, but overall OK). The last successful net-snmp build was > > > on the 11th of January under 9.99.36: > > > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > > > > I was a bit too quick to hit 'return' on this mail. I can't build > > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > > present /etc/mk.conf. > > > > Any build using gcc tries to use gcc3 and then fails with the circular > > dependency of devel/binutils. > > > > > Chavdar > > > > > > > > > -- > > > > > > > > > > > -- > > --
Re: net/net-snmp build failure on 9.99.37
Unsure if related or not, but I updated pkgsrc, then ran "pkg_rolling-replace -u" . Suddenly gcc3 became a dependency to py-setuptools, and gcc3 needs binutils, which fails at the configure step with "C compiler cannot create executables". I switched to another terminal, wrote a short hello world in C and indeed, gcc (/usr/bin/gcc) does nothing, not even an error. Even "gcc -v" does nothing, and afterwards, "echo $?" returns 0. FWIW, I rebooted, to no avail. Also running 9.99.37, amd64, VBox guest, Linux host. On Tue, Jan 14, 2020 at 1:06 PM Chavdar Ivanov wrote: > > On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > > > Hi, > > > > I bumped up my development machine to 9.99.37; after that I usually > > rebuild pkgtools/osabi and all that depend on it; this usually does > > not cause problems (with the exception of lsof, which I had installed > > some times ago and which does not build any more at all, as it is > > using apparently internal to the kernel interfaces). > > > > This time it failed to build net/net-snmp, as it for some reason > > decided that it has a build dependency of devel/binutils from > > lang/gcc3 (which I do not have built and installed so far).;binutils > > fails to build at the extract stage - as it claims built-in dependency > > on itself: > > root➜pkgsrc/devel/binutils» make clean > > [10[6/1788] > > ===> Cleaning for binutils-2.26.1nb1 > > root➜pkgsrc/devel/binutils» make extract > > [10:18:31] > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > > ===> Installing dependencies for binutils-2.26.1nb1 > > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > > => Tool dependency bison>=1.0: found bison-3.4.2 > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > => Full dependency gcc3-c>=3.3.5nb1: NOT found > > => Verifying reinstall for ../../lang/gcc3-c > > => Bootstrap dependency digest>=20010302: found digest-20190127 > > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > > ===> Installing dependencies for gcc3-c-3.3.6nb1 > > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > > => Full dependency binutils>=2.13.2.1: NOT found > > => Verifying reinstall for ../../devel/binutils > > ERROR: This package has set PKG_FAIL_REASON: > > ERROR: Circular dependency detected > > *** Error code 1 > > > > Stop. > > make[2]: stopped in /usr/pkgsrc/devel/binutils > > *** Error code 1 > > > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > > 5th of January and pkg_rolling-replace was carried out (with a number > > of failures, but overall OK). The last successful net-snmp build was > > on the 11th of January under 9.99.36: > > > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > > > > I was a bit too quick to hit 'return' on this mail. I can't build > *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the > present /etc/mk.conf. > > Any build using gcc tries to use gcc3 and then fails with the circular > dependency of devel/binutils. > > > Chavdar > > > > > > -- > > > > > > -- >
Re: net/net-snmp build failure on 9.99.37
On Tue, 14 Jan 2020 at 10:52, Chavdar Ivanov wrote: > > Hi, > > I bumped up my development machine to 9.99.37; after that I usually > rebuild pkgtools/osabi and all that depend on it; this usually does > not cause problems (with the exception of lsof, which I had installed > some times ago and which does not build any more at all, as it is > using apparently internal to the kernel interfaces). > > This time it failed to build net/net-snmp, as it for some reason > decided that it has a build dependency of devel/binutils from > lang/gcc3 (which I do not have built and installed so far).;binutils > fails to build at the extract stage - as it claims built-in dependency > on itself: > root➜pkgsrc/devel/binutils» make clean > [10[6/1788] > ===> Cleaning for binutils-2.26.1nb1 > root➜pkgsrc/devel/binutils» make extract > [10:18:31] > => Bootstrap dependency digest>=20010302: found digest-20190127 > => Checksum SHA1 OK for binutils-2.26.1.tar.bz2 > => Checksum RMD160 OK for binutils-2.26.1.tar.bz2 > => Checksum SHA512 OK for binutils-2.26.1.tar.bz2 > ===> Installing dependencies for binutils-2.26.1nb1 > => Tool dependency libtool-base>=2.4.2nb9: found libtool-base-2.4.6nb2 > => Tool dependency bison>=1.0: found bison-3.4.2 > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > => Full dependency gcc3-c>=3.3.5nb1: NOT found > => Verifying reinstall for ../../lang/gcc3-c > => Bootstrap dependency digest>=20010302: found digest-20190127 > => Checksum SHA1 OK for gcc-3.3.6.tar.bz2 > => Checksum RMD160 OK for gcc-3.3.6.tar.bz2 > => Checksum SHA512 OK for gcc-3.3.6.tar.bz2 > ===> Installing dependencies for gcc3-c-3.3.6nb1 > => Tool dependency ccache-[0-9]*: found ccache-3.7.6 > => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 > => Build dependency cwrappers>=20150314: found cwrappers-20180325 > => Full dependency binutils>=2.13.2.1: NOT found > => Verifying reinstall for ../../devel/binutils > ERROR: This package has set PKG_FAIL_REASON: > ERROR: Circular dependency detected > *** Error code 1 > > Stop. > make[2]: stopped in /usr/pkgsrc/devel/binutils > *** Error code 1 > > I ran 'make -dA'; at one stage it sets _NEED_GCC3. > > Anyway; this hasn't happen before; the pkgsrc tree was updated on the > 5th of January and pkg_rolling-replace was carried out (with a number > of failures, but overall OK). The last successful net-snmp build was > on the 11th of January under 9.99.36: > > # ls -l /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > -rw-r--r-- 1 root wheel 4065659 Jan 11 23:19 > /usr/pkgsrc/packages/All/net-snmp-5.7.3nb12.tgz > I was a bit too quick to hit 'return' on this mail. I can't build *anything* now under 9.99.37; to be sure, I updated pkgsrc and hid the present /etc/mk.conf. Any build using gcc tries to use gcc3 and then fails with the circular dependency of devel/binutils. > Chavdar > > > -- > --
