Aaron Puchert changed bug 1231820
What Removed Added
CC   aaronpuchert@alice-dsl.net
Status NEW CONFIRMED

Comment # 2 on bug 1231820 from Aaron Puchert
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: