02:11:00 [illumos-gate] 17061 want a more cautious wrmsr -- Luqman Aden 08:05:40 [illumos-gate] 17105 unix: dboot should be built with NO_SIMD -- Toomas Soome 08:09:27 [illumos-gate] 17099 ehci: address of NULL pointer -- Toomas Soome 08:15:51 [illumos-gate] 17100 cmlb: unsigned 'capacity' is never less than zero -- Toomas Soome 11:36:32 .oO Make only the text component of messages appear (remove this in SVR4.1) 11:41:56 Cheers all, got a question about (GNU?) libtool usage in an autoconf/automake driven project, specifically NUT: as I worked on some recent fixes in https://github.com/networkupstools/nut/pull/2781 I found that build/link arguments with -L/some/path (e.g. coming from pkg-config) are not passed on to -R/some/path, -Wl,-rpath,somedir or -Wl,-Rsomedir and so the resulting binary is not really usable without LD_LIBRARY_PATH or crle hacks. Ev 11:41:56 en some tests in the configure script fail because the needed shared objects are in a non-default location like /opt/ooce/lib in OmniOS. 11:42:19 Even some tests in the configure script fail because the needed shared objects are in a non-default location like /opt/ooce/lib in OmniOS. 11:43:23 its always pain when things are not on expected places. 11:43:24 Is there some setting to enable the auto-relinking behavior, without hacking the makefile recipes etc. for the platform 11:43:24 ? 11:44:12 as I've posted in the ticket, Linux and MacOS apparently get this right. Windows (MSYS2) builds also, although it is harder to see without a usable ldd there. 11:45:56 Even NUT itself, if installed into its default /usr/local/ups tree, becomes unusable on OI and OO as stuff in bin/ can not find libs under ../lib/ :\ 11:46:48 configure:41360: /usr/lib/ccache/gcc -o conftest -g -O2 -Wno-reserved-identifier -fdiagnostics-color=always -Wno-unknown-warning-option -std=gnu99 -D_REENTRANT -I/opt/ooce/include - I/opt/ooce/include/libpng16 -I/opt/ooce/include -I/opt/ooce/include/freetype2 -I/opt/ooce/include -I/opt/ooce/include/webp -Werror -Werror=implicit-function-declaration conftest .c -lsocket -lnsl -L/opt/ooce/lib/amd64 -lgd >&5 11:46:48 ld.so.1: conftest: fatal: libgd.so.3: open failed: No such file or directory 11:47:18 the -L and -R are very particular about the usage, if configure has no option to pass in the library path for a component, then the autoconf/configure needs fix 11:47:20 So it finds `-L/opt/ooce/lib/amd64 -lgd` via pkg-config and can link the test, but then can not run it :\ 11:48:06 ah, but thats another case, why that pkg-config does not provide -R? 11:49:02 pkg-config just returns whatever is put into the .pc file for that component 11:49:04 I mean, thats the purpose of pkg-config, to provide correct values for compile and link 11:49:50 I know I have a few packages where I have to add the correct -R entries into the installed .pc file 11:50:11 yep 11:51:05 well... is it a distro problem then? they should monkey-fix all pkgconfig files coming through when packaging? 11:51:24 `grep '\-R' /opt/ooce/lib/{*/,}pkgconfig/*` shows zero hits 11:51:36 with -L quite a few (so the regex does work) 11:51:41 pkgconfig files content is definitely the distro problem 11:52:09 pwd 11:52:16 oops... 11:52:31 in a sense that if you do provide .pc file, it better be usable and correct. 11:52:37 but typically there is some .pc.in template into which prefix, libdir, etc. are passed to be expanded by the build scenario, and that's it 11:53:38 the root cause is still likely with the software itself, usually the configure should substitute the correct paths in .pc file and that means you have to have the correct templates there 11:54:25 Well.. with stuff under `/usr/lib` the situation is better, there's a dozen hits :} 11:54:59 Across 1170 files I see in OI and 238 in OO 11:57:32 it is less of the issue with system paths, but it still would be nice to go directly for /usr/lib (and skip /lib) if the library is installed in /usr/lib 11:57:50 Default Library Path (ELF): /lib:/usr/lib (system default) 11:59:02 yup, at least those locations are easy to auto-find... 12:19:06 Curiously, at least on OI the `make package` (makes an SVR4 old one) somehow does the right thing and at least NUT bins are linked to NUT libs: 12:19:06 root@nutci-oi-testzone-nodev:~# ldd /usr/local/ups/bin/nut-scanner 12:19:06 libnutscan.so.2 => /usr/local/ups/lib/libnutscan.so.2 12:19:06 libltdl.so.7 => /usr/lib/64/libltdl.so.7 12:19:06 ... 12:36:08 Interesting, probably pkgadd/pkgrm do some magic here. If I `pkgtrans NUTx.local /tmp/x` and `ldd /tmp/x/NUTx/reloc/bin/nut-scanner`, I get `libnutscan.so.2 => (file not found)` both when the package is not installed and when I manually `cp -prf /tmp/x/NUTx/reloc/./ /usr/local/ups/`; however it begins resolving (for the same `/tmp/x/NUTx/reloc/bin/nut-scanner`) when I `pkgadd -d NUTx.local` 12:44:36 You can use `elfdump -d` or `dump -Lv` to query a shared object and see where it will look (ie, RPATH or RUNPATH) 12:45:36 But the actual name it's looking for might be a symlink, which will only be created when the package is installed 13:02:45 Good point, /usr/local/ups/lib/libnutscan.so.2 symlink was it (also when made manually with package removed) 13:07:23 And yes, the R(UN)PATH does get built in there: 13:07:23 # dump -Lv /tmp/x/NUTx/reloc/bin/nut-scanner 13:07:23 ... 13:07:23 .dynamic: 13:07:23 [INDEX] Tag Value 13:07:25 [1] NEEDED libnutscan.so.2 13:07:27 ... 13:07:29 [10] RUNPATH /usr/local/ups/lib:/usr/gcc/13/lib/amd64 13:07:31 [11] RPATH /usr/local/ups/lib:/usr/gcc/13/lib/amd64 13:07:33 ... 13:10:30 Hm, actually this is also what I see on OmniOS too, so the earlier report of it not seeing its own libs was flawed - I only looked at unpacked pkgtrans, without the files and symlinks actually present under /usr/local/ups 13:39:50 Oh wow, /usr/lib/pkgconfig/libcrypto.pc says (redacted): 13:39:50 prefix=/usr 13:39:50 exec_prefix=${prefix} 13:39:50 libdir=${exec_prefix} 13:39:50 ... 13:39:52 Libs: -L${libdir} -lcrypto 13:40:01 so -L/usr :\ 13:42:42 in practice, libssl.so.3 => /lib/64/libssl.so.3 13:44:11 RPATH/RUNPATH in the resulting binary does not reflect that location though, only /usr/gcc/14/lib/amd64 14:01:29 looks like someone started having fun without me! :) 14:15:04 oh, I was looking at the usb bus on my oi laptop. it looks like illumos doesn't support usb webcams perhaps? 14:24:37 You'll need the usbvc driver, I guess. People have had (some) usb webcams working in the past, certainly. 14:28:32 FreeBSD runs the linux drivers for such in userspace so that 1) linux drivers can be used 2) half the linux kernel doesn't have to live in FreeBSD kernel space 14:32:17 I don't need my webcam to work on illumos personally, wouldn't mind it but don't need, I'm working on it for Dragonfly BSD and I'm even reading specs from USB Implementers Forum today. I was hoping perhaps some work could be reused... 14:34:13 my usb webcam shows up on my OI box (from cfgadm) as type usb-miscell, connected, configured, ok. doesn't look like it's actually "hooked up" 14:39:55 so, it's a thing i'm already working on/looking at just for another OS and I was thinking I might be able to reuse what I'm needing to learn for theirs 14:44:47 I'm also looking at Illumos DRI/DRM code because I have two laptops that work with X under Linux and dfly but not in illumos and I really would like X to work on the console (something I do care about a bit) 14:48:59 I think my laptops can be supported with minor patches, other i915 gpus already work but would kinda like to re-port or update our port of the linux DRI/DRM code because it seems to be missing a lot, looks like it was originally ported from linux somewhere around 2008 or 2012. 14:52:06 most of my paid work experience was directly working with hardware, i have a love/hate relationship with hardware and systems level code :) might as well try to use it 14:56:17 the illumos libc mount smells to me like it could in fact be related to work I did at intel on the sample/reference implementation of fast system call (sysenter/sysexit) actually (and is a creative answer that I certainly hadn't considered at the time) 14:58:43 I am certain that Sun and Novell were both recipients of this work. 15:09:14 not trying to necessarily inflate myself, just working on things i know I have been good at in the past :) 15:17:58 from the doc i'm reading usb-video 1.0 came out in 2003 and the illumos (solaris) docs only talk about usb cameras as mass storage devices rather than actual devices for real-time capture of images or video 15:19:12 either way, in a few hours I will know well more than I ever was curious about wrt usb video devices 16:36:23 given our primary and shadow compilers are >= gcc10, are there any strong feelings against using the gcc builtin overflow check functions (at least clang supports them as well, so they're not too gcc-specific) 16:36:27 ? 17:28:22 I would probably avoid spewing built-ins everywhere and look towards adding support for that via the C23 header. 17:28:30 Assuming that's what you're looking for there. 17:29:38 Specifically stdckdint.h probably versus something else. 19:24:07 yeah -- i didn't know c23 added that... but since it does, going the standard route would be much preferable 19:48:48 I'm happy we have enough overflow checks to worry how to phrase them, tbh 20:55:06 true.. i just would prefer to let the compiler do it if it can vs. by hand (which it sounds like with c23 we can do that) 23:31:24 [illumos-gate] 17054 Strix Halo and Krackan amdzen(4D) support -- Robert Mustacchi