Support linux older than glibc2.29

[colaub]

On linux lincimgui.so is built against glibc2.29.

Log from a RHEL8 / Rocky8 which based on glibc2.28 :

/lib64/libm.so.6: version `GLIBC_2.29' not found (required by [...]/bin/Debug/net8.0/runtimes/linux-x64/native/libcimgui.so)

rhel8/rocky8 are long-term distributions, that's why it could be interesting to have another linux version in the nuget package.
Is it an option?

Thank you for considering the question.

Colin.

[zaafar]

that's a https://github.com/cimgui/cimgui question. Please post it there otherwise correct me if I am wrong.

[sonoro1234]

cimgui is not built at all. You choose compiler.

[zaafar]

oh i see, @colaub can you help me figure out which linux version i should use such that I get glibc2.28
ref: https://github.com/ImGuiNET/ImGui.NET-nativebuild/blob/master/.github/workflows/build.yml#L29

[se5a]

This is fairly old but we're running into this issue as well, looks like the current nuget version (of imgui.net) is targeted at glibc 2.38.
I'm currently on linux mint 21.3 which uses glibc 2.35
mint 21.3 (currently latest) is based off Ubuntu 22.04

We've been trying to update our sdl2 and imgui.net 1.88.0 project to sdl3 and imgui,v 1.91.6.1 and it's... not been fun to say the least.

I'd suggest maybe building against glibc 2.31 which appears to be what the steam runtime is using.
Due to steams size it might be worth using them as a sort of standard.

Edit: Ubuntu 20.04 uses glibc 2.31

[se5a]

An extra note: I ended up using docker with the steam sniper runtime SDK to compile cimgui, was pretty easy to do from the command line, I'm assuming it'll be fairly straight forward to automate it.

[SkaveRat]

I'm running into the same issue with ubuntu 22.04, which ships with glibc 2.35.

Is there a way to check which is the latest imgui/imgui.net version that supports this? (I'm not super familiar with .net, so I can't really find the version)

[se5a]

@SkaveRat it's not .net, it's the cimgui library which is C.
you should be able to build the cimgui lib and drop that into your runtime folder.

[SkaveRat]

I'm a bit stuck on replacing the lib.

The docs regarding the nativebuild repo mention the libcimgui.so, but the cimgui repo only compiles a cimgui.so, which also differs in size quite a bit to the libcimgui.so in the nuget package.

How would I replace the .so in the nuget package with my compiled one?

[se5a]

yeah linux is shit with it's lib nomenclature, it has ~3 "standards" of naming, it's dumb, imgui.net should look for all three, in our project just dropping cimgui.so in there along with libcimgui.so seemed to work, I'm not sure if that's just because it checks for cimgui.so before libcimgui.so though.
Don't be afraid to just try stuff and see what works.
The one I compiled ended up 1.6MB.
If you're having issues compiling it, you could try using the steam sniper runtime SDK, it's pretty straight foward, I asked one of our ai overlords and it gave me (mostly) correct instructions on how to do it with docker, except for the build of cimgui within docker itself, for that I just used make.

[SkaveRat]

argh, alright. Of course it works now, after trying it again (I swear it didn't before...). Thanks!

For people stumbling onto this: This is how I fixed it for me:

1. Clone, check out the required version tag and initialize the nativebuild repo. Note: I had to initialize it with git submodule update --init --recursive, as the c repo also has submodules
2. Build the library with ./build-native.sh release
3. Copy the library into the local cached nuget package. This isn't really optimal, as it will break if you ever change or update, but it's good enough[tm] for me: cp cimgui/build/Release/cimgui.so ~/.nuget/packages/imgui.net/[yourversion]/runtimes/linux-x64/native/libcimgui.so

In my case I'm using imgui-godot, so I'm just going to throw that name in here in case anyone else stumbles on this problem

[se5a]

Excellent.

This is why I'm hoping @zaafar will consider using the steam sdk as a defacto standard, it should solve 99% of these issues.

Edit: extra note: if you tried renaming the new one and replacing the old, the project may (probilby) would have overwritten it back again, depending on how you tried running it, which would have caused you to think it'd failed in your first try.