Re: build failure in libz
Hi, # This problem had already been fixed. My previous message was # stalled somehow and delivered after preceding ones... On 2020/04/23 13:57, Michael van Elst wrote: rokuyama...@gmail.com (Rin Okuyama) writes: It seems that files in the following directories are rolled back to rev 1.x after removing & re-adding to phil-wifi branch: src/common/dist/zlib src/crypto/external/bsd/heimdal src/crypto/dist/ipsec-tools For example for src/common/dist/zlib/inflate.h, 1.1 is checked out whereas 1.1.1.2 should be. The default branch information (which was the vendor branch for these files) was removed and cvs would return the trunk version instead. This is usually an admin operation, but it also happens when removing a file and temporarily in a commit. Thank you for your message. What a confusing feature! I could not imagine such a behavior without your explanation... rin
Re: build failure in libz
rokuyama...@gmail.com (Rin Okuyama) writes: >It seems that files in the following directories are rolled back to >rev 1.x after removing & re-adding to phil-wifi branch: >src/common/dist/zlib >src/crypto/external/bsd/heimdal >src/crypto/dist/ipsec-tools >For example for src/common/dist/zlib/inflate.h, 1.1 is checked out >whereas 1.1.1.2 should be. The default branch information (which was the vendor branch for these files) was removed and cvs would return the trunk version instead. This is usually an admin operation, but it also happens when removing a file and temporarily in a commit. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: build failure in libz
Hi, It seems that files in the following directories are rolled back to rev 1.x after removing & re-adding to phil-wifi branch: src/common/dist/zlib src/crypto/external/bsd/heimdal src/crypto/dist/ipsec-tools For example for src/common/dist/zlib/inflate.h, 1.1 is checked out whereas 1.1.1.2 should be. I don't understand why commits to phil-wifi affected to -HEAD... Thanks, rin On 2020/04/22 7:41, Thomas Klausner wrote: Hi! I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me. When I try building NetBSD-current now, it fails in libz with: # compile libz/infback.o gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror -fPIE -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -I/usr/src/common/dist/zlib -D_FORTIFY_SOURCE=2 -c - Wno-error=implicit-fallthrough /usr/src/common/dist/zlib/infback.c -o infback.o /usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’: /usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has no member named ‘wnext’; did you mean ‘next’? state->wnext = 0; ^ next /usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’: /usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall through [-Wimplicit-fallthrough=] state->mode = LEN; ^ /usr/src/common/dist/zlib/infback.c:483:9: note: here case LEN: ^~~~ *** Error code 1 And /usr/src/common/dist/zlib/inflate.c: In function 'inflateMark': /usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' has no member named 'back' return (long)(((unsigned long)((long)state->back)) << 16) + ^~ /usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' has no member named 'was'; did you mean 'last'? (state->mode == MATCH ? state->was - state->length : 0)); ^~~ last I don't see a mail about this from the build bots, and I don't see any relevant changes between April 12 and today (about an hour ago) that'd explain it. Any ideas? Thomas
Re: build failure in libz
On Wed, Apr 22, 2020 at 01:45:25PM +0100, Robert Swindells wrote: > Do we need to do anything special to fix it in our checked out trees, or > will just a 'cvs update' do it ? I think a cvs up should do. Martin
Re: build failure in libz
Martin Husemann wrote: >On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote: >> Seems fixed now. Thank you! > >No quite sure what happened, but every file affected by the re-adding >that was from a vendor branch and unchanged on the wifi branch got >its default branch set to trunk (instead of the vendor branch). Do we need to do anything special to fix it in our checked out trees, or will just a 'cvs update' do it ?
Re: build failure in libz
On Wed, Apr 22, 2020 at 09:27:44PM +0900, Rin Okuyama wrote: > Seems fixed now. Thank you! No quite sure what happened, but every file affected by the re-adding that was from a vendor branch and unchanged on the wifi branch got its default branch set to trunk (instead of the vendor branch). spz fixed it (as I don't have "cvs admin -b" access), thanks a lot! (I am not sure I want to know what stupid thing I did to trigger it, or whether it is a generic cvs bug...) Moving to hg-trial now. Martin
Re: build failure in libz
On 2020/04/22 16:01, Martin Husemann wrote: On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote: I don't understand why commits to phil-wifi affected to -HEAD... ARGH - I hate cvs. Will fix... Seems fixed now. Thank you! rin
Re: build failure in libz
On Wed, Apr 22, 2020 at 03:48:30PM +0900, Rin Okuyama wrote: > I don't understand why commits to phil-wifi affected to -HEAD... ARGH - I hate cvs. Will fix... Martin
Re: build failure in libz
On Tue, 21 Apr 2020 at 23:42, Thomas Klausner wrote: > > Hi! > > I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me. > > When I try building NetBSD-current now, it fails in libz with: > > > # compile libz/infback.o > gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional > -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual > -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror > -fPIE -fstack-protector -Wstack-protector --param ssp-buffer-size=1 > -I/usr/src/common/dist/zlib -D_FORTIFY_SOURCE=2 -c - > Wno-error=implicit-fallthrough /usr/src/common/dist/zlib/infback.c -o > infback.o > /usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’: > /usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has > no member named ‘wnext’; did you mean ‘next’? > state->wnext = 0; > ^ > next > /usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’: > /usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall > through [-Wimplicit-fallthrough=] > state->mode = LEN; > ^ > /usr/src/common/dist/zlib/infback.c:483:9: note: here > case LEN: > ^~~~ > *** Error code 1 > > > And > > /usr/src/common/dist/zlib/inflate.c: In function 'inflateMark': > /usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' > has no member named 'back' > return (long)(((unsigned long)((long)state->back)) << 16) + >^~ > /usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' > has no member named 'was'; did you mean 'last'? > (state->mode == MATCH ? state->was - state->length : 0)); > ^~~ > last > > I don't see a mail about this from the build bots, and I don't see any > relevant changes between April 12 and today (about an hour ago) that'd > explain it. > > Any ideas? When I get something like this, I usually 'make cleandir' in /usr/[x]src and wipe the obj directory. This usually sorts things out. I see similar error in my log from the 11th of April: ... /home/sysbuild/src/tools/binutils/../../external/gpl3/binutils.old/dist/bfd/archive.c:860:30: error: lvalue required as left operand of assignment bfd_is_thin_archive (abfd) = (strncmp (armag, ARMAGT, SARMAG) == 0); Obviously a different place, but I did the above and my next build completed fine, even if there was no cvs changes between the faulty and the successful build, only the above action... > Thomas > Chavdar --
build failure in libz
Hi! I'm running a userland from 2020-04-12/amd64 when NetBSD built fine for me. When I try building NetBSD-current now, it fails in libz with: # compile libz/infback.o gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Werror -fPIE -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -I/usr/src/common/dist/zlib -D_FORTIFY_SOURCE=2 -c - Wno-error=implicit-fallthrough /usr/src/common/dist/zlib/infback.c -o infback.o /usr/src/common/dist/zlib/infback.c: In function ‘inflateBackInit_’: /usr/src/common/dist/zlib/infback.c:69:12: error: ‘struct inflate_state’ has no member named ‘wnext’; did you mean ‘next’? state->wnext = 0; ^ next /usr/src/common/dist/zlib/infback.c: In function ‘inflateBack’: /usr/src/common/dist/zlib/infback.c:481:25: warning: this statement may fall through [-Wimplicit-fallthrough=] state->mode = LEN; ^ /usr/src/common/dist/zlib/infback.c:483:9: note: here case LEN: ^~~~ *** Error code 1 And /usr/src/common/dist/zlib/inflate.c: In function 'inflateMark': /usr/src/common/dist/zlib/inflate.c:1559:47: error: 'struct inflate_state' has no member named 'back' return (long)(((unsigned long)((long)state->back)) << 16) + ^~ /usr/src/common/dist/zlib/inflate.c:1561:44: error: 'struct inflate_state' has no member named 'was'; did you mean 'last'? (state->mode == MATCH ? state->was - state->length : 0)); ^~~ last I don't see a mail about this from the build bots, and I don't see any relevant changes between April 12 and today (about an hour ago) that'd explain it. Any ideas? Thomas
