Provided binaries don't work on Arch Linux anymore #3824
Comments
|
I tried to build it manually, which failed for, I think, a different reason: Build Log |
|
I think the build error was fixed in revery here: revery-ui/revery#1033 |
|
I upgraded revery in the resolutions of the package.json to 14402ad200a6c659afa67315b7fe36cdb1c5ef3c but it still fails with the same errors. |
|
Can you try this branch https://github.com/revery-ui/esy-skia/tree/fix-oni2-3824 |
|
Just tried only with overriding esy-skia like this: Which still failed, now I try overriding revery and esy-skia like this: |
|
Same, I think I have to go into esy_libjpeg_turbo and have to fix it there too. I'll try that. |
|
So I still get this: DetailsI cloned https://github.com/revery-ui/libjpeg-turbo/ now and try to find the file |
|
Is it possible this error comes from code generation and I would need to understand skia or libjpeg to figure out where the error comes from in the source? |
|
Oh, the error is actually different, before it was complaining about it overriding the other thing without being marked as such, now it complains about overriding the other thing but not overriding member functions... |
|
I didn't see a way to fix this now without learning C++ and rewriting parts of skia 😄 So I forked esy-skia removed |
|
Actually disregard everything I said so far (except the binaries not working). I wasn't on the current master, my local oni repo was probably out of date for a couple of months... With current master everything works actually. So I guess we just need to recreate the binaries in CI with a newer glibc version installed? |
|
I'll try the docker build instructions to see if they produce broken binaries on my arch system. If so, I'll try to use a more recent version of centos and see if that fixes it. |
I have done a monkey patch but not compiled myself mb. I expected the change to be small and pass directly. But this seem like a clang bug because now he want to remove it. Clang13 is around the corner so it might be fixed. For another CI build maybe ask @zbaylin why do you need the docker build building directly on your arch doesn't work ? |
It does, I want to check though if building it on centos and running it on Arch works. My goal is to be able to run the nightlies on Arch again. |
|
Yeah, using the docker build process still creates a binary having this error: I'll check if upgrading to centos 8 helps. |
|
Ok, no idea how to do that, Would it be easier to take a newer ubuntu and compile on that one? What was the reason for choosing centos? |
Believe it or not, there are still quite a few people stuck using CentOS 7. Some of us like to to be able to use OniVim on such systems. I believe that the thought is that picking the oldest supported RedHat release provides a good base to cover pretty much any other distro. |
I guess we can have our cake and eat it too, just need to run 2 Linux pipelines, right? |
|
Currently when trying to compile oni in a docker container with ubuntu 20.04 I get a lot of those Anybody knows what that means? |
|
Nevermind that, I was sharing the build cache of my system with the docker image and that caused the issue. |
|
out of subject:
I compiled with apple clang 12 no warning and with clang quite recent (compiled from main a month ago) I can reproduce the warning. I have also removed flags: So I don't know how arch linux package clang 🤷 |
I'll check that out today. |
|
@Et7f3 yeah so basically what I said there is correct: Everything I said about the errors related to esy-skia and clang was wrong. I just didn't Sorry about the confusion. What remains though is that the binaries generated on CentOS do not work on Arch Linux at the moment. |
|
Can you grep g_module_open_full in .esy to detect which dependencies require this symbol (and need to be updated) |
|
I'll let you know when it finds something, has been running for 20 minutes now 😄 |
|
I tried |
|
If you don't find something it means a dependencies on host library so you might also look in /lib* /usr/lib* /usr/local/lib* ... |
|
Ah I have other idea in man ld.so I see LD_DEBUG try to export as libs and run your binary. 🤦🏻libgio require this symbol and it is absent of your machine hence the error. You can cancel. |
|
https://forum.manjaro.org/t/vscodium-appimage-wont-launch-symbol-lookup-error-libgio/84462/3 Seem to be glibc issue 😬 |
Yeah, that was my first thought since this happens from time to time with arch.
Having 2 binaries, one for old linux systems and one for newer systems, would solve this, right? |
Should I still do that? If yes, what exactly should I do? I feel a bit lost with the instructions 😬 |
|
I'm currently having the same error, also on arch. Here's the output with |
|
Sorry if it was unclear (it was late in my timezone). so you tried to build with docker centos7
in dockerfile I see hardcoded version oni2/scripts/docker/centos/Dockerfile Line 20 in fda6bf7 what I was trying to test with LD_DEBUG allow to identify wich lib require this symbol. If we identify this lib we can try to vendor a more up to date version. Here is a tuto http://www.bnikolic.co.uk/blog/linux-ld-debug.html if we don't manage to vendor it then craft a new dockerfile can help. thanks @DJNighswander |
|
@DJNighswander I don't see which lib import g_module_open_full can you try other option of LD_DEBUG ? |
|
@Et7f3 does this help? |
|
I don't think it actually does help, because it points to |
|
Can you send the full log because here we only see where this symbol is searched not which originate this research |
|
Ok I read the logs: I read ld is searching stderr that is undefined in libc and found inside Onivim2-x86_64-master.AppImage And here we seek strlen for libz and we have found it in libc. when we see the undefined symbol we see this line before So for me it is a internal relocation (wtf I though it did at link time for inter so symbol) From here I see these solutions:
|
|
Given your solutions, I think I can only help with the last one. I don't think I understand enough about native development to help with the other two. 😞 |
|
I'm currently trying to create a docker build based on ubuntu 20.04, but I hit some compilation errors: Build Log |
|
You miss this dependencies |
|
Hi. |
|
@despairblue Hey! What the problem could be here: it seems that glib version >= 2.70 gives an error and doesn't work on Arch based systems, so this is what i did to make it work by using the glib version 2.68.4 (the version with which Onivim2 still worked). Solution: Patch glib2 version 2.68.4 into Onivim2 AppImage and the method is what I followed -
|
That works too. I found the solution in the Arch forum, but didn't try it. Since I worked a bit on Oni I know how to compile it, so recompiling it on my system was easier for me 🤷🏾 I'd like to find the time to create a docker based build on a newer ubuntu version that produces a binary that also works on arch. |
|
Is OniVim2 still going on? |
|
Is this issue still ongoing? I have a separate AppImage/AUR package that refuses to run for the exact same reason as this one and I don't want to spend a lot of time fixing it. I'm not a regular Arch Linux user anymore (for now, until I get my Steam Deck). |
|
I've already spent entirely too much time on what should have just been a naming convention fix. |
|
@AutoUpdatingBSoD You can download onivim2-bin from the AUR or manually download the AppImage from this repo. |
|
@santilococo I'm sorry I wasn't clear. I meant an AUR package/PKGBUILD I was developing/maintaining which has the exact same issue as this. But it doesn't matter, I've relinquished control of it to someone with more experience and time. So it won't matter anymore anyway. Thanks for the feedback though, and I'm sorry I didn't get back to you! Past couple of months have been hectic and GitHub wasn't even on my radar. |
ghost
mentioned this issue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm getting this when I start it:
I supposed glib2 has been upgraded and is not not compatible anymore.
The text was updated successfully, but these errors were encountered: