https://bugzilla.suse.com/show_bug.cgi?id=1231820 https://bugzilla.suse.com/show_bug.cgi?id=1231820#c2 Aaron Puchert <aaronpuchert@alice-dsl.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aaronpuchert@alice-dsl.net Status|NEW |CONFIRMED --- Comment #2 from Aaron Puchert <aaronpuchert@alice-dsl.net> --- This issue seems to break the build of wine-nine-standalone on x86_64, but not 32-bit x86. The build fails in the configuration phase, where it's trying to detect presence of dlopen (edited for readability): Command line: `winegcc [...]/testfile.c -o [...]/output.exe -m64 -D_FILE_OFFSET_BITS=64 -O0 -mwindows` -> 2 stderr: /usr/x86_64-suse-linux/bin/ld: cannot find -lshell32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -lcomdlg32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -lgdi32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -ladvapi32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -luser32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -lwinecrt0: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -lkernel32: No such file or directory /usr/x86_64-suse-linux/bin/ld: cannot find -lntdll: No such file or directory collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed But I'm not sure if the libraries are missing, after all there are files that would resolve this in x86_64-windows. Let's try with a simple "int main() {}". When I add -L/usr/lib64/wine/x86_64-windows, I get the same errors that you got:
winegcc main.c -o output.exe -m64 -mwindows -L/usr/lib64/wine/x86_64-windows /usr/bin/ld: relocatable linking with relocations from format pe-x86-64 (/usr/lib64/wine/x86_64-windows/libuser32.a(user32_syms-000001f6.o)) to format elf64-x86-64 (tmp6742bbac/output-00000001.spec-00000001.o) is not supported winebuild: winegcc: /usr/bin/winebuild failed
However, when I instead set the environment variable LIBRARY_PATH=/usr/lib64/wine/x86_64-windows, I get $ winegcc main.c -o output.exe -m64 -mwindows /usr/x86_64-suse-linux/bin/ld: tmp6742b34d/output-00000001.spec.o: in function `__wine_spec_nt_header': (.data+0x28): undefined reference to `__wine_spec_exe_entry' collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed So it seems to have found the libraries and the format is matching. (My suspicion is that winegcc does some conversion under the hood, if we tell it about the libraries in the right way.) The error is now about a missing entry point. For regular ELF binaries the entry point would come from some object file passed into the linker. For now let's just rename "main" into "__wine_spec_exe_entry". This compiles. Adding some printf also works and even runs: $ ./output.exe 0050:err:winediag:nodrv_CreateWindow Application tried to create a window, but no driver could be loaded. 0050:err:winediag:nodrv_CreateWindow L"The explorer process failed to start." 0050:err:systray:initialize_systray Could not create tray window Hello World! The messages are because I run this outside of a graphical session. In a graphical session: $ ./output.exe 0080:fixme:wineusb:query_id Unhandled ID query type 0x5. wine: could not open working directory L"unix\\home\\aaron\\", starting in the Windows directory. Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. Ok, this might be because we played around with the entry point. We're probably missing some setup. However, running it directly works again: $ wine64 output.exe.so 007c:fixme:wineusb:query_id Unhandled ID query type 0x5. Hello World! Now let's try some actual Windows functions, like MessageBox. The code is straightforward. But it doesn't quite build: /usr/x86_64-suse-linux/bin/ld: warning: user32_tail-00000001.o: missing .note.GNU-stack section implies executable stack /usr/x86_64-suse-linux/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/lib64/wine/x86_64-windows/libuser32.a(user32_syms-000001f6.o):(.idata$4+0x0): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined /usr/lib64/wine/x86_64-windows/libuser32.a(user32_syms-000001f6.o):(.idata$5+0x0): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined /usr/lib64/wine/x86_64-windows/libuser32.a(user32_syms-000001f6.o):(.idata$7+0x0): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined /usr/lib64/wine/x86_64-windows/libuser32.a(user32_head-00000000.o):(.idata$2+0x0): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined /usr/lib64/wine/x86_64-windows/libuser32.a(user32_head-00000000.o):(.idata$2+0xc): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined /usr/lib64/wine/x86_64-windows/libuser32.a(user32_head-00000000.o):(.idata$2+0x10): dangerous relocation: R_AMD64_IMAGEBASE with __ImageBase undefined collect2: error: ld returned 1 exit status winegcc: /usr/bin/gcc failed The warnings are a bit smelly, but Ok. The build fails because of a missing symbol __ImageBase, which I think might be provided by the same object file that should also provide the entry point. Let's do something evil and add "__attribute__((used)) int __ImageBase;" to make it resolve. That makes it compile. Of course it doesn't run properly—it crashes instead, but that was expected. My suspicion is that there is an issue with the paths. The fact that it works on 32-bit, where we have everything in the more usual /usr/lib, versus our 64-bit setup in /usr/lib64, makes me think this might be a reason. However, I think the entry point and __ImageBase should come from some object file, and I can't find any in wine-devel. Looking through the build history, this have happened relatively recently, maybe in the last two months. Before that, wine-nine-standalone was building fine. (It's currently broken even on i586 because of a GCC issue, but that is fixed upstream and I encountered this while trying to update the package.) -- You are receiving this mail because: You are on the CC list for the bug.