https://bugs.winehq.org/show_bug.cgi?id=54635
Bug ID: 54635 Summary: libwine backward compatibility Product: Wine Version: 8.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winecrt0 Assignee: wine-bugs@winehq.org Reporter: a.heider@gmail.com Distribution: ---
v8.3 finally removed libwine. Older winegcc builds automatically link against it (just __wine_dll_register@WINE_1.0 in out case). Newer winegcc builds don't link against it anymore, it looks like since f6a363bc4108f3d45b7a5bac706d10579f4d2772 "winecrt0: Get rid of constructor support." v5.7.
We build downloadable releases and would like to keep maximum binary compatibility.
Building with >=v5.7 would likely avoid the issue, but I guess binaries won't work on older WINE versions then.
For the record: Ubuntu 18.04 LTS is about to go unsupported, 20.04 LTS ships v5.0. Our current CI setup uses 20.04, so v5.0, to build releases.
Is there something we can do to make built binaries work on >=v5.0? Any suggestions how to archive that? Something on our end? Or maybe WINE can get a compatibility addition to skip the libwine.so.1/__wine_dll_register@WINE_1.0 symbol or something?
Thanks! Andre
https://bugs.winehq.org/show_bug.cgi?id=54635
Elvis Angelaccio elvis.angelaccio@kde.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |elvis.angelaccio@kde.org
https://bugs.winehq.org/show_bug.cgi?id=54635
--- Comment #1 from Andre Heider a.heider@gmail.com --- I tested a few combinations, and v5.7 indeed is the release that changed how libwine dlls are loaded and registered.
Binaries built with <v5.17 still worked up to v8.2, but the v8.3 libwine removal breaks binary compatibility.
I couldn't find a way to make binaries build with v5.0 work on v8.3. Nor binaries build with v6.0 on <v5.7.
So my current conclusion is: Building with <v5.7 works up to v8.2. Building with >v5.7 works with v8.3 but breaks <v5.7.
As always there're no reasons in any commit messages, but was that incompatibility planned and expected? Will that change in the future?
Thanks, Andre
https://bugs.winehq.org/show_bug.cgi?id=54635
--- Comment #2 from Alexandre Julliard julliard@winehq.org --- The change was necessary because of the new PE/Unix architecture. The planned incompatibility was explained in the stable release notes, in particular the ones for 6.0.
What is your app? How is it packaged and distributed? Is it downloadable somewhere?
https://bugs.winehq.org/show_bug.cgi?id=54635
--- Comment #3 from Andre Heider a.heider@gmail.com --- It's the Gallium Nine standalone release. I just pushed the v0.9 release, which was built with WINE v6.0 to make it work with >=v8.3: https://github.com/iXit/wine-nine-standalone/releases/tag/v0.9 But of course that breaks it on <v5.7, which I tried to avoid.
But our v0.8 release suffers from the effects described here.
FWIW, one of the things I tried is adding this locally: /* Building with WINE<v5.7 automatically links against winecrt, which adds a dependency on * libwine/__wine_dll_register@@WINE_1.0. * Add our own function of the same name, which prevents that dependency. This makes a * release work on WINE >=v8.3, which removed libwine altogether. * To keep a releases working with older WINE versions, register ourself if libwine exists. */ void DECLSPEC_HIDDEN __wine_dll_register(const IMAGE_NT_HEADERS *header, const char *filename) { void *h; void (*f)(const IMAGE_NT_HEADERS *header, const char *filename);
h = dlopen("libwine.so.1", RTLD_NOW | RTLD_GLOBAL);
if (!h) { ERR("no libwine handle for backwards compatibility\n"); return; }
f = dlvsym(h, "__wine_dll_register", "WINE_1.0");
if (!f) { ERR("no libwine __wine_dll_register function for backwards compatibility\n"); } else { ERR("registering DLL for WINE backwards compatibility\n"); f(header, filename); }
dlclose(h); }
And that indeed hacks around that one issue, there's no dependency on libwine anymore when building with e.g. WINE v5.0.
But then I ran into the next problem: __wine_spec_nt_header is not global and probably needs to be added to .dynsym. I stopped there, I'm not sure if there're more issues even when solving that one.
https://bugs.winehq.org/show_bug.cgi?id=54635
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=54635
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- (In reply to Alexandre Julliard from comment #2)
The change was necessary because of the new PE/Unix architecture. The planned incompatibility was explained in the stable release notes, in particular the ones for 6.0.
The 6.0 release notes mention that libwine was being deprecated and removed, but it doesn't mention why, and I've been increasingly wondering that. Why couldn't libwine have stayed as a unix-side library?
https://bugs.winehq.org/show_bug.cgi?id=54635
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- (In reply to Zeb Figura from comment #4)
(In reply to Alexandre Julliard from comment #2)
The change was necessary because of the new PE/Unix architecture. The planned incompatibility was explained in the stable release notes, in particular the ones for 6.0.
The 6.0 release notes mention that libwine was being deprecated and removed, but it doesn't mention why, and I've been increasingly wondering that. Why couldn't libwine have stayed as a unix-side library?
It's all dead code, and there's a non-zero cost to keeping it around. It also constrains what is possible to change in the loader because it requires constructors to be executed on load.
https://bugs.winehq.org/show_bug.cgi?id=54635
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- (In reply to Alexandre Julliard from comment #5)
(In reply to Zeb Figura from comment #4)
(In reply to Alexandre Julliard from comment #2)
The change was necessary because of the new PE/Unix architecture. The planned incompatibility was explained in the stable release notes, in particular the ones for 6.0.
The 6.0 release notes mention that libwine was being deprecated and removed, but it doesn't mention why, and I've been increasingly wondering that. Why couldn't libwine have stayed as a unix-side library?
It's all dead code, and there's a non-zero cost to keeping it around. It also constrains what is possible to change in the loader because it requires constructors to be executed on load.
Thanks, that makes sense. I was figuring that most of it could be kept working on the unix side (rather than moving all of that to ntdll), but I didn't consider the entry point interface.
-
WineHQ Bugzilla