How to load ffs module via boot.cfg?
Hello, I'd like to run amd64/MODULAR, but I have forgotten how to load modules via the boot loader. In particular, I need FFS in order to boot. It seems that the manual page boot.cfg(5) is incorrect, i.e. the following should work according to the instructions therein: menu=Boot MODULAR current:rndseed /var/db/entropy-file;load ffs;boot hd0a:/kernel/modular-current -v -x Given that: $ ls -l /stand/amd64/9.99.64/modules/ffs/ffs.kmod -r--r--r-- 1 root wheel 235328 Jun 1 12:24 /stand/amd64/9.99.64/modules/ffs/ffs.kmod - Jukka
Re: How to load ffs module via boot.cfg?
On Mon, Jun 01, 2020 at 01:36:01PM +0300, Jukka Ruohonen wrote: > I'd like to run amd64/MODULAR, but I have forgotten how to load modules via > the boot loader. In particular, I need FFS in order to boot. To reply to myself: it works if I uncomment "-no file-system FFS". I do not know whether I actually have ever had FFS as a module. In any case, amd64/MODULAR is not really that modular... $ modstat | grep builtin | wc -l 143 - Jukka
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Jukka Ruohonen wrote: On Mon, Jun 01, 2020 at 01:36:01PM +0300, Jukka Ruohonen wrote: I'd like to run amd64/MODULAR, but I have forgotten how to load modules via the boot loader. In particular, I need FFS in order to boot. To reply to myself: it works if I uncomment "-no file-system FFS". I do not know whether I actually have ever had FFS as a module. It's really easy. Just fix your syntax: load=ffs Also, you'll need to include a couple of dependency/required modules: load=ufs load=wapbl And finally, there are a couple of options which are not yet modular. You may need to remove some options from the modules' Makefile and build custom modules. In any case, amd64/MODULAR is not really that modular... $ modstat | grep builtin | wc -l 143 You can strip out a lot more modules and still have a functioning system. Mostly you can remove all the device drivers for devices that don't exist, but there are other things, too. FWIW, $ modstat | grep builtin | wc -l 21 $ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Paul Goyette wrote: On Mon, 1 Jun 2020, Jukka Ruohonen wrote: On Mon, Jun 01, 2020 at 01:36:01PM +0300, Jukka Ruohonen wrote: I'd like to run amd64/MODULAR, but I have forgotten how to load modules via the boot loader. In particular, I need FFS in order to boot. To reply to myself: it works if I uncomment "-no file-system FFS". I do not know whether I actually have ever had FFS as a module. It's really easy. Just fix your syntax: load=ffs Also, you'll need to include a couple of dependency/required modules: load=ufs load=wapbl And finally, there are a couple of options which are not yet modular. You may need to remove some options from the modules' Makefile and build custom modules. Oh yeah, one more thing! You will also need to update the boot loader stuff: Index: sys/lib/libsa/ffsv1.c === RCS file: /cvsroot/src/sys/lib/libsa/ffsv1.c,v retrieving revision 1.7 diff -u -p -r1.7 ffsv1.c --- sys/lib/libsa/ffsv1.c 24 Jun 2019 13:58:24 - 1.7 +++ sys/lib/libsa/ffsv1.c 5 May 2020 19:39:22 - @@ -15,7 +15,7 @@ #define ufs_dinode ufs1_dinode #define indp_t int32_t -#if 0 +#if 1 /*XXX-PRG 0 */ #defineFSMOD "wapbl/ufs/ffs" #endif Index: sys/lib/libsa/ffsv2.c === RCS file: /cvsroot/src/sys/lib/libsa/ffsv2.c,v retrieving revision 1.7 diff -u -p -r1.7 ffsv2.c --- sys/lib/libsa/ffsv2.c 24 Jun 2019 13:58:24 - 1.7 +++ sys/lib/libsa/ffsv2.c 5 May 2020 19:39:23 - @@ -15,7 +15,7 @@ #define ufs_dinode ufs2_dinode #define indp_t int64_t -#if 0 +#if 1 /*XXX-PRG 0 */ #defineFSMOD "wapbl/ufs/ffs" #endif In any case, amd64/MODULAR is not really that modular... $ modstat | grep builtin | wc -l 143 You can strip out a lot more modules and still have a functioning system. Mostly you can remove all the device drivers for devices that don't exist, but there are other things, too. FWIW, $ modstat | grep builtin | wc -l 21 $ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
panic: kernel diagnostic assertion "l == curlwp"
Just hit this panic on 9.99.64:
[ 6717.5700161] panic: kernel diagnostic assertion "l == curlwp" failed: file
"/home/source/ab/HEAD/src/sys/kern/kern_lwp.c", line 2063
[ 6717.5800161] cpu18: Begin traceback...
[ 6717.5900170] trace fp c0088f5d3c50
[ 6717.5900170] fp c0088f5d3c70 vpanic() at c04b0334
netbsd:vpanic+0x15c
[ 6717.6000167] fp c0088f5d3ce0 kern_assert() at c07ce26c
netbsd:kern_assert+0x5c
[ 6717.6100211] fp c0088f5d3d70 lwp_thread_cleanup() at c045f368
netbsd:lwp_thread_cleanup+0x80
[ 6717.6200270] fp c0088f5d3d90 lwp_exit() at c045f4ac
netbsd:lwp_exit+0xcc
[ 6717.6200270] fp c0088f5d3dd0 sys__lwp_create() at c04c2f00
netbsd:sys__lwp_create+0xe8
[ 6717.6300215] fp c0088f5d3e20 syscall() at c008a63c
netbsd:syscall+0x18c
[ 6717.6400221] tf c0088f5d3ed0 el0_trap() at c0088c74
netbsd:el0_trap
[ 6717.6500214] trapframe 0xc0088f5d3ed0 (304 bytes)
[ 6717.6500214] pc=f8abc4638958, spsr=2000
[ 6717.6600309]esr=56000135,far=f8abc465b030
[ 6717.6600309] x0=ffe68500, x1=f8abc4a1a260
[ 6717.6700228] x2=f8abc49fe200, x3=
[ 6717.6800338] x4=ffe684d0, x5=0030
[ 6717.6800338] x6=ffe68500, x7=f8abc4760208
[ 6717.6900234] x8=0001, x9=1003
[ 6717.6900234]x10=000c,x11=0001
[ 6717.7000252]x12=f8abc49e91d8,x13=
[ 6717.7000252]x14=,x15=f8abc4000980
[ 6717.7100242]x16=f8abc4a122e0,x17=f8abc4638954
[ 6717.7200306]x18=0001,x19=ffe68500
[ 6717.7200306]x20=f9a72e60,x21=0002
[ 6717.7300283]x22=f8abc4a1a260,x23=f8abc49fe200
[ 6717.7300283]x24=f9a72000,x25=ffe684d0
[ 6717.7400357]x26=f9a732a8,x27=f9a73070
[ 6717.7400357]x28=f8abc4a1b400, fp=x29=ffe68510
[ 6717.7500291] lr=x30=f8abc49fe224, sp=ffe68420
[ 6717.7600300]
[ 6717.7600300] cpu18: End traceback...
Stopped in pid 152.152 (conftest) atnetbsd:cpu_Debugger+0x4:ret
db{18}>
Re: panic: kernel diagnostic assertion "l == curlwp"
Looks like lwp_exit is called with something other than curlwp in the
sys__lwp_create error path:
https://nxr.netbsd.org/xref/src/sys/kern/sys_lwp.c#156
On Mon, 1 Jun 2020, Jared McNeill wrote:
Just hit this panic on 9.99.64:
[ 6717.5700161] panic: kernel diagnostic assertion "l == curlwp" failed: file
"/home/source/ab/HEAD/src/sys/kern/kern_lwp.c", line 2063
[ 6717.5800161] cpu18: Begin traceback...
[ 6717.5900170] trace fp c0088f5d3c50
[ 6717.5900170] fp c0088f5d3c70 vpanic() at c04b0334
netbsd:vpanic+0x15c
[ 6717.6000167] fp c0088f5d3ce0 kern_assert() at c07ce26c
netbsd:kern_assert+0x5c
[ 6717.6100211] fp c0088f5d3d70 lwp_thread_cleanup() at c045f368
netbsd:lwp_thread_cleanup+0x80
[ 6717.6200270] fp c0088f5d3d90 lwp_exit() at c045f4ac
netbsd:lwp_exit+0xcc
[ 6717.6200270] fp c0088f5d3dd0 sys__lwp_create() at c04c2f00
netbsd:sys__lwp_create+0xe8
[ 6717.6300215] fp c0088f5d3e20 syscall() at c008a63c
netbsd:syscall+0x18c
[ 6717.6400221] tf c0088f5d3ed0 el0_trap() at c0088c74
netbsd:el0_trap
[ 6717.6500214] trapframe 0xc0088f5d3ed0 (304 bytes)
[ 6717.6500214] pc=f8abc4638958, spsr=2000
[ 6717.6600309]esr=56000135,far=f8abc465b030
[ 6717.6600309] x0=ffe68500, x1=f8abc4a1a260
[ 6717.6700228] x2=f8abc49fe200, x3=
[ 6717.6800338] x4=ffe684d0, x5=0030
[ 6717.6800338] x6=ffe68500, x7=f8abc4760208
[ 6717.6900234] x8=0001, x9=1003
[ 6717.6900234]x10=000c,x11=0001
[ 6717.7000252]x12=f8abc49e91d8,x13=
[ 6717.7000252]x14=,x15=f8abc4000980
[ 6717.7100242]x16=f8abc4a122e0,x17=f8abc4638954
[ 6717.7200306]x18=0001,x19=ffe68500
[ 6717.7200306]x20=f9a72e60,x21=0002
[ 6717.7300283]x22=f8abc4a1a260,x23=f8abc49fe200
[ 6717.7300283]x24=f9a72000,x25=ffe684d0
[ 6717.7400357]x26=f9a732a8,x27=f9a73070
[ 6717.7400357]x28=f8abc4a1b400, fp=x29=ffe68510
[ 6717.7500291] lr=x30=f8abc49fe224, sp=ffe68420
[ 6717.7600300]
[ 6717.7600300] cpu18: End traceback...
Stopped in pid 152.152 (conftest) atnetbsd:cpu_Debugger+0x4:ret
db{18}>
Re: How to load ffs module via boot.cfg?
On Mon, Jun 01, 2020 at 05:26:16AM -0700, Paul Goyette wrote: > Also, you'll need to include a couple of dependency/required modules: > > load=ufs > load=wapbl Ah yes, it tried to load ffs, but ufs and wapbl were probably missing; [ 1.00] NetBSD 9.99.64 (MODULAR) #0: Mon Jun 1 14:20:02 EEST 2020 [ 1.00] jruoho@kafka:/usr/obj/sys/arch/amd64/compile/MODULAR [ 1.00] total memory = 8075 MB [ 1.00] avail memory = 7802 MB [ 1.00] entropy: entering seed from bootloader with 256 bits of entropy [ 1.00] entropy: ready [ 1.00] kobj_checksyms, 1020: [/ffs.kmod]: linker error: global symbol `ffs_vnodeop_opv_desc' redefined [ 1.00] kobj_checksyms, 1020: [/ffs.kmod]: linker error: global symbol `ffs_snapshot_fini' redefined [...] > You can strip out a lot more modules and still have a functioning > system. Mostly you can remove all the device drivers for devices > that don't exist, but there are other things, too. > > FWIW, > > $ modstat | grep builtin | wc -l >21 Nice! Since you seem to have this nailed down already, do you have time to update the off-the-shelf MODULAR config? I'd also fancy a good development kernel with which I can unload/patch/load/etc. as much code as is possible. I also noticed that some things that are disabled in GENERIC (e.g., experimental, old, or generally less useful drivers) are available as modules. The examples include odcm(4), hpacel(4), and hpqlb(4). - Jukka
Re: How to load ffs module via boot.cfg?
On Mon, 1 Jun 2020, Jukka Ruohonen wrote: FWIW, $ modstat | grep builtin | wc -l 21 Nice! Since you seem to have this nailed down already, do you have time to update the off-the-shelf MODULAR config? I'd also fancy a good development kernel with which I can unload/patch/load/etc. as much code as is possible. I've left the MODULAR kernel to Christos. My local kernel is very specific to my local set-up, and it has (almost) all of my devices hardwired and includes no unneeded device drivers. In addition, I have _no_ file-systems defined, only a few of the "standard system options", and no unnecessary pseudo-devices. I've disabled all of the following (which are enabled in sys/conf/std on all kernels): no options EXEC_SCRIPT no options EXEC_ELF64 no options COREDUMP no options AIO no options MQUEUE no options SEMAPHORE no options PTRACE (Note that SEMAPHORE is actually an addition in my local tree (I have resurrected the old ksem module!) so my local kernel has to exclude it. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: panic: kernel diagnostic assertion "l == curlwp"
lwp_exit() used to work for curlwp and !curlwp.
There is a regression that there was introduced code called from
lwp_exit() calling lwp_thread_cleanup(l) that asserts curlwp,
effectively enforcing lwp_exit() to be operational for curlwp only.
This was introduced by:
commit 2de05dfb9c516db5509614b7be366e31205ceeaa
Author: thorpej
Date: Sat Apr 4 20:20:12 2020 +
Add support for lazily generating a "global thread ID" for a LWP. This
identifier uniquely identifies an LWP across the entire system, and will
be used in future improvements in user-space synchronization primitives.
(Test disabled and libc stub not included intentionally so as to avoid
multiple libc version bumps.)
On 01.06.2020 14:45, Jared McNeill wrote:
> Looks like lwp_exit is called with something other than curlwp in the
> sys__lwp_create error path:
>
> https://nxr.netbsd.org/xref/src/sys/kern/sys_lwp.c#156
>
>
> On Mon, 1 Jun 2020, Jared McNeill wrote:
>
>> Just hit this panic on 9.99.64:
>>
>> [ 6717.5700161] panic: kernel diagnostic assertion "l == curlwp"
>> failed: file "/home/source/ab/HEAD/src/sys/kern/kern_lwp.c", line 2063
>> [ 6717.5800161] cpu18: Begin traceback...
>> [ 6717.5900170] trace fp c0088f5d3c50
>> [ 6717.5900170] fp c0088f5d3c70 vpanic() at c04b0334
>> netbsd:vpanic+0x15c
>> [ 6717.6000167] fp c0088f5d3ce0 kern_assert() at c07ce26c
>> netbsd:kern_assert+0x5c
>> [ 6717.6100211] fp c0088f5d3d70 lwp_thread_cleanup() at
>> c045f368 netbsd:lwp_thread_cleanup+0x80
>> [ 6717.6200270] fp c0088f5d3d90 lwp_exit() at c045f4ac
>> netbsd:lwp_exit+0xcc
>> [ 6717.6200270] fp c0088f5d3dd0 sys__lwp_create() at
>> c04c2f00 netbsd:sys__lwp_create+0xe8
>> [ 6717.6300215] fp c0088f5d3e20 syscall() at c008a63c
>> netbsd:syscall+0x18c
>> [ 6717.6400221] tf c0088f5d3ed0 el0_trap() at c0088c74
>> netbsd:el0_trap
>> [ 6717.6500214] trapframe 0xc0088f5d3ed0 (304 bytes)
>> [ 6717.6500214] pc=f8abc4638958, spsr=2000
>> [ 6717.6600309] esr=56000135, far=f8abc465b030
>> [ 6717.6600309] x0=ffe68500, x1=f8abc4a1a260
>> [ 6717.6700228] x2=f8abc49fe200, x3=
>> [ 6717.6800338] x4=ffe684d0, x5=0030
>> [ 6717.6800338] x6=ffe68500, x7=f8abc4760208
>> [ 6717.6900234] x8=0001, x9=1003
>> [ 6717.6900234] x10=000c, x11=0001
>> [ 6717.7000252] x12=f8abc49e91d8, x13=
>> [ 6717.7000252] x14=, x15=f8abc4000980
>> [ 6717.7100242] x16=f8abc4a122e0, x17=f8abc4638954
>> [ 6717.7200306] x18=0001, x19=ffe68500
>> [ 6717.7200306] x20=f9a72e60, x21=0002
>> [ 6717.7300283] x22=f8abc4a1a260, x23=f8abc49fe200
>> [ 6717.7300283] x24=f9a72000, x25=ffe684d0
>> [ 6717.7400357] x26=f9a732a8, x27=f9a73070
>> [ 6717.7400357] x28=f8abc4a1b400, fp=x29=ffe68510
>> [ 6717.7500291] lr=x30=f8abc49fe224, sp=ffe68420
>> [ 6717.7600300]
>> [ 6717.7600300] cpu18: End traceback...
>> Stopped in pid 152.152 (conftest) at
>> netbsd:cpu_Debugger+0x4: ret
>> db{18}>
>>
>>
>>
signature.asc
Description: OpenPGP digital signature
Re: panic: kernel diagnostic assertion "l == curlwp"
> On Jun 1, 2020, at 6:36 AM, Kamil Rytarowski wrote: > > lwp_exit() used to work for curlwp and !curlwp. > > There is a regression that there was introduced code called from > lwp_exit() calling lwp_thread_cleanup(l) that asserts curlwp, > effectively enforcing lwp_exit() to be operational for curlwp only. I just reviewed the entire code path below that assertion again, and nothing in the current incarnation of the code relies on l == curlwp. I've removed the assertion just now. -- thorpej
Re: dhcpd broken on -current (Re: CVS commit: src/external/mpl/dhcp)
Should work now... [2:55pm] 173>cvs commit socket.c /cvsroot/src/external/mpl/bind/dist/lib/isc/unix/socket.c,v <-- socket.c new revision: 1.16; previous revision: 1.15 christos signature.asc Description: Message signed with OpenPGP
On NPF connection state handling
Hi, I have made some adjustments to the NPF connection state handling in the NetBSD -current. The state behaviour can now be configured using the configuration-level parameters -- please see explanations in the manual pages at the following locations: - npf.conf(5) manual page, the "Stateful" section. - npf-params(7) manual page, the section on the 'state.key' parameters. Let me know if you have any questions or if you would like to suggest wording improvements to these sections. Thanks. -- Mindaugas
daily CVS update output
Updating src tree: P src/UPDATING P src/distrib/evbarm/installimage/Makefile P src/external/mit/libuv/lib/Makefile P src/external/mpl/bind/dist/lib/isc/unix/socket.c P src/lib/libc/citrus/citrus_ctype_template.h P src/lib/libc/locale/multibyte.h P src/lib/libpthread/pthread.c P src/lib/libpthread/pthread_cond.c P src/lib/libpthread/pthread_int.h P src/lib/libpthread/pthread_mutex.c P src/lib/libpthread/pthread_rwlock.c P src/lib/libpthread/pthread_types.h P src/sbin/modload/modload.8 P src/share/mk/bsd.README P src/share/mk/bsd.lib.mk P src/sys/arch/aarch64/aarch64/cpufunc_asm_armv8.S P src/sys/arch/amd64/amd64/cpufunc.S P src/sys/arch/amd64/include/frameasm.h P src/sys/arch/x86/include/specialreg.h P src/sys/dev/sysmon/sysmon_envsys.c P src/sys/dev/usb/xhci.c P src/sys/dev/usb/xhcireg.h P src/sys/kern/kern_lwp.c P src/sys/kern/kern_timeout.c U src/sys/modules/examples/ddbping/Makefile U src/sys/modules/examples/ddbping/ddbping.c P src/tests/dev/scsipi/libscsitest/Makefile P src/tests/dev/usb/libhid/Makefile P src/tests/fs/common/Makefile P src/tests/net/if_ipsec/t_ipsec_natt.sh P src/tests/net/ipsec/t_ipsec_natt.sh P src/tests/net/npf/t_npf.sh P src/usr.sbin/cpuctl/arch/i386.c P src/usr.sbin/puffs/mount_9p/node.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38365293 Jun 2 03:04 ls-lRA.gz
Re: How to load ffs module via boot.cfg?
On Mon, Jun 01, 2020 at 05:26:16AM -0700, Paul Goyette wrote: > You can strip out a lot more modules and still have a functioning > system. Mostly you can remove all the device drivers for devices > that don't exist, but there are other things, too. Another small module question: when running a -current kernel with 9.0 userland, the compat_90 module is loaded, as I believe it should given the MODULAR_DEFAULT_AUTOLOAD option. Due to module_start_unload_thread(9), it is also over and over again unloaded: $ modstat > d && sleep 3 && modstat > dd && diff -u d dd --- d 2020-06-02 08:19:44.893168878 +0300 +++ dd 2020-06-02 08:19:47.915516801 +0300 @@ -26,6 +26,7 @@ cir driver builtin -1 - ir clockctl driver builtin -0 - - coda vfs builtin -0 - vcoda +compat_90 exec filesys a0 - - compat_util misc builtin -0 - - coredump misc builtin -0 - - coretemp driver boot -0 - sysmon_envsys This kind of constant unload/load trashing does not seem optimal. I would expect there to be also a performance impact. So can I control module unloading at runtime? That is, I want: $ sysctl kern.module.autoload kern.module.autoload = 1 But there is no "kern.module.autounload", which I would want to be 0. - Jukka
static linking glxgears and glxinfo now fails (mult. def. _glapi_tls_Context, etc.)
Glxgears and glxinfo will no longer build in my static-linked environment.
I don't know what's changed to cause this since I last updated current
(quite some time ago, around about 8.99.32 for both src and xsrc) and
built everything, but something has, and I can't quite figure out what
to do about it.
Perhaps common "global" variables in TLS aren't being merged by the
linker? Maybe I can/should just turn off -DGLX_USE_TLS for libGL and
libglapi? But why do both libraries define these same variables in
objects that are pulled in? (see below for symbols in likely modules)
$ mynbmake dependall
link glxgears/glxgears
/build/woods/future/current-amd64-amd64-tools/lib/gcc/x86_64--netbsd/8.4.0/../../../../x86_64--netbsd/bin/ld:
/build/woods/future/current-amd64-destdir/usr/X11R7/lib/libglapi.a(u_current.o):(.tbss+0x0):
multiple definition of `_glapi_tls_Context';
/build/woods/future/current-amd64-destdir/usr/X11R7/lib/libGL.a(glxcurrent.o):(.tbss+0x0):
first defined here
/build/woods/future/current-amd64-amd64-tools/lib/gcc/x86_64--netbsd/8.4.0/../../../../x86_64--netbsd/bin/ld:
/build/woods/future/current-amd64-destdir/usr/X11R7/lib/libglapi.a(u_current.o):(.tbss+0x8):
multiple definition of `_glapi_tls_Dispatch';
/build/woods/future/current-amd64-destdir/usr/X11R7/lib/libGL.a(glxcurrent.o):(.tbss+0x8):
first defined here
collect2: error: ld returned 1 exit status
*** Failed target: glxgears
*** Failed command:
/build/woods/future/current-amd64-amd64-tools/bin/x86_64--netbsd-gcc
--sysroot=/build/woods/future/current-amd64-destdir -Wl,-z,relro
-L/build/woods/future/current-amd64-destdir/usr/X11R7/lib
-Wl,-rpath-link,/build/woods/future/current-amd64-destdir/usr/X11R7/lib
-Wl,-rpath,/usr/X11R7/lib -static -o glxgears glxgears.o -lGL -lXxf86vm
-lXfixes -lXdamage -lglapi -ldrm -lpci -lX11-xcb -lxcb-dri2 -lxcb-glx -lXext
-lX11 -lxcb -lXau -lXdmcp -lexpat -lpthread -lm
*** Error code 1
Stop.
nbmake[1]: stopped in
/more/work/woods/m-NetBSD-current/external/mit/xorg/bin/glxgears
*** Failed target: dependall
*** Failed command: cd
"/more/work/woods/m-NetBSD-current/external/mit/xorg/bin/glxgears";
/build/woods/future/current-amd64-amd64-tools/bin/nbmake realall
*** Error code 1
Stop.
nbmake: stopped in
/more/work/woods/m-NetBSD-current/external/mit/xorg/bin/glxgears
Below is the patch for static-linking glxgears/Makefile (the same is
needed for glxinfo, and many similar patches are required throughout
xorg). I had to add -lexpat since the update as well -- it was not
required for 8.99.32.
Index: external/mit/xorg/bin/glxgears/Makefile
===
RCS file:
/cvs/master/m-NetBSD/main/src/external/mit/xorg/bin/glxgears/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- external/mit/xorg/bin/glxgears/Makefile 18 Dec 2014 06:24:28 -
1.4
+++ external/mit/xorg/bin/glxgears/Makefile 2 Jun 2020 03:55:37 -
@@ -8,8 +8,8 @@
CPPFLAGS+=${X11FLAGS.THREADS}
-LDADD+=-lGL -lXext -lX11 -lpthread -lm
-DPADD+=${LIBGL} ${LIBXEXT} ${LIBX11} ${LIBPTHREAD} ${LIBM}
+LDADD+=-lGL -lXxf86vm -lXfixes -lXdamage -lglapi -ldrm -lpci -lX11-xcb
-lxcb-dri2 -lxcb-glx -lXext -lX11 -lxcb -lXau -lXdmcp -lexpat -lpthread -lm
+DPADD+=${LIBGL} ${LIBXF86VM} ${LIBXFIXES} ${LIBXDAMAGE} ${LIBGLAPI}
${LIBDRM} ${LIBPCI} ${LIBX11_XCB} ${LIBXCB_DRI} ${LIBXCB_GLX} ${LIBXEXT}
${LIBX11} ${LIBXCB} ${LIBXAU} ${LIBXDMCP} ${LIBEXPAT} ${LIBPTHREAD} ${LIBM}
.PATH: ${X11SRCDIR.mesa-demos}/src/xdemos
FYI, here's what's in each module that I think is causing the problems:
libGL.a(glxcurrent.o):
00a2 t MakeContextCurrent
U _GLOBAL_OFFSET_TABLE_
U __glXInitVertexArrayState
U __glXSendError
T __glXSetCurrentContext
0021 T __glXSetCurrentContextNull
0010 B __glX_tls_Context
D __glXmutex
U __libc_mutex_lock
U __libc_mutex_unlock
U _glapi_check_multithread
U _glapi_set_context
U _glapi_set_dispatch
B _glapi_tls_Context
0008 B _glapi_tls_Dispatch
0060 b dummyBuffer
0040 D dummyContext
b dummyVtable
U glGetString
004f T glXGetCurrentContext
0074 T glXGetCurrentDrawable
00a2 T glXMakeContextCurrent
0367 T glXMakeCurrent
00a2 T glXMakeCurrentReadSGI
libglapi.a(u_current.o):
U _GLOBAL_OFFSET_TABLE_
0017 T _glapi_get_context
0057 T _glapi_get_dispatch
B _glapi_tls_Context
0008 B _glapi_tls_Dispatch
U stub_init_once
U table_noop_array
T u_current_destroy
0001 T u_current_init
0002 T u_current_set_context
002c T u_cu
