[Bug 53918] New: Building with external PE libraries fails when static libraries are also installed
https://bugs.winehq.org/show_bug.cgi?id=53918 Bug ID: 53918 Summary: Building with external PE libraries fails when static libraries are also installed Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs(a)winehq.org Reporter: z.figura12(a)gmail.com Regression SHA1: 6a912649188a765d0c58e8b26e093fb0c31b3e3d Distribution: --- The basic problem is that winegcc, when passed e.g. "-L/usr/x86_64-w64-mingw32/lib -lvkd3d", looks up that library in the search path, finds libvkd3d.a, and tries to link to it. The mingw-w64 linking process, at least for vkd3d (but presumably others as well), provides both "libvkd3d.a" and "libvkd3d.dll.a". The former is a static library, and the latter is essentially an import library for libvkd3d-1.dll. Normal mingw-w64 gcc, when passed -lvkd3d, links to the latter, according to the search path specified in [1] s.v. "direct linking to a dll". winegcc does not know about .dll.a and hence finds the static library first. This worked before 6a912649 because winegcc would try to find a library ending in ".cross.a", fail to find *any* vkd3d libraries, and just leave the linker argument as "-lvkd3d". Given this, an obvious solution is to teach winegcc about the ld linker path. However, I find myself asking—why are we trying to rewrite the command line at all? Why can't we just let mingw-w64 gcc work by itself? winegcc is, naturally, devoid of any comments, and as far as I can tell the code doesn't actually *do* anything that depends on the library type or path, so I started looking in the git history, but unfortunately was only partly able to answer the question. Here is what I found: * c7a210bc2f27 forces the use of library paths if -mno-cygwin is set (in addition to some other conditions). The commit message specifies that we *can* do this (due to our use of -nodefaultlibs), but doesn't specify why we *need* to do this. Jacek, can you by chance explain? * 33147c947500 forces the use of library paths (sort of) if lib_suffix is set, which makes sense—gcc won't be able to find any libraries if we are overriding lib_suffix. * 870d490eecdb forces the use of library paths for all winelib DLLs, so that "-lfoo" links to "foo/foo.dll". This makes sense, but is also now obsolete—our makefiles pass the direct paths. Or do we want to support winelib users outside of wine including from the build tree? * 006ec80dd5c1 introduces the logic in the first place, forcing the use of library paths for static libraries. This was written by Dimitrie O. Paun, with the comment "For static libs (.a) we need to pass the actual filename to winebuild, not a -l switch." No further explanation is given. Alexandre, can you please shed light on this? [1] https://sourceware.org/binutils/docs-2.39/ld/WIN32.html -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 Jacek Caban <jacek(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek(a)codeweavers.com --- Comment #1 from Jacek Caban <jacek(a)codeweavers.com> --- c7a210bc2f27 fixed building Wine with clang msvc mode. libfoo.dll.a (and libfoo.a) is a mingw thing, when LLD is used in msvc mode, it looks for foo.lib. Since we provide our import libs with "mingw" names, we can't rely on linker to find those libraries in this case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 --- Comment #2 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Jacek Caban from comment #1)
c7a210bc2f27 fixed building Wine with clang msvc mode. libfoo.dll.a (and libfoo.a) is a mingw thing, when LLD is used in msvc mode, it looks for foo.lib. Since we provide our import libs with "mingw" names, we can't rely on linker to find those libraries in this case.
I guess I didn't realize that code path would turn paths "back" into -lfoo even if they weren't written as -lfoo in the first place. On the other hand, wouldn't we have still used --lib-suffix at that point? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 --- Comment #3 from Jacek Caban <jacek(a)codeweavers.com> --- (In reply to Zeb Figura from comment #2)
On the other hand, wouldn't we have still used --lib-suffix at that point?
Ah, right, it wasn't for building Wine itself, but for using winegcc as a tool for cross compiling external code. Installed importlibs never had .cross.a suffix. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 --- Comment #4 from Henri Verbeet <hverbeet(a)gmail.com> --- Mostly for the benefit of people building their own Wine and vkd3d that are running into this issue: Note that configuring vkd3d with --disable-static will prevent these static libraries from being built in the first place. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED Fixed by SHA1| |3c235e053c7ca472b9169d0ef07 | |b82c77843a549 --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> --- Hopefully fixed by 3c235e053c7ca472b9169d0ef07b82c77843a549. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53918 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.0-rc2. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla