https://bugs.winehq.org/show_bug.cgi?id=47090
Bug ID: 47090 Summary: wine fails to build with certain LDFLAGS Product: Wine Version: 4.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl CC: julliard@winehq.org Distribution: ---
I'm not 100% sure it's a proper bug, cause I couldn't get a confirmation from anyone else, yet - going by the sources - there might be something valid here.
Anyway, this is reported against 4.7, but almost certainly the problem comes from the changes made in 4.6 (which I've skipped - my current working wine build is 4.5). During build with LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro", of which just about only '-Wl,--as-needed' might matter (unless I've hit a linker bug), build fails as soon as it starts linking to the newly created libwine with "missing symbols" errors for __wine_dbg_output and __wine_dbg_header.
As far as I can tell by the sources, till ntdll gets loaded, those symbols are indeed undefined. I suspect the source of the problem is that a few of the inline functions defined in include/wine/debug.h call those functions.
While you may not consider this a valid problem (that is, if you're able to reproduce it), this has literally been working for years, so I'd still want to know why it stopped now.
https://bugs.winehq.org/show_bug.cgi?id=47090
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47090
--- Comment #1 from Alexandre Julliard julliard@winehq.org --- I can't reproduce, it builds fine here.
https://bugs.winehq.org/show_bug.cgi?id=47090
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Alexandre Julliard from comment #1)
I can't reproduce, it builds fine here.
Command that builds libwine: x86_64-pc-linux-gnu-gcc -m32 -o libwine.so.1.0 config.o debug.o ldt.o loader.o mmap.o port.o version.o -shared \ -Wl,-soname,libwine.so.1 \
-Wl,--version-script=/mnt/buildbox/builds/portage/app-emulation/wine-4.7/work/wine-4.7/libs/wine/wine.map \ ../../libs/port/libwine_port.a -ldl -Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,-z,relro
A failing command: x86_64-pc-linux-gnu-gcc -m32 -o wine-installed main.o \ -Wl,--rpath,$ORIGIN/`../tools/makedep -R /usr/bin /usr/lib32` -Wl,--enable-ne w-dtags \ -Wl,--export-dynamic -Wl,-Ttext-segment=0x7c000000 -Wl,-z,max-page-size=0x1000 -lwine -lpthread \ ../libs/port/libwine_port.a -L../libs/wine -Wl,-O1 -Wl,--as-needed -Wl,--sort- common -Wl,-z,relro
../libs/wine/libwine.so: undefined reference to `__wine_dbg_header' ../libs/wine/libwine.so: undefined reference to `__wine_dbg_output'
so, I don't know... Any chance that during your build the already installed libwine is getting picked up ? Going by '-L' it shouldn't, but perhaps '-rpath' interferes...? Anyway, 'nm -C -D' does show those two symbols as undefined in the built lib...
gcc 7.3.0 binutils 2.29.1
https://bugs.winehq.org/show_bug.cgi?id=47090
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- libwine should not be referencing these. Did you change CFLAGS too? Please attach the full build log.
https://bugs.winehq.org/show_bug.cgi?id=47090
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 64293 --> https://bugs.winehq.org/attachment.cgi?id=64293 build log
...not really - besides -march/-mtune, it's just the standard '-O2'.
https://bugs.winehq.org/show_bug.cgi?id=47090
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- I don't know then. I imagine it's including a copy of the static inline functions even though they are not used. You'll need to debug this yourself I'm afraid.
https://bugs.winehq.org/show_bug.cgi?id=47090
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- :sweatdrop:
...so, the problem was due to a (nearly) 7 years old patch that partially addresses a bug in wine, that's still valid and (mostly) untouched.
It was using 'ERR' in libwine, which now is no longer possible. Just replacing that with 'fprintf(stderr,...)' got things moving.
https://bugs.winehq.org/show_bug.cgi?id=47090
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #7 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Invalid.
-
wine-bugs＠winehq.org