Hello? Is there a plague of silence here?

hi, everyone! I wish you a merry Happy Christmas! :-)

I am attempting to port something to illumos (OpenIndiana) and having some trouble. The application depends on gcc13-libs-13.3.0. GCC 13 and its libraries are installed, yet there is still a warning about an unmet dependency on GCC 13

I'm not especially familiar with porting nor porting to illumos. I have reached out to the developers of the application and have been directed to try to see if I can sort it out

Would someone kindly give me a nudge as to which direction I should go in as far as troubleshooting at this point?

twobitsahead: usually you should specify an additional run-path to the target binary, if I correctly understood your "trouble"

The application is GHC. Per the GHC website, the package for GHC 7.2.2(?) should be available via the sfe repository. It appears as though it's not available anymore. I saw that GHC 9.8.2 is available on pkgin, so I used the bootstrap script from SmartOS to install pkgin on OI. Upon attempting to install GHC 9.8.2 via pkgin, a warning is produced

which reads '... the following packages have unmet requirements: gcc13-libs-13.3.0'. After installing GHC anyways, I attempted to run it and it immediately throws an error reading 'ghc-9.8.2: internal error: timerfd_create: No such file or directory'. Immediately after this message is one which directs me to report it as a bug on the GHC site,

which I already tried to do (and was directed to try changing the path or libraries)

denk Is the additional run-path still applicable in this situation?

see output of ldd ghc as first step

does it contain the libraries?

twobitsahead: I meant you compile something using gcc

No. 'ldd ghc' returns 'unsupported or unknown file type'

full path to the ghc binary

find a correct binary of ghc-9.8.2 which produces the internal error

denk It seems like compiling GHC via GCC isn't an option as it's a self hosted compiler

if ghc is a staticaly linked it does not need any external libraries

The full path to the ghc binary is /opt/local/bin (created via and for pkgin)

inspect the building processif you cannot find the file and try to use LD_LIBRARY_PATH env variable to specify a path to the gcc13 libraries

sorry, I have to go now, maybe next time...

Thank you for some direction. I'll keep looking around

I highly recommend to not mix OI with packages from SFE as long as you are inexperienced.

You shouldn't mix the package systems without real necessity. I also recommend to not use pkgin or others. Start using the official build system we have.

Mixing different build systems is IMO generally a bad idea.

Start here: docs.openindiana.org/dev/userland

Our default gcc version is 14 at the moment btw.

Thank you for the heads up

the timerfd_create error seems a bit strange -- that exists in libc

and has been there for a while (2004)

I had wanted to try to (attempt to) port the latest version of GHC to OI. The pages on the GHC porting page mentioned that it is possible on both OI and other distros. The first mention of using the SFE repository is on their site. I checked for packages on the SFE and did not find any as their docs had suggested

I am aware that, supposedly, OpenSolaris had a port of GHC. I haven't come across it as of yet

Pkgin has the only GHC package I have found that I can get onto OI

my read of that error message is that it's calling timerfd_create and getting an EEXIST somewhere along the way

so twobitsahead in your shoes i'd be curious what truss says is happening in the program that's printing that (does the call to timerfd_create look reasonable?)

OI has its own build system (originating from OpenSolaris). It's similar to what is being used for Solaris 11.

the text ('No such file or directory') is basically strerror(ENOENT)

oh ENOENT, right, sorry

the only thing I could think of is if it's trying to maybe use dlsym() on the wrong library??

If you don't use it you will sooner or later suffer from the consequences. Porting something to OI is twofold: 1. porting to illumos (that is, it's libc and and supporting libraries and tools) and 2. porting to OI's build system.

iximeow I'm not experienced enough to understand the output to determine if it looks reasonable. If you wouldn't mind, I could create a pastebin with the output and share it

Different illumos distribuitions have different build systems; some use IPS for package management (eg. OI and OmniOS), some use others.

Also, I should mention that the version of GHC that is broken is *not* the version I am trying to compile. The compiler is self-hosted and this older version should be used for compiling the latest version from source

twobitsahead: wouldn't hurt, but i probably won't be able to help very much either. just thinking through some debugging steps out loud

(good chance you're more familiar with packaging and porting than me :) )

I reached out to the GHC devs on IRC and I was basically told to look at the paths and libraries. (the errors actually mention contacting their devs in regards to a bug fix)

If GHC needs itself to build you'll need to find a way to bootstrap it if you don't find an already working version of it for illumos. I haven't seen anything GHC related in illumos yet.

I don't recommend starting with such a big project; you should start with something simpler to get used to the libs and tools OI (or any other illumos based distro).

I had hoped to use the pkgin ghc-9.8.2 to bootstrap the newer version. This seem(ed) like it would come down to making the ghc-9.8.2 aware of the gcc-13 libs

I'm just spitballing ideas now, but maybe it's possible that pkgin is set up for SmartOS? And I should try bootstrapping on there first? (Thinking this, since I used the script on OI, after all)

I should probably take your advice and start with a smaller project

I suspect you ought to be able to use the pkgsrc GHC, FWIW

I would imagine, though, that it's built against the GCC 13 libraries that come from pkgsrc though, so you might need to install those with pkgin

I don't really know anything about Haskell though

yeah that's why i was wondering about truss, because i don't think timerfd_create should even be able to return ENOENT so something seems weird there

and tbh if timerfd_create *is* returning ENOENT that's a smaller project: updating docs :)

It really shouldn't under normal conditions

But: if it is, it's probably because /dev/timerfd doesn't exist

timerfd_create() isn't a system call, it just opens a character device that implements the emulation

If that device node doesn't exist though it feels like something else has previously gone pretty wrong

ooooh

There should be a symlink: /dev/timerfd -> ../devices/pseudo/timerfd@0:timerfd

And then /devices/pseudo/timerfd@0:timerfd should be made available when you try to open it etc

/usr/kernel/drv/amd64/timerfd is in one of the base packages though with other kernel bits so it's not like it won't have been installed

Ok, gcc13-13.3.0 is in pkgin. Attempting to install the package gives a couple of dependency warnings;

1.   /usr/lib/amd64/libstdc++.so.6, needed by gcc13-13.3.0 is not present in this system.

2. /usr/lib/amd64/libgcc_s.so.1, needed by gcc13-13.3.0 is not present in this system.

If you "pkg search :path:/usr/lib/amd64/libgcc_s.so.1" it should hopefully list some packages that include that base OS file

(I don't have an OI machine myself)

OI has several gcc versions. Their libs reside in /usr/gcc/<version>/lib

Yes but there should be some base package delivering at least /usr/lib/amd64/libgcc_s.so.1

Two results, library/gcc-12-compat-links⊙14 and library/gcc-10-compat-links⊙15

Maybe give gcc-12-compat-links a go?

I have introduced the compat-links in the past.

FWIW, /usr/lib/amd64/libgcc_s.so.1 is not really a "compat" thing

It's something the base OS should include

It led to problems in the past. We have several gcc versions; which one should have its libs in /usr/lib and why?

libgcc_s.so.1 has not lead to problems that anybody has ever been able to demonstrate to me. It's different from the C++ runtime, and is stable and backwards compatible. Just link in the latest one that's installed, using a mediator or whatever

Or link in the one that illumos is currently being built with (e.g., 10, soon 14, etc)

Either way

It's fine to deliver the versioned artefacts under /usr/gcc/$version as well, the system really ought to provide the stable ones in the default rpath is all

Yes, somebody should provide a solution we can test and discuss.

Where should libstdc++.so.* be?

That one I'm less sure about, because it has indeed presented compat issues in the past

I'm somewhat surprised that the gcc13-13.3.0 package depends on it though, to be honest, for that reason

So I would probably try and get pkgin to ignore the issue

and see what happens

Ok, I tried to install gcc13-13.3.0 via pkgin. I jimmied the libgcc_s.so dependency, and pkgin is only complaining about the libstdc++.so dependency

I attempted to proceed with the installation, ignoring that dependency on libstdc++.so, but the pkgin install command is immediately returning *without* installing gcc13-13.3.0, even after acknowledging the missing dependency

Oddly enough, I managed to install GHC with its missing dependencies successfully. I'm not sure why pkgin isn't returning any errors but simply returning with no output. A cursory Google search isn't helping. I suppose I should inquire about this in the pkgin channels

Found libstdc++.so.6 and placed it in the place where pkgin was looking for it. Pkgin installed gcc13-13.3.0 successfully