[illumos-gate] 17061 want a more cautious wrmsr -- Luqman Aden <luqman⊙oc>

[illumos-gate] 17105 unix: dboot should be built with NO_SIMD -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 17099 ehci: address of NULL pointer -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 17100 cmlb: unsigned 'capacity' is never less than zero -- Toomas Soome <tsoome⊙mc>

.oO Make only the text component of messages appear (remove this in SVR4.1)

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 networkupstools/nut #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

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.

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.

its always pain when things are not on expected places.

Is there some setting to enable the auto-relinking behavior, without hacking the makefile recipes etc. for the platform

?

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.

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/ :\

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

ld.so.1: conftest: fatal: libgd.so.3: open failed: No such file or directory

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

So it finds `-L/opt/ooce/lib/amd64 -lgd` via pkg-config and can link the test, but then can not run it :\

ah, but thats another case, why that pkg-config does not provide -R?

pkg-config just returns whatever is put into the .pc file for that component

I mean, thats the purpose of pkg-config, to provide correct values for compile and link

I know I have a few packages where I have to add the correct -R entries into the installed .pc file

yep

well... is it a distro problem then? they should monkey-fix all pkgconfig files coming through when packaging?

`grep '\-R' /opt/ooce/lib/{*/,}pkgconfig/*` shows zero hits

with -L quite a few (so the regex does work)

pkgconfig files content is definitely the distro problem

pwd

oops...

in a sense that if you do provide .pc file, it better be usable and correct.

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

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

Well.. with stuff under `/usr/lib` the situation is better, there's a dozen hits :}

Across 1170 files I see in OI and 238 in OO

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

Default Library Path (ELF): /lib:/usr/lib (system default)

yup, at least those locations are easy to auto-find...

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:

root@nutci-oi-testzone-nodev:~# ldd /usr/local/ups/bin/nut-scanner

libnutscan.so.2 => /usr/local/ups/lib/libnutscan.so.2

libltdl.so.7 => /usr/lib/64/libltdl.so.7

...

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`

You can use `elfdump -d` or `dump -Lv` to query a shared object and see where it will look (ie, RPATH or RUNPATH)

But the actual name it's looking for might be a symlink, which will only be created when the package is installed

Good point, /usr/local/ups/lib/libnutscan.so.2 symlink was it (also when made manually with package removed)

And yes, the R(UN)PATH does get built in there:

# dump -Lv /tmp/x/NUTx/reloc/bin/nut-scanner

...

.dynamic:

[INDEX] Tag Value

[1] NEEDED libnutscan.so.2

...

[10] RUNPATH /usr/local/ups/lib:/usr/gcc/13/lib/amd64

[11] RPATH /usr/local/ups/lib:/usr/gcc/13/lib/amd64

...

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

Oh wow, /usr/lib/pkgconfig/libcrypto.pc says (redacted):

prefix=/usr

exec_prefix=${prefix}

libdir=${exec_prefix}

...

Libs: -L${libdir} -lcrypto

so -L/usr :\

in practice, libssl.so.3 => /lib/64/libssl.so.3

RPATH/RUNPATH in the resulting binary does not reflect that location though, only /usr/gcc/14/lib/amd64

looks like someone started having fun without me! :)

oh, I was looking at the usb bus on my oi laptop. it looks like illumos doesn't support usb webcams perhaps?

You'll need the usbvc driver, I guess. People have had (some) usb webcams working in the past, certainly.

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

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...

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"

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

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)

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.

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

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)

I am certain that Sun and Novell were both recipients of this work.

not trying to necessarily inflate myself, just working on things i know I have been good at in the past :)

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

either way, in a few hours I will know well more than I ever was curious about wrt usb video devices

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)

?

I would probably avoid spewing built-ins everywhere and look towards adding support for that via the C23 header.

Assuming that's what you're looking for there.

Specifically stdckdint.h probably versus something else.

yeah -- i didn't know c23 added that... but since it does, going the standard route would be much preferable

I'm happy we have enough overflow checks to worry how to phrase them, tbh

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)

[illumos-gate] 17054 Strix Halo and Krackan amdzen(4D) support -- Robert Mustacchi <rm⊙fo>