Hello, I'm running into an issue with finding GNU libdl.so.1. There is a program trying to call */usr/gcc/10/lib/amd64/libdl.so.1*, except this directory doesn't contain libdl.so.1. I symlinked /usr/gcc/10/lib/amd64 to /lib/libdl.so.1, but this is returning err#48 ENOTSUP. find hasn't found anything under /usr/gcc nor /usr/gnu. It looks like the

repo doesn't contain GNU libdl.so, either, and looking through the contents of various gcc-10 packages isn't returning any libdl.so. Is there a spot which I have missed where GNU libdl.so.1 might be found?

There historically hasn't been a GNU version provided.

The symlink you performed would not be correct because you symlinked a 64-bit path to a 32-bit library.

I assume you have software that is trying to use dlopen, etc.?

On illumos you can find that all in libc.

Becaues it's dependent on the implementation of our run-time link-editor, /usr/lib/ld.so.1, generally you just use the native version.

So I think depending on what this software is, you want it to just use the default search path to find libdl (which will get you to the correct implementation library) or remove the need to link against it.

I am trying to run a build which is using Chez Scheme. A part of the build hangs before returning "out of memory". Running scheme directly on the file returns an error about ld.so.1 open failing, and truss output shows err#2 ENOENT on stat while trying to open /usr/gcc/10/lib/amd64/libdl.so.1

I expect the enoent is probably just because it has a runpath so it's searching for that in the needed section and may be a red herring?

[illumos-gate] 16939 SCM_UCRED lost in transit -- Hans Rosenfeld <rosenfeld⊙gho>

twobitsahead left but: I suspect that runtime linker paths needed to be tweaked when running the binary - some LD_* environment variable is set during the build that isn't present when you run it from the shell. Also wouldn't be surprised if the out of memory were "real" and would go away if more swap were added (we don't do memory overcommit, other systems will let you allocate a lot of vm space if you never touch it all..)

mail says "nightly build failed" but no actual error in the mail... and night;y.log has no occurence of "***" so there's no make error?

the email shows 4 warnings from lint, no errors

is this normal for a@danger-oi:/code/illumos-gate$ time ./usr/src/tools/scripts/nightly illumos.sh

Can you provide the full mail_msg?

There are multiple sections in the mail_msg that aren't build failures that can lead to a failure.

certainly, do pastebins stll exist?

Yes?

i grabbed wgetpaste from gentoo and none of the ones it uses still work

I like gist myself. :)

(i.e. gist.github.com)

I don't have a www server in the house

aha

ok, just woke up and i need to paste creds, no passwords on my illumos box

oh and it looks like i found a minor problem with this oi emacs build, the movemail tool from emacs may need root? it doesn't work for M-x rmail so i have used mailx

i can file a bug on that later with oi and maybe even fix it, it's a trivial fix

dangergrrl: perhaps illumos.org/issues/16879

→ BUG 16879: pkglint fails on openindiana with more unexpected /32 packages (In Progress) | code.illumos.org/c/illumos-gate/+/3802

been busy with many other things so I haven't pushed to get a fix integrated.

(there are multiple ways to fix it; I went for a "just fix it once and for all" but Marcel didn't like my approach)

so those warnings are a build failure, aha

yes.

aha, since those are warnings, will i still have built installable packages?

I kinda have something I wanted to look at and prefer to be actually running current/master when i do

I'm really wanting to look at the intel drm code, X works fine on the console on my other dual gpu laptop with not only linux but also dragonfly bsd, the problem seems surely in the kernel drm code or the interface to it

dangergrrl xaero will need to hand over his PR for OI soon if you want to take it up I can guide you

More people working on X would be great

Also please file a bug for that emacs behaviour wacki is a emacs user too so then he has a packge to work on he likes :)

this particular issue strongly smells of kernel space to me, gemini agrees not that this means anything since it's only a stupid AI :)

but i will file a bug on the emacs issue, it's probably trivial

well we are using the old DRM code still and have to switch our swrast to gallium which is userland only

kernel parts are here github.com/openindiana/gfx-drm

and it's the same build system as illumos-gate

just tiny in comparison

I can also send you two dtrace scripts from grzemba it looks like the userland code is not sending the next ioctl while initializing.

I will certainly dive into it and finish the lex thing i accepted forever ago too, I had hardware failures and had to shuffle OS stuff around to support work for a paying client

ah, yeah that's why I switched to VM's :) very easy to shuffle around

but now I even have an extra machne to chase some low paying bounties for dragonfly, they look like easy fixes :)

oh, do you have some info on that bounty program? I would love to see how that is built up.

Thanks I'll have a look

I'm actually eyeing one for aros too which isn't even unix

power2people.org/projects/64bit-distro like almost $500 to build their stuff 64 bit and pray it doesn't break too bad :)

I was playing with the though of organizing payed work for code before and some people had interest. So looking at the organisation of other projects helps finding a good org structure for that.

I really thought AROS was totally dead (rewrite of AmigaOS) but their bounty program is very longstanding so I know it works for them

Toasterson, there exist broke hackers, I'm tryng bounty stuff for extra cash, spouse has been off work since august and things are more than tight

dangergrrl: sorry was away for a bit. packages are installable - the warning is just about unexpected package dependencies as the core illumos-gate is not expecting the /32 packages.

ah yeah you will need the oi patches here on openindiana github.com/OpenIndiana/oi-userland/…ts/openindiana/illumos-gate/patches

what a mess

sommerfeld Hello, just came across your message from 13:12:34. The build is somewhat simple, and I don't believe that the LDFLAGS had more than a couple of arguments. By running the build with Make, or running it on the trouble file with scheme directly, it is returning the same 'out of memory' issue. I'll try allocating more swap space

I'll take another look at the LDFLAGS and friends in the Make files

the libdl thing is a red herring, the out of memory thing I don't know.

last I looked at chez, it worked, but it's been years

also e careful about /tmp Our OI CI has run multiple times into out of memory issues when rust was compiling due to the many temp objects. With 256GB RAM

with gcc aswell

twobitsahead: I was thinking of LD_LIBRARY_PATH and similar environment variables, possibly set by a script invoked from a Makefile.

sommerfeld: based on the path, I imagine it's a compiler inserted RPATH

I'm trying to find if I wrote anything down last I dealt with chez

I think it was just getting someone to stash the generated OS-specific sources

RPATH and RUNPATH both point to /usr/gcc/14/lib/amd64:/lib

Isn't everything in /lib 32-bit?

yes

whatever has happened there, it didn't happen correctly.

but the defaults should come in after that and work out

I think even work out despite finding an inappropriate arch object first

Can you break that down for me?

If you don't mind

so that runpath is wrong, it should be /lib/amd64 if anything at all, like you said. But the default runtime linker search paths are correct, and will be searched after those. I think that if the linker finds an object it can't use (like in this case any of those 32bit ones) it will keep looking for one it can, and find the ones on the default run path

so that being wrong shouldn't break anything

ldd FILE.so shows libcso.1 => /lib/64/libc.so.1 \ libm.so.2 => /lib/64/libm.so.2 so I think this suffices to explain how this is linking up? Being the default search path

Thanks for breaking it down, I am still coming up to speed with this

Also, the build failed with 'out of memory' after increasing the swap +12G. Running a concurrent build on Linux using Chez 9.5.4 passed. OI is running Chez 9.5.2. Is there a place where I should be looking, or an illumos tool which I've overlooked which might provide further insight into the issue? I've reached out on the Chez side, as well as the

Idris (target application) side and not heard much. Not quite sure where to turn as far as this obstacle

try serial builds. Concurrency is sometimes an issue

running a concurrent build == running a build concurrently in case that wasn't clear from context :]

ok, so presumably I shouldn't install illumos-gate packages built from illumos.org/docs/developers/build on OI and should instead follow this: docs.openindiana.org/pdf/dev/building-openindiana.pdf ?

dangergrrl: I think it depends on what you're trying to achieve

jclulow, I'm trying to look at the dual gpu laptop issue, I have strong suspicion it's the kernel DRM code or the interface with it since both dragonfly bsd and linux start x fine on my laptops and the userspace code should be nearly identical

I suspect the x11 versions aren't that different but I can look there first ofc

I'm running lightdm on xvncserver which works for me for now

jclulow, Toasterson said I would need github.com/OpenIndiana/oi-userland/…ts/openindiana/illumos-gate/patches <-- those patches but those are part of the latter build procedure and I suppose I need to pull the X11 stuff from oi-userland to look at this even if it is a kernel space issue, so I really need to rebuild that from master too

any spare hardware I have is likely to be "gaming laptop", other than the GPU not really being needed they typically have fast CPUs and high ram. I'm a gamer, if i buy a new machine it will probably be for gaming and I'll upcycle an older one to be a new dev host

anyway, since I'm trying to look at an X issue I do need to build oi-userland too so I can start that

I need to read the DTrace docs myself anyway, I've been lazy and just asking gemini so what I do know is probably wrong :)

I worked with really old system v sources at Intel, Tandem, and SCO but that was decades ago. I actually found out yesterday that Xinuos is actually selling really old unixware and openserver for very high prices - found their www while looking up some really old kernel locking stuff

[illumos-gate] 14549 cxgbe is a touch logorrheic -- Patrick Mooney <pmooney⊙pc>

[illumos-gate] 10270 Convert ptree(1) to mandoc -- Jason King <jason.brian.king⊙gc>

[illumos-gate] 17014 i86pc: C-states should be able to tolerate not using mwait -- iximeow <illumos⊙in>