Comment # 4 on bug 1231820 from Aaron Puchert

(In reply to Alexander Leithner from comment #3)
> I'm not sure if I'm understanding what you're trying to say/do here. I'll
> assume that your experiment produces a PE binary for the rest of my comment,
> as this is the way I read LD's output here.

No, it's whatever winegcc produces. You can see the flags, I didn't pass any
special flags. Anyway, since you've asked:

$ file output.exe
output.exe: POSIX shell script, ASCII text executable

But this is just a wrapper that in the end calls output.exe.so:

$ file output.exe.so
output.exe.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
static-pie linked, BuildID[sha1]=[...], with debug_info, not stripped

So it's ELF and not PE. However, it's not a regular ELF binary:

$ readelf --dynamic output.exe.so

Dynamic section at offset 0x18e38 contains 21 entries:
  Tag        Type                         Name/Value
 0x0000000000000010 (SYMBOLIC)           0x0
 0x0000000060009996 (Operating System specific: 60009996)                0x1000
 0x000000000000000d (FINI)               0x15000
 0x0000000060009994 (Operating System specific: 60009994)               
0x18e28
 0x0000000060009995 (Operating System specific: 60009995)                0x8
 0x000000000000001a (FINI_ARRAY)         0x18e30
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x260
 0x000000006ffffef5 (GNU_HASH)           0x2a0
 0x0000000000000005 (STRTAB)             0x3e0
 0x0000000000000006 (SYMTAB)             0x2d8
 0x000000000000000a (STRSZ)              159 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x18fc8
 0x0000000000000007 (RELA)               0x480
 0x0000000000000008 (RELASZ)             216 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000000000001e (FLAGS)              SYMBOLIC BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW
 0x000000006ffffff9 (RELACOUNT)          5
 0x0000000000000000 (NULL)               0x0

This is what winegcc is expected to produce according to my understanding.

What am I trying to say? That I could make the missing library errors
disappear, and not by telling winegcc to build a PE binary. (Which I wouldn't
even know how to do.) This indicates that the libraries might not be missing.

> > 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.
> 
> This may be the case though I don't see why changing the paths when building
> Wine could lead it to not produce all files. When building Wine from source
> from the Wine project's Git repository, it generates the following folder
> structure:
> 
> prefix/lib64/wine
>  +- i386-windows
>  +- x86_64-unix
>  +- x86_64-windows

I didn't try building it from source, but in the end that's also what the
package does. You're right that e.g. x86_64-windows/advapi32.dll is a PE
binary, but the linker doesn't complain about the library missing, nor about a
mismatch between PE and ELF. Maybe there is some translation going on, after
all this isn't a regular ELF binary and only works in Wine. So Wine might be
able to load PE binaries just fine.

> but no prefix/lib folder and no i386-unix as is currently present in
> OpenSUSE's packages. Notably, with the above folder structure, Wine ELF DLLs
> can be built for both 32 and 64-bit although only x86_64-unix is present, as
> I've alluded to in this bug's description.
> 
> I'm not well-versed enough in RPM spec writing to diagnose the issue with
> the build process further, though. Aside from paths the only notable
> difference I see in the current (failing) build logs of Wine on OBS [3],[4]
> to my local test is that I got the above folder structure after compiling
> wine with:
> 
>   --enable-archs=i386,x86_64 --enable-win64
> 
> in one go.

For the default flavor (i.e. not wow64), we should have

%configure \
        --with-x \
        --with-wayland \
        --with-gstreamer \
        --enable-win64 \
        --verbose

On x86_64. You can see what %configure expands to by running "rpm -E
%configure". You can expand the entire spec file by running "rpmspec -P
wine.spec". (But you might need the dependencies to be installed for that to
work.)

Anyway, the "--enable-archs=i386,x86_64" is an interesting difference. It seems
to single-handedly explain that you have 32-bit libraries while the package
does not. However, maybe we need "--enable-archs=x86_64".

I could try that, but as you've noticed the build is failing. Somehow usage of
the internal dependency generator broke, and that's way beyond my
understanding. I've never seen that being used in another package, and I
suspect it's not documented anywhere.