Re: build error for -macppc
On 02/09/15 21:40, Christos Zoulas wrote: In article 54d8ba16.6090...@groessler.org, Christian Groessler ch...@groessler.org wrote: Hi, when cross-building on Linux/x86_64 for macppc I get the following error: Should be fixed now. The build went through. Thanks, chris
build error for -macppc
Hi, when cross-building on Linux/x86_64 for macppc I get the following error: # compile kdump/siginfo.o /data/home/chris/tmp/netbsd/tools/bin/powerpc--netbsd-gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn -type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/data/home/c hris/tmp/netbsd/dest -I/data/home/chris/tmp/netbsd/src/usr.bin/ktrace -I/data/home/chris/tmp/netbsd/src/sys -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include/libdrm -I/data/home/chris/tmp/netbsd/dest/usr/X 11R7/include/pixman-1 -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include -D_ALTQ_ALTQ_JOBS_H_ -D_VIA_DRM_H_ -DQXL_DRM_H -D__R128_DRM_H__ -D__SIS_DRM_H__ -D__SAVAGE_DRM_H__ -D__RADEON_DRM_H__ -D__MACH64_DRM_ H__ -D__MGA_DRM_H__ -csiginfo.c # compile kdump/kdump-ioctl.o /data/home/chris/tmp/netbsd/tools/bin/powerpc--netbsd-gcc -O2 -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn -type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/data/home/c hris/tmp/netbsd/dest -I/data/home/chris/tmp/netbsd/src/usr.bin/ktrace -I/data/home/chris/tmp/netbsd/src/sys -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include/libdrm -I/data/home/chris/tmp/netbsd/dest/usr/X 11R7/include/pixman-1 -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include -D_ALTQ_ALTQ_JOBS_H_ -D_VIA_DRM_H_ -DQXL_DRM_H -D__R128_DRM_H__ -D__SIS_DRM_H__ -D__SAVAGE_DRM_H__ -D__RADEON_DRM_H__ -D__MACH64_DRM_ H__ -D__MGA_DRM_H__ -ckdump-ioctl.c In file included from /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/xf86_OSlib.h:416:0, from kdump-ioctl.c:189: /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'outb': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:953:24: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] xf86WriteMmio8((void *)ioBase, port, value); ^ /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'outw': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:960:27: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] xf86WriteMmio16Le((void *)ioBase, port, value); ^ /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'outl': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:967:27: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] xf86WriteMmio32Le((void *)ioBase, port, value); ^ /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'inb': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:974:30: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] return xf86ReadMmio8((void *)ioBase, port); ^ /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'inw': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:981:33: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] return xf86ReadMmio16Le((void *)ioBase, port); ^ /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h: In function 'inl': /data/home/chris/tmp/netbsd/dest/usr/X11R7/include/xorg/compiler.h:988:33: error: cast discards '__attribute__((noreturn))' qualifier from pointer target type [-Werror=cast-qual] return xf86ReadMmio32Le((void *)ioBase, port); ^ cc1: all warnings being treated as errors *** Failed target: kdump-ioctl.o *** Failed command: /data/home/chris/tmp/netbsd/tools/bin/powerpc--netbsd-gcc -O2 -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/data/home/chris/tmp/netbsd/dest -I/data/home/chris/tmp/netbsd/src/usr.bin/ktrace -I/data/home/chris/tmp/netbsd/src/sys -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include/libdrm -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include/pixman-1 -I/data/home/chris/tmp/netbsd/dest/usr/X11R7/include
build error macpp with COMPAT_LINUX defined
Hi, -current from today, I'm getting --- kern-TWINPPC.MP --- /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c: In function 'linux_sys_rt_sigreturn': /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c:324:2: error: too few arguments to function 'fpu_discard' fpu_discard(); ^ In file included from ./machine/fpu.h:3:0, from /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c:69: ./powerpc/fpu.h:107:1: note: declared here fpu_discard(lwp_t *l) ^ /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c: In function 'linux_sys_sigreturn': /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c:418:2: error: too few arguments to function 'fpu_discard' fpu_discard(); ^ In file included from ./machine/fpu.h:3:0, from /data/home/chris/tmp/netbsd/src/sys/compat/linux/arch/powerpc/linux_machdep.c:69: ./powerpc/fpu.h:107:1: note: declared here fpu_discard(lwp_t *l) ^ regards, chris
Re: CVS commit: src
On 08/09/17 23:06, Swift Griggs wrote: On Wed, 9 Aug 2017, Brian Buhrow wrote: SCO was pretty much pure SVR3, so noting that COMPAT_IBCS2 implements SVR3 functionality is pretty much correct. Is anyone still using it? I used it back-in-the day. I'm probably running some of the oldest Unix variants and versions you'll run across. Also, where I work we support legacy Unix platforms and we don't have any more SCO clients. In my view "it's dead Jim". If we want to emulate a platform for Oracle, I'd think the method dejour today would be Linux emulation. Nowadays, I find that Unixware is a lot more interesting (free VxVM anyone?) than SCO ever was. As you say, it was pretty much straight SysV without many cool bells or whistles. I also find SCO super-annoying now because it's so disagreeable about it's licenses. It's tough to be more annoying than Tru64 about licenses, but SCO manages. I know IT shouldn't be personal, but after we all watched their public demise then Zombie SCO suing every FOSS company they could left ashes in my mouth, personally. I'm not anyone important in TNF, but I am a longtime user and user of other platforms (SCO included) and my vote is to kill it and reduce the kernel code size. :-) I think the real question is, is someone still using old iBCS closed source software and relying on it. regards, chris
building a kernel "the old way"
Hi, with "old way" I mean not using build.sh. I ran: - [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ config GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd ../compile/GENERIC/ [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ make making sure the compat library is up to date... make[1]: cannot open ../../../../../../compat/common/Makefile. make[1]: stopped in /usr/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat *** Error code 2 Stop. make: stopped in /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ cat /etc/mk.conf MKUNPRIVED=yes #USETOOLS=yes TOOLDIR=/local/netbsd-src/tools RELEASEDIR=/local/netbsd-src/release BSDSRCDIR=/local/netbsd-src/src BSDOBJDIR=/local/netbsd-src/obj MKOBJDIRS=yes MKOBJ=yes OBJMACHINE=yes DESTDIR=/local/netbsd-src/dest #PKG_OPTIONS.emacs=dbus svg x11 xft2 gnutls xaw xml PKG_OPTIONS.emacs=dbus x11 xft2 gnutls xaw xml PKG_OPTIONS.firefox+=debug-info PKGSRC_KEEP_BIN_PKGS=yes [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ find . -type d . [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ - So source code isn't under /usr/src, but /local/netbsd-src/src due to tight space in the /usr partition. Running "make depend" first doesn't help, it gives a similar message. It says, "make[1]: stopped in /usr/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat", but there is no "lib/compat" directory there. I'm using -current from around May-17. Is building a kernel this way not supported anymore? I have to admit, I don't remember when I did it last time before, probably not for a few years. regards, chris
Re: building a kernel "the old way"
On 05/24/17 17:44, Patrick Welche wrote: On Wed, May 24, 2017 at 04:59:58PM +0200, Christian Groessler wrote: Hi, with "old way" I mean not using build.sh. I ran: - [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ config GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" ^ Did you run "make depend"? (Just checking...) No, not in this example. But I wrote: Running "make depend" first doesn't help, it gives a similar message. regards, chris
Re: building a kernel "the old way"
On 05/24/17 17:35, Robert Swindells wrote: Christian Groessler <ch...@groessler.org> wrote: with "old way" I mean not using build.sh. [snip] I don't use build.sh to build kernels but use a workflow inbetween it and the old way that you describe. I cross build the tools for whatever target architecture I want using build.sh. Then: % cd src/sys/arch/macppc/conf % /path/to/macppc-tools/bin/nbconfig GENERIC % cd ../compile/GENERIC % /path/to/macppc-tools/bin/nbmake-macppc depend % /path/to/macppc-tools/bin/nbmake-macppc You could probably look in the nbmake-macppc shell script to work out what extra environment variables you need to set in order to get your way to work but I think there is still the chance of a mismatch between the host tools and the -current source tree. I'm not cross-compiling here. I'm trying to build a macppc kernel on a macppc host. My installation was done by cross-compiling on amd64 (using build.sh), then installing on the Mac. After I had verified that it basically works, I compiled it again (the whole system, using build.sh) on the target Mac. This is the version which is currently installed. So I think the tools should be good and matching. Also, my amd64 development machine is so much faster than anything else that I always cross-compile kernels anyway. My amd65 machine is also way faster. That's the reason I first compile a version there to verify that it's "good". But then I compile it again on the Mac. This is a good test that it's basically "stable". But now I just want to compile a modified kernel to check something out. But the nice, simple, way I was using in older times doesn't work anymore :-( regards, chris
Re: building a kernel "the old way"
On 05/25/17 01:25, Christian Groessler wrote: If you guys/gals run "config"/"nbconfig", do you have a lib/compat dir in the compile dir? Any input on that? regards, chris
Re: building a kernel "the old way"
On 05/24/17 18:55, Martin Husemann wrote: On Wed, May 24, 2017 at 04:59:58PM +0200, Christian Groessler wrote: making sure the compat library is up to date... make[1]: cannot open ../../../../../../compat/common/Makefile. Do you have a full source tree? Why is it not finding that file relative to your compile dir? I should have a complete source tree. 'build.sh', at least, was able to build the whole system without errors. The file is there, but in ../../../../compat/common(so two ".."s less). Like I've written, > It says, "make[1]: stopped in /usr/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat", but there is no "lib/compat" directory there. "make" thinks it's in the lib/compat dir, but there is no such dir If you guys/gals run "config"/"nbconfig", do you have a lib/compat dir in the compile dir? regards, chris
Re: building a kernel "the old way"
I've also tried to use the "tools", it fails, too, but a bit differently: -- [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ /local/netbsd-src/tools/bin/nbconfig GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd - /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ /local/netbsd-src/tools/bin/nbmake-macppc making sure the compat library is up to date... nbmake[1]: cannot open ../../../../../../compat/common/Makefile. nbmake[1]: stopped in /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat *** Failed target: /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat/libcompat.a *** Failed command: cd /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat && /local/netbsd-src/tools/bin/nbmake -f ../../../../../../compat/common/Makefile COMPATDIR=../../../../../../compat/common CC=/local/netbsd-src/tools/bin/powerpc--netbsd-gcc CFLAGS=\ \ -mno-strict-align\ \ \ -Wa,-maltivec\ \ \ -msdata=none\ \ -msoft-float\ \ -ffreestanding\ -fno-zero-initialized-in-bss\ \ -O2\ -fno-strict-aliasing\ -fno-common\ \ \ \ \ -std=gnu99\ \ \ -Werror\ -Wreturn-type\ -Wall\ -Wno-main\ -Wno-format-zero-length\ -Wpointer-arith\ -Wmissing-prototypes\ -Wstrict-prototypes\ -Wold-style-definition\ -Wswitch\ -Wshadow\ -Wcast-qual\ -Wwrite-strings\ -Wno-unreachable-code\ -Wno-pointer-sign\ -Wno-attributes\ -Wno-sign-compare\ \ \ AS=/local/netbsd-src/tools/bin/powerpc--netbsd-as AFLAGS=\ \ \ -D_NOREGNAMES\ -D_LOCORE\ -Wa,--fatal-warnings\ \ AR=/local/netbsd-src/tools/bin/powerpc--netbsd-ar NM=/local/netbsd-src/tools/bin/powerpc--netbsd-nm LORDER=NM=/local/netbsd-src/tools/bin/powerpc--netbsd-nm\ MKTEMP=/local/netbsd-src/tools/bin/nbmktemp\ /local/netbsd-src/tools/bin/nblorder TSORT=/local/netbsd-src/tools/bin/nbtsort\ -q RANLIB=/local/netbsd-src/tools/bin/powerpc--netbsd-ranlib LD=/local/netbsd-src/tools/bin/powerpc--netbsd-ld LDFLAGS=\ --sysroot=/local/netbsd-src/dest STRIP=/local/netbsd-src/tools/bin/powerpc--netbsd-strip MACHINE=macppc MACHINE_ARCH=powerpc COMPATCPPFLAGS=--sysroot=/local/netbsd-src/dest\ -Dmacppc=macppc\ -I../../.\ -I../../../../../../../common/lib/libx86emu\ -I../../../../../../../common/include\ -I../../../../../../arch\ -I../../../../../..\ -nostdinc\ -DZS_CONSOLE_ABORT\ -DFORCE_FUNCTION_KEYS\ -D_KERNEL\ -D_KERNEL_OPT\ -std=gnu99\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/quad\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/string\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/arch/powerpc/string\ -I../../../../../../external/bsd/ipf\ -I../../../../../../external/isc/atheros_hal/dist\ -I../../../../../../external/isc/atheros_hal/ic LINTFLAGS=-bcehnxzFS libcompat.a *** Error code 2 Stop. nbmake: stopped in /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ find . -type d . [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ -- Still, problem seems to be that there is no "lib/compat" subdir. So, with people stating that it works for them, maybe the custom source directory (/local/netbsd-src/src) instead of /usr/src could be the problem? I don't have space on this system to copy the source to /usr/src. Btw., there is a symlink from /usr/src to /local/netbsd-src/src: - [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ ls -l /usr total 148 drwxr-xr-x 8 root wheel512 May 3 20:14 X11R7/ drwxr-xr-x 2 root wheel 8192 May 4 23:29 bin/ drwxr-xr-x 17 chris chris 1024 Feb 21 00:50 chris/ drwxr-xr-x 3 root wheel 1024 May 4 23:22 games/ drwxr-xr-x 59 root wheel 5120 May 4 23:20 include/ drwxr-xr-x 7 root wheel 35840 May 4 08:44 lib/ drwxr-xr-x 6 root wheel512 May 3 20:14 libdata/ drwxr-xr-x 5 root wheel 1536 May 4 23:29 libexec/ drwxr-xr-x 2 root wheel512 Jul 18 2013 local/ drwxr-xr-x 2 root wheel512 May 4 08:45 mdec/ lrwxr-xr-x 1 root wheel 21 Jul 17 2013 obj@ -> /local/netbsd-src/obj lrwxr-xr-x 1 root wheel 10 Jul 17 2013 pkg@ -> /local/pkg lrwxr-xr-x 1 root wheel 24 Jul 17 2013 pkgsrc@ -> /local/netbsd-src/pkgsrc drwxr-xr-x 2 root wheel 6144 May 4 23:21 sbin/ drwxr-xr-x 33 root wheel512 May 3 20:14 share/ lrwxr-xr-x 1 root wheel 21 Jul 17 2013 src@ -> /local/netbsd-src/src drwxr-xr-x 24 root wheel512 May 4 08:56 tests/ lrwxr-xr-x 1 root wheel 22 Jul 17 2013 xsrc@ -> /local/netbsd-src/xsrc [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ -
Re: building a kernel "the old way"
Where do you see that "cd" is failing? I've missed that... The source tree is "owned" by me (my user) and this user also previously compiled the whole system with build.sh. regards, chris On 05/25/17 02:26, Brian Buhrow wrote: hello. The error says the command cd is failing. I wonder if you're running into a permissions problem. Did the same uid build the source tree as is trying to build the kernel? A lack of permission could certainly create the kind of behavior you're seeing. -thanks -Brian
Re: building a kernel "the old way"
On 05/24/17 20:16, Valery Ushakov wrote: On Wed, May 24, 2017 at 16:59:58 +0200, Christian Groessler wrote: with "old way" I mean not using build.sh. I ran: - [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ config GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd ../compile/GENERIC/ [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ make making sure the compat library is up to date... make[1]: cannot open ../../../../../../compat/common/Makefile. $ make USETOOLS=no should work - if the sources are ~the same as the host you build on (config is compatible, etc, etc). Doesn't help: --- [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ config GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd ../compile/GENERIC/ [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ make USETOOLS=no making sure the compat library is up to date... make[1]: cannot open ../../../../../../compat/common/Makefile. make[1]: stopped in /usr/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat *** Error code 2 Stop. make: stopped in /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ --- regards, chris
Re: building a kernel "the old way"
On 05/25/17 01:44, Robert Swindells wrote: Christian Groessler <ch...@groessler.org> wrote: I should have a complete source tree. 'build.sh', at least, was able to build the whole system without errors. The file is there, but in ../../../../compat/common(so two ".."s less). Like I've written, It says, "make[1]: stopped in /usr/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/compat", but there is no "lib/compat" directory there. "make" thinks it's in the lib/compat dir, but there is no such dir If you guys/gals run "config"/"nbconfig", do you have a lib/compat dir in the compile dir? The lib/compat directory is created by "make depend". I would delete your src/sys/arch/macppc/compile/GENERIC directory and start again. I have to admit, I had omitted the "depend" step in most of my tests. I've always been removing the compile/GENERIC dir btw. my tests, but still: [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ rm -rf ../compile/GENERIC/ [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ /local/netbsd-src/tools/bin/nbconfig GENERIC Build directory is ../compile/GENERIC Don't forget to run "make depend" [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/conf]$ cd - /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ /local/netbsd-src/tools/bin/nbmake-macppc depend depending the kern library objects nbmake[1]: cannot open ../../../../../../lib/libkern/Makefile. nbmake[1]: stopped in /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/kern *** Failed target: dependkernlib *** Failed command: cd /local/netbsd-src/obj/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/lib/kern && /local/netbsd-src/tools/bin/nbmake -f ../../../../../../lib/libkern/Makefile KERNDIR=../../../../../../lib/libkern CC=/local/netbsd-src/tools/bin/powerpc--netbsd-gcc CFLAGS=\ \ -mno-strict-align\ \ \ -Wa,-maltivec\ \ \ -msdata=none\ \ -msoft-float\ \ -ffreestanding\ -fno-zero-initialized-in-bss\ \ -O2\ -fno-strict-aliasing\ -fno-common\ \ \ \ \ -std=gnu99\ \ \ -Werror\ -Wreturn-type\ -Wall\ -Wno-main\ -Wno-format-zero-length\ -Wpointer-arith\ -Wmissing-prototypes\ -Wstrict-prototypes\ -Wold-style-definition\ -Wswitch\ -Wshadow\ -Wcast-qual\ -Wwrite-strings\ -Wno-unreachable-code\ -Wno-pointer-sign\ -Wno-attributes\ -Wno-sign-compare\ \ \ CPUFLAGS= AS=/local/netbsd-src/tools/bin/powerpc--netbsd-as AFLAGS=\ \ \ -D_NOREGNAMES\ -D_LOCORE\ -Wa,--fatal-warnings\ \ LORDER=NM=/local/netbsd-src/tools/bin/powerpc--netbsd-nm\ MKTEMP=/local/netbsd-src/tools/bin/nbmktemp\ /local/netbsd-src/tools/bin/nblorder TSORT=/local/netbsd-src/tools/bin/nbtsort\ -q LD=/local/netbsd-src/tools/bin/powerpc--netbsd-ld STRIP=/local/netbsd-src/tools/bin/powerpc--netbsd-strip AR=/local/netbsd-src/tools/bin/powerpc--netbsd-ar NM=/local/netbsd-src/tools/bin/powerpc--netbsd-nm RANLIB=/local/netbsd-src/tools/bin/powerpc--netbsd-ranlib SIZE=/local/netbsd-src/tools/bin/powerpc--netbsd-size MACHINE=macppc MACHINE_ARCH=powerpc KERNCPPFLAGS=--sysroot=/local/netbsd-src/dest\ -Dmacppc=macppc\ -I../../.\ -I../../../../../../../common/lib/libx86emu\ -I../../../../../../../common/include\ -I../../../../../../arch\ -I../../../../../..\ -nostdinc\ -DZS_CONSOLE_ABORT\ -DFORCE_FUNCTION_KEYS\ -D_KERNEL\ -D_KERNEL_OPT\ -std=gnu99\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/quad\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/string\ -I/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC/../../../../lib/libkern/../../../common/lib/libc/arch/powerpc/string\ -I../../../../../../external/bsd/ipf\ -I../../../../../../external/isc/atheros_hal/dist\ -I../../../../../../external/isc/atheros_hal/ic KERNMISCCPPFLAGS= LINTFLAGS=-bcehnxzFS LIBKERN_ARCH= COMMON_MACHINE_ARCH= depend *** Error code 2 Stop. nbmake: stopped in /local/netbsd-src/src/sys/arch/macppc/compile/GENERIC [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ find . -type d . [muc-twinppc:/local/netbsd-src/src/sys/arch/macppc/compile/GENERIC]$ regards, chris
build error with MKX11MOTIF=yes in mk.conf
Hi, recent -current on amd64: # cat /etc/mk.conf MKCATPAGES=yes MKCOMPAT=yes MKCTF=yes MKDEBUG=yes MKDEBUGLIB=yes MKDYNAMICROOT=no MKOBJ=yes MKOBJDIRS=yes MKX11=yes MKX11MOTIF=yes TOOLDIR=/usr/tools # I'm getting # create libGLw/GLwMDrawA.d CC=/usr/tools/bin/x86_64--netbsd-gcc /usr/tools/bin/nbmkdep -f GLwMDrawA.d.tmp -- -std=gnu99 --sysroot=/ -I/usr/pkg/include -DCSRG_BASED -DFUNCPROTO=15 -DNARROWPROTO -I/usr/X11R7/include -D__AMD64__ /usr/xsrc/external/mit/glw/dist/GLwMDrawA.c && mv -f GLwMDrawA.d.tmp GLwMDrawA.d In file included from /usr/xsrc/external/mit/glw/dist/GLwMDrawA.c:41:0: /usr/xsrc/external/mit/glw/dist/GLwDrawA.c:53:10: fatal error: Xm/PrimitiveP.h: No such file or directory #include ^ compilation terminated. nbmkdep: compile failed. *** [GLwMDrawA.d] Error code 1 make[4]: stopped in /usr/src/external/mit/xorg/lib/libGLw 1 error regards, chris
Re: tar extract changed since netbsd-8? (extracting sets over running system)
On 2019-11-13 20:29, Christos Zoulas wrote: Yes, but open(O_EXCL) does not protect you against mmapped segments (which has the potential to kill running processes that use shared libraries/jar/other mapped files) or crashing in the middle of writing a file and leaving stuff 1/2 written. For me safety trumps speed (after all we don't mount our filesystems async :-), so I would prefer that the default is slow and safe as opposed to fast and unsafe, like the old pax/tar did: https://nxr.netbsd.org/xref/src/bin/pax/file_subs.c#238 But isn't the flow "unlink and extract new file" safe in this regard? I don't like the "temp file" idea, since it potentially (depending on old and new file size) requires double the space on the file system. regards, chris
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
build error for macppc
Hello, recent -current gives me this when I try to build macppc on Linux/x86_64: --- dependall ===> external/gpl3/gdb.old/lib/libsim cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -I. -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/sim/ppc -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/include -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/lib/libsim/arch/powerpc -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/lib/libsim/../libbfd/arch/powerpc -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/bfd -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/gdb -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/gdb/config -DHAVE_COMMON_FPU -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/lib/libsim/../arch/powerpc -I/data/home/chris/tmp/netbsd/src/external/gpl3/gdb.old/dist/sim/common igen.lo table.lo lf.lo misc.lo filter_host.lo ld-decode.lo ld-cache.lo filter.lo ld-insn.lo gen-model.lo gen-itable.lo gen-icache.lo gen-semantics.lo gen-idecode.lo gen-support.lo -o igen /usr/bin/ld: ld-insn.lo:(.bss+0x0): multiple definition of `max_model_fields_len'; igen.lo:(.bss+0xc): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x60): multiple definition of `models'; igen.lo:(.bss+0x68): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x58): multiple definition of `last_model'; igen.lo:(.bss+0x60): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x48): multiple definition of `last_model_macro'; igen.lo:(.bss+0x50): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x50): multiple definition of `model_macros'; igen.lo:(.bss+0x58): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x38): multiple definition of `last_model_function'; igen.lo:(.bss+0x40): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x40): multiple definition of `model_functions'; igen.lo:(.bss+0x48): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x28): multiple definition of `last_model_internal'; igen.lo:(.bss+0x30): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x30): multiple definition of `model_internal'; igen.lo:(.bss+0x38): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x18): multiple definition of `last_model_static'; igen.lo:(.bss+0x20): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x20): multiple definition of `model_static'; igen.lo:(.bss+0x28): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x8): multiple definition of `last_model_data'; igen.lo:(.bss+0x10): first defined here /usr/bin/ld: ld-insn.lo:(.bss+0x10): multiple definition of `model_data'; igen.lo:(.bss+0x18): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x0): multiple definition of `max_model_fields_len'; igen.lo:(.bss+0xc): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x50): multiple definition of `model_macros'; igen.lo:(.bss+0x58): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x60): multiple definition of `models'; igen.lo:(.bss+0x68): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x40): multiple definition of `model_functions'; igen.lo:(.bss+0x48): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x10): multiple definition of `model_data'; igen.lo:(.bss+0x18): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x20): multiple definition of `model_static'; igen.lo:(.bss+0x28): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x30): multiple definition of `model_internal'; igen.lo:(.bss+0x38): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x8): multiple definition of `last_model_data'; igen.lo:(.bss+0x10): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x18): multiple definition of `last_model_static'; igen.lo:(.bss+0x20): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x28): multiple definition of `last_model_internal'; igen.lo:(.bss+0x30): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x38): multiple definition of `last_model_function'; igen.lo:(.bss+0x40): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x48): multiple definition of `last_model_macro'; igen.lo:(.bss+0x50): first defined here /usr/bin/ld: gen-model.lo:(.bss+0x58): multiple definition of `last_model'; igen.lo:(.bss+0x60): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x0): multiple definition of `max_model_fields_len'; igen.lo:(.bss+0xc): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x8): multiple definition of `last_model_data'; igen.lo:(.bss+0x10): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x10): multiple definition of `model_data'; igen.lo:(.bss+0x18): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x18): multiple definition of `last_model_static'; igen.lo:(.bss+0x20): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x20): multiple definition of `model_static'; igen.lo:(.bss+0x28): first defined here /usr/bin/ld: gen-itable.lo:(.bss+0x28): multiple definition of `last_model_internal'; igen.lo:(.bss+0x30): first defined here /usr/bin/ld:
cross-build error on Linux host
Hi,
...
dependall ===> tools/lint1
# compile lint1/tyname.lo
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-I/data/home/chris/tmp/netbsd/tools/include/compat -I/data/home/ch
ris/tmp/netbsd/src/tools/compat -DHAVE_NBTOOL_CONFIG_H=1
-D_FILE_OFFSET_BITS=64
-I/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bi
n/xlint/lint1 -I. -DPASS=\"lint1.h\"
-I/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../arch/x86_64
-I/data/home/c
hris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../common -c
-o tyname.lo.o /data/home/chris/tmp/netbsd/src/tools/lint1/../..
/usr.bin/xlint/lint1/../common/tyname.c
/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../common/tyname.c:86:1:
error: expected '=', ',', ';', 'asm' or '__
attribute__' before 'intern'
86 | intern(const char *name)
| ^~
/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../common/tyname.c:
In function 'type_name':
/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../common/tyname.c:373:9:
warning: implicit declaration of function
'intern' [-Wimplicit-function-declaration]
373 | name = intern(buf.data);
| ^~
/data/home/chris/tmp/netbsd/src/tools/lint1/../../usr.bin/xlint/lint1/../common/tyname.c:373:7:
warning: assignment to 'const char *' from
'int' makes pointer from integer without a cast [-Wint-conversion]
373 | name = intern(buf.data);
| ^
*** Failed target: tyname.lo
...
After this change to src/usr.bin/xlint/common/tyname.c it works:
---
diff -u -r1.25 tyname.c
--- tyname.c 24 Jan 2021 11:55:57 - 1.25
+++ tyname.c 26 Jan 2021 12:43:50 -
@@ -82,7 +82,7 @@
}
/* Return the canonical instance of the string, with unlimited life
time. */
-static const char * __noinline
+static const char * __attribute__((noinline))
intern(const char *name)
{
name_tree_node *n = type_names, **next;
---
Host compiler is
cc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
regards,
chris
Re: Problem reports for version control systems
On 4/30/21 7:31 AM, Lloyd Parkes wrote: Hi all, The problem reports people have in their emails are completely inadequate for trying to determine what is going wrong for people trying to access the NetBSD source. I'm rsync'ing the CVS tree to my local server and then run CVS against my server on the LAN. No problems... regards, chris
Re: NetBSD 10.0 timeline and branch status
On 9/10/23 10:59, Martin Husemann wrote: On Sun, Aug 20, 2023 at 02:07:25PM +0200, Martin Husemann wrote: The tricky pullups are done (thanks to everyone who helped with it), and package builds are going - so now it looks like we will be able to switch from BETA to release candidate state soonish. See https://wiki.netbsd.org/releng/netbsd-10/ ... so, as ususual, things do not work out as smooth as we hoped. We had to do some shared library version bumps to the netbsd-10 branch as a consequence of the openssl pullup. All critical changes (and especially everything that would normally not be allowed for a release branch) have happend now. Unfortunately the additional shared library changes require another round of package rebuilds from scratch. Everyond building packages against netbsd-10: please start a new round from scratch. Sorry for the bumpy ride, I hope we are really there now. The above reference wiki page has been updated, schedule had to be adjusted slightly - but fortunately we found the issues quickly and only have a minor delay now. Thanks to everyone helping and testing, looking forward to a great 10.0 release! Has port-evbarm/57551 been fixed? It's not running stable on my Raspberry Pi 3. regards, chris
build fails for evbmips64-eb
Hi, trying to build today's version with $ build.sh -m evbmips64-eb -M ... -D ... -R ... -T ... -X ... -U -x -j 32 release iso-image install-image fails with ... == 6 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/libdata/debug/netbsd-msk0-XLSATX32.debug ./usr/libdata/debug/netbsd-msk0-XLSATX64.debug ./usr/libdata/debug/netbsd-sd0a-XLSATX32.debug ./usr/libdata/debug/netbsd-sd0a-XLSATX64.debug ./usr/libdata/debug/netbsd-wm0-XLSATX32.debug ./usr/libdata/debug/netbsd-wm0-XLSATX64.debug end of 6 missing files == *** Failed target: checkflist ... regards, chris
GZIP warnings when building
Hi, probably known and considered not important, but I wanted to mention that I'm getting warnings like this when building a release: --- do-games --- Creating games.tgz gzip: warning: GZIP environment variable is deprecated; use an alias or script regards, chris
Re: GZIP warnings when building
On 2/15/23 16:44, Martin Husemann wrote: On Wed, Feb 15, 2023 at 03:09:37PM +0100, Christian Groessler wrote: Hi, probably known and considered not important, but I wanted to mention that I'm getting warnings like this when building a release: Sounds like a local problem - what is in your $GZIP (and why)? I don't have a GZIP env variable. I'm building on Linux Debian/amd64. [blitz:~]$ gzip --version gzip 1.12 Copyright (C) 2018 Free Software Foundation, Inc. Copyright (C) 1993 Jean-loup Gailly. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <https://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law. Written by Jean-loup Gailly. [blitz:~]$ regards, chris
