02:10:46 <twobitsahead> 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
02:10:46 <twobitsahead> 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?
02:27:40 <rmustacc> There historically hasn't been a GNU version provided.
02:28:28 <rmustacc> The symlink you performed would not be correct because you symlinked a 64-bit path to a 32-bit library.
02:30:04 <rmustacc> I assume you have software that is trying to use dlopen, etc.?
02:30:11 <rmustacc> On illumos you can find that all in libc.
02:30:49 <rmustacc> 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.
02:31:26 <rmustacc> 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.
02:43:50 <twobitsahead> 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
04:05:18 <rmustacc> 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?
18:04:43 <gitomat> [illumos-gate] 16939 SCM_UCRED lost in transit -- Hans Rosenfeld <rosenfeld⊙gho>
18:12:34 <sommerfeld> 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..)
18:42:28 <dangergrrl> 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?
18:43:35 <dangergrrl> the email shows 4 warnings from lint, no errors
18:44:24 <dangergrrl> is this normal for a@danger-oi:/code/illumos-gate$ time ./usr/src/tools/scripts/nightly illumos.sh
18:45:15 <rmustacc> Can you provide the full mail_msg?
18:45:48 <rmustacc> There are multiple sections in the mail_msg that aren't build failures that can lead to a failure.
18:45:50 <dangergrrl> certainly, do pastebins stll exist?
18:45:57 <rmustacc> Yes?
18:46:21 <dangergrrl> i grabbed wgetpaste from gentoo and none of the ones it uses still work
18:47:44 <danmcd> I like gist myself.  :)
18:47:56 <danmcd> (i.e. gist.github.com)
18:48:00 <dangergrrl> I don't have a www server in the house
18:48:02 <dangergrrl> aha
18:49:55 <dangergrrl> ok, just woke up and i need to paste creds, no passwords on my illumos box
18:53:28 <dangergrrl> 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
18:54:13 <dangergrrl> i can file a bug on that later with oi and maybe even fix it, it's a trivial fix
19:05:31 <dangergrrl> https://gist.github.com/dangergrrl/b1527c74d76144e8860241de4b0efbe4#file-mbox
19:07:20 <sommerfeld> dangergrrl: perhaps https://www.illumos.org/issues/16879
19:07:21 <fenix> → BUG 16879: pkglint fails on openindiana with more unexpected /32 packages (In Progress) | https://code.illumos.org/c/illumos-gate/+/3802
19:07:45 <sommerfeld> been busy with many other things so I haven't pushed to get a fix integrated.
19:08:14 <sommerfeld> (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)
19:09:42 <dangergrrl> so those warnings are a build failure, aha
19:10:25 <sommerfeld> yes.
20:02:33 <dangergrrl> aha, since those are warnings, will i still have built installable packages?
20:07:10 <dangergrrl> I kinda have something I wanted to look at and prefer to be actually running current/master when i do
20:13:27 <dangergrrl> 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
20:14:41 <Toasterson> dangergrrl xaero will need to hand over his PR for OI soon if you want to take it up I can guide you
20:15:04 <Toasterson> More people working on X would be great
20:15:37 <Toasterson> 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 :)
20:16:15 <dangergrrl> this particular issue strongly smells of kernel space to me, gemini agrees not that this means anything since it's only a stupid AI :)
20:16:39 <dangergrrl> but i will file a bug on the emacs issue, it's probably trivial
20:16:49 <Toasterson> well we are using the old DRM code still and have to switch our swrast to gallium which is userland only
20:17:33 <Toasterson> kernel parts are here https://github.com/openindiana/gfx-drm
20:17:49 <Toasterson> and it's the same build system as illumos-gate
20:18:01 <Toasterson> just tiny in comparison
20:19:04 <Toasterson> I can also send you two dtrace scripts from grzemba it looks like the userland code is not sending the next ioctl while initializing.
20:19:16 <dangergrrl> 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
20:19:59 <Toasterson> ah, yeah that's why I switched to VM's :) very easy to shuffle around
20:20:24 <dangergrrl> but now I even have an extra machne to chase some low paying bounties for dragonfly, they look like easy fixes :)
20:21:05 <Toasterson> oh, do you have some info on that bounty program? I would love to see how that is built up.
20:22:00 <dangergrrl> https://www.dragonflybsd.org/docs/developer/Code_Bounties/
20:22:26 <Toasterson> Thanks I'll have a look
20:22:31 <dangergrrl> I'm actually eyeing one for aros too which isn't even unix
20:24:27 <dangergrrl> https://power2people.org/projects/64bit-distro/ like almost $500 to build their stuff 64 bit and pray it doesn't break too bad :)
20:25:11 <Toasterson> 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.
20:27:35 <dangergrrl> I really thought AROS was totally dead (rewrite of AmigaOS) but their bounty program is very longstanding so I know it works for them
20:28:56 <dangergrrl> 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
20:32:01 <sommerfeld> 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.
20:34:00 <Toasterson> ah yeah you will need the oi patches here on openindiana https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/openindiana/illumos-gate/patches
20:35:05 <richlowe> what a mess
20:35:31 <twobitsahead> 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
20:37:33 <twobitsahead> I'll take another look at the LDFLAGS and friends in the Make files
20:38:38 <richlowe> the libdl thing is a red herring, the out of memory thing I don't know.
20:38:48 <richlowe> last I looked at chez, it worked, but it's been years
20:44:51 <Toasterson> 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
20:45:07 <Toasterson> with gcc aswell
20:46:40 <sommerfeld> twobitsahead: I was thinking of LD_LIBRARY_PATH and similar environment variables, possibly set by a script invoked from a Makefile.
20:47:03 <richlowe> sommerfeld: based on the path, I imagine it's a compiler inserted RPATH
20:47:40 <richlowe> I'm trying to find if I wrote anything down last I dealt with chez
20:47:58 <richlowe> I think it was just getting someone to stash the generated OS-specific sources
20:49:30 <twobitsahead> RPATH and RUNPATH both point to /usr/gcc/14/lib/amd64:/lib
20:50:20 <twobitsahead> Isn't everything in /lib 32-bit?
20:51:03 <richlowe> yes
20:51:20 <richlowe> whatever has happened there, it didn't happen correctly.
20:51:35 <richlowe> but the defaults should come in after that and work out
20:51:44 <richlowe> I think even work out despite finding an inappropriate arch object first
20:52:59 <twobitsahead> Can you break that down for me?
20:53:06 <twobitsahead> If you don't mind
20:55:07 <richlowe> 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
20:55:12 <richlowe> so that being wrong shouldn't break anything
20:58:45 <twobitsahead> 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
20:59:18 <twobitsahead> Thanks for breaking it down, I am still coming up to speed with this
21:13:18 <twobitsahead> 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
21:13:19 <twobitsahead> Idris (target application) side and not heard much. Not quite sure where to turn as far as this obstacle
21:14:24 <Toasterson> try serial builds. Concurrency is sometimes an issue
21:22:16 <twobitsahead> running a concurrent build == running a build concurrently in case that wasn't clear from context :]
21:28:31 <dangergrrl> ok, so presumably I shouldn't install illumos-gate packages built from https://illumos.org/docs/developers/build/ on OI and should instead follow this: https://docs.openindiana.org/pdf/dev/building-openindiana.pdf ?
21:55:56 <jclulow> dangergrrl: I think it depends on what you're trying to achieve
21:58:15 <dangergrrl> 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
21:59:30 <dangergrrl> I suspect the x11 versions aren't that different but I can look there first ofc
22:03:02 <dangergrrl> I'm running lightdm on xvncserver which works for me for now
22:07:22 <dangergrrl> jclulow, Toasterson said I would need https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/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
22:12:08 <dangergrrl> 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
22:23:02 <dangergrrl> anyway, since I'm trying to look at an X issue I do need to build oi-userland too so I can start that
22:25:06 <dangergrrl> 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 :)
22:29:49 <dangergrrl> 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
23:01:39 <gitomat> [illumos-gate] 14549 cxgbe is a touch logorrheic -- Patrick Mooney <pmooney⊙pc>
23:04:54 <gitomat> [illumos-gate] 10270 Convert ptree(1) to mandoc -- Jason King <jason.brian.king⊙gc>
23:36:17 <gitomat> [illumos-gate] 17014 i86pc: C-states should be able to tolerate not using mwait -- iximeow <illumos⊙in>