Closed q4a closed 1 year ago
I assume that 32/64 split is because of the libwine-dev conflict? Did anyone file a bug report for that ubuntu package about it?
I'm not sure, that it's because libwine-dev conflict. @kevinwidjaja21 tested workaroud and it didn't help: https://github.com/kevinwidjaja21/wine-nine-standalone/blob/5ae6a612f5c934d46ef9e7cd0c4097fda910dde1/.github/workflows/G9_exp.yml#L44
sudo apt-get -y download libwine-dev:i386
sudo dpkg -i --force-depends libwine-dev**.deb
I made few tests and make sure that problem ERROR: C shared or static library 'dl' not found
is related to libwine-dev
and this commit:
https://github.com/q4a/wine-nine-standalone/commit/1ef247baa6d6cf19f448fccd691815ea494d0f10
sudo apt-get purge -y libwine-dev:i386
sudo apt-get install -y libwine-dev
fixes it. So, I searched and created new bug report about problem with libwine-dev
:
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/2009152
Thanks for the reporting the bug upstream.
That's one bug that is at play here. But there's another, in winegcc itself: it's related to multiarch specific libraries, which is why it fails with the dl
error. If you check the meson logs you'll see that it can't find its wine libs to link to. That's because winegcc tries to be smart and hardcodes some library paths which may be impossible to overwrite. Your workaround works because the files from the "wrong" arch are not present anymore.
For older wine versions, you can work around it with -L
, which is why I added WINE32_LIBDIR here.
I don't recall if there's a workound for the jammy 6.0 version. IIRC the required fix is https://github.com/wine-mirror/wine/commit/0aa335b1060428f5f799c93e3c6dea2bc2dd864a
@dhewg Thanks for pointing to old Wine. Last stable Wine builds fine, so I force pushed better PR.
Unfortunately that's problematic :\
We need to be careful what distro and what wine version we use here, because the releases are built with this CI setup. If we build on 22.04 that likely won't run on e.g. 20.04. And building against the latest wine will break using the binaries on an older wine version.
Which is the reason why we chose the oldest stuff available on CI :)
This makes it work with 22.04 packages: https://github.com/dhewg/wine-nine-standalone/commit/716f13965bf5774405980ed8aafde8d5411332e9
But I'd prefer to get it working on 20.04, but of course each ubuntu versions has its own problems...
@dhewg Ok. I saw, that you fixed building 20.04: https://github.com/dhewg/wine-nine-standalone/commit/36ee99e131c6722c4e95e655dd1ef81ae02aca4d Thanks for explanation and your work. Close this PR and issue https://github.com/iXit/wine-nine-standalone/issues/144 , when you push ci changes to upstream
Yeah, what a pain /o\ No clue why everybody insists on that ubuntu crap... Like that isn't broken enough, but let's break it even more with PPAs! Thanks for your work, but I think the switch to 20.04 is the most user friendly atm!
Here's a working 22.04 setup: https://github.com/dhewg/wine-nine-standalone/commits/22.04
That's not going in for the above mentioned reasons, but in case anyone want's to replicate that on a 22.04 setup.
But I recommend to switch to debian instead :D
Follow-up on CI stuff: I'll switch to winehq v6.0 packages soon for the current CI 20.04 setup. Because building with <v5.7 breaks binary compatibility for v8.3. Building with v6.0 gives us releases that work on >=v5.7.
See #149
Thx for info)
This is working solution for building both x86 and x86_64 on CI. And this is fixes: https://github.com/iXit/wine-nine-standalone/issues/144
I made few tests and got same error as in issue, but separately installing x86 and x86_64 libs works fine. After @dhewg suggestion about old Wine version, I added Wine repo from here and it worked: https://wiki.winehq.org/Ubuntu
Also I decided to keep ubuntu 18.04 build - to proof, that it still works too. Here is CI result from my repo: https://github.com/q4a/wine-nine-standalone/actions/runs/4324400422