https://bugs.winehq.org/show_bug.cgi?id=50257
Bug ID: 50257 Summary: Regression: startup crash/infinite loop on FreeBSD Product: Wine Version: 6.0-rc1 Hardware: x86-64 OS: FreeBSD Status: NEW Severity: blocker Priority: P2 Component: msvcrt Assignee: wine-bugs@winehq.org Reporter: damjan.jov@gmail.com
Lots of:
01ac:err:heap:HEAP_GetPtr Invalid heap 00000000! 01ac:err:heap:HEAP_GetPtr Invalid heap 00000000!
Endless 100% CPU usage or crash.
https://bugs.winehq.org/show_bug.cgi?id=50257
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |piotr@codeweavers.com Regression SHA1| |d784dbb89993d0565ea132109b1 | |10cc9500c97f4
--- Comment #1 from Damjan Jovanovic damjan.jov@gmail.com --- Regression during beta release -> BLOCKER.
Bisection result:
d784dbb89993d0565ea132109b110cc9500c97f4 is the first bad commit commit d784dbb89993d0565ea132109b110cc9500c97f4 Author: Piotr Caban piotr@codeweavers.com Date: Tue Dec 1 13:51:32 2020 +0100
msvcrt: Remove MSVCRT_ prefix from heap.c functions.
Signed-off-by: Piotr Caban piotr@codeweavers.com Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/crtdll/crtdll.spec | 20 ++--- dlls/msvcr100/msvcr100.spec | 58 +++++++-------- dlls/msvcr110/msvcr110.spec | 58 +++++++-------- dlls/msvcr120/msvcr120.spec | 58 +++++++-------- dlls/msvcr70/msvcr70.spec | 38 +++++----- dlls/msvcr71/msvcr71.spec | 38 +++++----- dlls/msvcr80/msvcr80.spec | 60 +++++++-------- dlls/msvcr90/msvcr90.spec | 58 +++++++-------- dlls/msvcrt/console.c | 4 +- dlls/msvcrt/cpp.c | 44 +++++------ dlls/msvcrt/data.c | 6 +- dlls/msvcrt/dir.c | 12 +-- dlls/msvcrt/environ.c | 4 +- dlls/msvcrt/errno.c | 14 ++-- dlls/msvcrt/except.c | 2 +- dlls/msvcrt/exit.c | 8 +- dlls/msvcrt/file.c | 56 +++++++------- dlls/msvcrt/heap.c | 56 +++++++------- dlls/msvcrt/locale.c | 174 ++++++++++++++++++++++---------------------- dlls/msvcrt/main.c | 16 ++-- dlls/msvcrt/math.c | 8 +- dlls/msvcrt/mbcs.c | 8 +- dlls/msvcrt/msvcrt.h | 12 +-- dlls/msvcrt/msvcrt.spec | 52 ++++++------- dlls/msvcrt/process.c | 104 +++++++++++++------------- dlls/msvcrt/scheduler.c | 46 ++++++------ dlls/msvcrt/string.c | 2 +- dlls/msvcrt/thread.c | 8 +- dlls/msvcrt/time.c | 24 +++--- dlls/msvcrt/wcs.c | 2 +- dlls/msvcrtd/msvcrtd.spec | 42 +++++------ dlls/ucrtbase/ucrtbase.spec | 38 +++++----- 32 files changed, 562 insertions(+), 568 deletions(-)
https://bugs.winehq.org/show_bug.cgi?id=50257
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com, | |iwtcex@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #2 from Damjan Jovanovic damjan.jov@gmail.com --- This only affects the ELF build, the PE build starts up fine.
Unfortunately mingw-w64 is still a work-in-progress on FreeBSD, so we use the ELF build exclusively.
https://bugs.winehq.org/show_bug.cgi?id=50257
Piotr Caban piotr.caban@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban@gmail.com
--- Comment #3 from Piotr Caban piotr.caban@gmail.com --- What compiler did you use?
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #4 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Piotr Caban from comment #3)
What compiler did you use?
GCC 9.3.0 for the broken ELF build, along with mingw-w64's GCC 10.2.0 for the working PE build.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #5 from Piotr Caban piotr.caban@gmail.com --- I have verified that it works with GCC 9.3.0 on Linux (both 32 and 64-bit build). Could you please attach configure.log? Are there any warnings during compilation (maybe it will be easier if compilation output is also attached)?
I have also tried compiling 64-bit wine on FreeBSD. I didn't dig into it but I'm getting: wine: could not load ntdll.so: (null) both with and without "msvcrt: Remove MSVCRT_ prefix from heap.c functions" patch.
https://bugs.winehq.org/show_bug.cgi?id=50257
Alexander Vereeken Alexander88207@Protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Alexander88207@Protonmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=50257
Gen Otsuji otsugen0000@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |otsugen0000@gmail.com
--- Comment #6 from Gen Otsuji otsugen0000@gmail.com --- Hi, all.
--------------------------------------- #include <stdio.h> #include <malloc.h> void * malloc(size_t size){ putchar('A'); return NULL; } int main(void){ char *p=malloc(20); return 0; } --------------------------------------- This code gets segfault on FreeBSD 12.2R. this bug has similar issue I think.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #7 from Gen Otsuji otsugen0000@gmail.com --- (In reply to Gen Otsuji from comment #6) I used both gcc9 and gcc10 and segfault occur.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #8 from Gen Otsuji otsugen0000@gmail.com --- I don't know whether Comment6's code compiled on Linux runs normally or not.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #9 from Gen Otsuji otsugen0000@gmail.com --- So, if on Linux it gets segfault the same way, I 'm sorry. Just I found it on FreeBSD.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #10 from Gerald Pfeifer gerald@pfeifer.com --- (In reply to Gen Otsuji from comment #9)
So, if on Linux it gets segfault the same way, I 'm sorry. Just I found it on FreeBSD.
Yes, openSUSE Tumbleweed with GCC 10.2.1 segfaults your example as well, Gen. (I'm not sure how this is related to the issue at hand.)
https://bugs.winehq.org/show_bug.cgi?id=50257
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #11 from Paul Gofman pgofman@codeweavers.com --- (In reply to Gen Otsuji from comment #6)
Hi, all.
#include <stdio.h> #include <malloc.h> void * malloc(size_t size){ putchar('A'); return NULL; } int main(void){ char *p=malloc(20); return 0; }
This code gets segfault on FreeBSD 12.2R. this bug has similar issue I think.
FWIW this example segfaults on Linux when compiled and run natively with no Wine involved:
gcc ./test.c -o test ./test
Segmentation fault (core dumped)
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #12 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Gerald Pfeifer from comment #10)
Gen. (I'm not sure how this is related to the issue at hand.)
The crash is in the msvcrt DLLs, which export symbols with names similar to libc's symbols, just like that example code.
ELF's symbol handling is generally a nightmare, as symbols are always global instead of library-scoped (like on Windows and MacOS X), so when multiple libraries export the same symbol, it could end up matching the symbol in the wrong library. Here, the user-defined malloc probably overrides libc's, resulting in a crash as it has different ABI/semantics, possibly corrupting memory too.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #13 from Alex S iwtcex@gmail.com --- (In reply to Damjan Jovanovic from comment #12)
ELF's symbol handling is generally a nightmare,
Still, our nightmare implementation is supposed to be compatible with GNU's. It's quite concerning if Linux behaves differently.
Here, the user-defined malloc probably overrides libc's, resulting in a crash as it has different ABI/semantics, possibly corrupting memory too.
In Gen's case the code simply crashes on the first (libc's internal) memory allocation, which is to be expected. The Wine issue is a bit more interesting:
env LD_DEBUG=1 ./wine64 winecfg ... "calloc" in "libc.so.7" ==> 0x69626e00 in "ucrtbase.dll.so" reloc_jmpslot: *0x62245c18 = 0x69626e00 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! "_execve" in "libc.so.7" ==> 0x6963e1d0 in "ucrtbase.dll.so" ... "_exit" in "libc.so.7" ==> 0x69617190 in "ucrtbase.dll.so" ...
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #14 from Gen Otsuji otsugen0000@gmail.com --- Hi, Thank you for testing on Linux. I'm sorry . the code on Linux also segfaults. But why does wine-6.0-rc4 on FreeBSD stuck? And why does wine-6.0-rc4 on Linux go well? I don't know.
I tested env LD_DEBUG=1.
My assumption is that, wine-6.0-rc4 is using malloc. and into the internal of malloc in heap.c, RtlAllocateHeap in ntdll/heap.c, TRACE => wine_dbg_log => vnsprintf. In vnsprintf,the malloc function is executed and it is recursion of malloc. so this malloc should be in libc.
Thank you all.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #15 from Gen Otsuji otsugen0000@gmail.com --- It's assumption. sorry.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #16 from Gen Otsuji otsugen0000@gmail.com --- I think if something else is happening, too.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #17 from Gen Otsuji otsugen0000@gmail.com --- How about another assumption story? LD_DEBUG=1 ./wine winecfg shows malloc is in libc. so the malloc in wine-6.0-rc4 is not working. and nightmare.
I'm confusing about recursion of malloc. My example code is recursion of malloc .(my assumption story)
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #18 from Alex S iwtcex@gmail.com --- (In reply to Gen Otsuji from comment #17)
With all due respect, we don't really need any kind of analysis.
(If you want a workaround, use LD_BIND_NOW=1.)
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #19 from Gen Otsuji otsugen0000@gmail.com --- (In reply to Alex S from comment #18)
(In reply to Gen Otsuji from comment #17)
With all due respect, we don't really need any kind of analysis.
(If you want a workaround, use LD_BIND_NOW=1.)
I'm sorry, I'll stop writing.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- (In reply to Alex S from comment #13)
env LD_DEBUG=1 ./wine64 winecfg ... "calloc" in "libc.so.7" ==> 0x69626e00 in "ucrtbase.dll.so" reloc_jmpslot: *0x62245c18 = 0x69626e00 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! 0084:err:heap:HEAP_GetPtr Invalid heap 0000000000000000! "_execve" in "libc.so.7" ==> 0x6963e1d0 in "ucrtbase.dll.so" ... "_exit" in "libc.so.7" ==> 0x69617190 in "ucrtbase.dll.so"
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #21 from Piotr Caban piotr.caban@gmail.com --- (In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
There seems to be something wrong with the Linux without-mingw build too. I've tested changing the "pow" function to "MSVCRT_pow" and it affects how often the function is called while running: wine nonexisting.exe
When the function was called pow it was called 2048. It was called 0 times after changing the name to MSVCRT_pow. It was also not called in mingw builds no mater how function was named.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #22 from Alex S iwtcex@gmail.com --- (In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
Submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252307.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #23 from Alexandre Julliard julliard@winehq.org --- (In reply to Piotr Caban from comment #21)
(In reply to Alexandre Julliard from comment #20)
If this means that libc symbols are resolved to ucrtbase.dll.so, that sounds like a bug in the dynamic linker. We load dlls without RTLD_GLOBAL so their symbols should not be available for global resolution.
There seems to be something wrong with the Linux without-mingw build too. I've tested changing the "pow" function to "MSVCRT_pow" and it affects how often the function is called while running: wine nonexisting.exe
When the function was called pow it was called 2048. It was called 0 times after changing the name to MSVCRT_pow. It was also not called in mingw builds no mater how function was named.
Are you sure? pow() is called from the gdi32 font initialization, and it will be imported from ucrtbase also in non-mingw builds, so it should be called in all builds (unless the compiler inlines it). It shouldn't go through ELF linking at all.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #24 from Piotr Caban piotr.caban@gmail.com --- (In reply to Alexandre Julliard from comment #23)
Are you sure?
No, I've done something wrong while testing, sorry.
https://bugs.winehq.org/show_bug.cgi?id=50257
robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |robert.ayrapetyan@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #25 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- Seems relevant, wine v6.2_1 (i386-wine-develop compiled with gcc10) on x64 gives:
... rtld_exit() calling fini function for /usr/bin/uname at 0x20322c calling fini function for /lib/libc.so.7 at 0x8003fdf40 calling fini function for /lib/libc.so.7 at 0x80040949c "_rtld_addr_phdr" in "libc.so.7" ==> 0x800213fd0 in "ld-elf.so.1" reloc_jmpslot: *0x80041cb48 = 0x800213fd0 lm_fini() lm_free(0x800232110) "_write" in "libc.so.7" ==> 0x8004078b0 in "libc.so.7" reloc_jmpslot: *0x80041bfc0 = 0x8004078b0 "_exit" in "libc.so.7" ==> 0x800398bb0 in "libc.so.7" reloc_jmpslot: *0x80041bcf0 = 0x800398bb0 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION
(hangs here, waiting...)
0024:err:environ:run_wineboot boot event wait timed out 0024:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 003c:err:environ:run_wineboot boot event wait timed out 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:module:LdrInitializeThunk "ucrtbase.dll" failed to initialize, aborting 003c:err:module:LdrInitializeThunk Initializing dlls for L"C:\windows\system32\services.exe" failed, status c0000142 003c:err:service:RPC_Init RpcServerListen failed with error 1721 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 0024:err:heap:HEAP_GetPtr Invalid heap 00000000! 002c:err:wineboot:start_services_process Couldn't start services.exe: error 1359 ^C0024:err:module:LdrInitializeThunk "kernelbase.dll" failed to initialize, aborting 0024:err:module:LdrInitializeThunk Initializing dlls for L"C:\windows\system32\winecfg.exe" failed, status c000013a 0024:err:module:LdrInitializeThunk "comctl32.dll" failed to initialize, aborting 0024:err:module:LdrInitializeThunk Initializing dlls for L"C:\windows\system32\winecfg.exe" failed, status c000013a
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #26 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- Btw when compiling with clang 10.0.1 on FreeBSD 12.2 x64 it fails with:
... tools/winegcc/winegcc -o dlls/activeds/activeds.dll.so --wine-objdir . -m64 -fPIC -fasynchronous-unwind-tables -shared \ dlls/activeds/activeds.spec -mno-cygwin dlls/activeds/activeds_main.o dlls/activeds/pathname.o \ dlls/activeds/activeds_r.res -ladvapi32 -lole32 -loleaut32 dlls/uuid/libuuid.a \ dlls/ucrtbase/libucrtbase.a -fstack-protector-strong ld: error: undefined symbol: __wine$func$ucrtbase$2264$ldexp
referenced by ucrtbase.UooaI2.o:(ldexp) in archive dlls/ucrtbase/libucrtbase.a
ld: error: undefined symbol: __wine$func$ucrtbase$2315$memset
referenced by ucrtbase.xoRUpg.o:(memset) in archive dlls/ucrtbase/libucrtbase.a
cc: error: linker command failed with exit code 1 (use -v to see invocation) winegcc: /usr/bin/cc failed gmake[2]: *** [Makefile:1930: dlls/aclui/aclui.dll.so] Error 2 gmake[2]: *** Waiting for unfinished jobs.... ...
so seems it just passes gcc10 unseen and fails only at a runtime.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #27 from Alex S iwtcex@gmail.com --- (In reply to robert.ayrapetyan from comment #26)
Btw when compiling with clang 10.0.1 on FreeBSD 12.2 x64 it fails with:
ld: error: undefined symbol: __wine$func$ucrtbase$2264$ldexp
That doesn't look like a valid symbol name.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #28 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- Yeah, but similar symbol is generated by gcc10 (only diff is a number):
__wine$func$ucrtbase$2333$ldexp
in dlls/ucrtbase/libucrtbase.a
but somehow it proceeds with no errors...
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #29 from Alex S iwtcex@gmail.com --- (In reply to robert.ayrapetyan@gmail.com from comment #28)
Yeah, but similar symbol is generated by gcc10 (only diff is a number):
__wine$func$ucrtbase$2333$ldexp
in dlls/ucrtbase/libucrtbase.a
but somehow it proceeds with no errors...
See https://source.winehq.org/git/wine.git/commit/aac69889bf1e276688895eca313dc8....
In any case, this a completely different issue.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #30 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- Sure, so what's the workaround for the original issues? How to perform: "You need to LD_PRELOAD your interposer" while building - a suggestion from Konstantin in a referred bug?
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #31 from Alex S iwtcex@gmail.com --- (In reply to robert.ayrapetyan@gmail.com from comment #30)
Sure, so what's the workaround for the original issues?
Ctrl + F "workaround".
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #32 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- LD_BIND_NOW works for x64 on x64 build, but still gives:
002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 002c:fixme:ntdll:get_firmware_info info_class SYSTEM_FIRMWARE_TABLE_INFORMATION 003c:err:environ:run_wineboot boot event wait timed out 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:heap:HEAP_GetPtr Invalid heap 00000000! 003c:err:module:LdrInitializeThunk "ucrtbase.dll" failed to initialize, aborting 003c:err:module:LdrInitializeThunk Initializing dlls for L"C:\windows\system32\services.exe" failed, status c0000142 003c:err:service:RPC_Init RpcServerListen failed with error 1721 002c:err:wineboot:start_services_process Couldn't start services.exe: error 1359
for i386 on x64.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #33 from Alex S iwtcex@gmail.com --- (In reply to robert.ayrapetyan@gmail.com from comment #32)
It's LD_32_BIND_NOW for 32-bit apps on amd64.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #34 from robert.ayrapetyan@gmail.com robert.ayrapetyan@gmail.com --- Thanks, that worked.
https://bugs.winehq.org/show_bug.cgi?id=50257
Graham Perrin grahamperrin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |grahamperrin@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #35 from Graham Perrin grahamperrin@gmail.com --- (In reply to Piotr Caban from comment #5)
… also tried compiling 64-bit wine on FreeBSD. I didn't dig into it but I'm getting: wine: could not load ntdll.so: (null) both with and without "msvcrt: Remove MSVCRT_ prefix from heap.c functions" patch.
FYI https://forums.FreeBSD.org/threads/77253/post-522107
https://bugs.winehq.org/show_bug.cgi?id=50257
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #36 from Jacek Caban jacek@codeweavers.com --- (In reply to Damjan Jovanovic from comment #2)
This only affects the ELF build, the PE build starts up fine.
Unfortunately mingw-w64 is still a work-in-progress on FreeBSD, so we use the ELF build exclusively.
I don't know what's problematic about getting mingw-w64 to work on FreeBSD, but for other options, recent Wine may be built with PE support using plain Clang. Clang supports cross compilation to PE targets with its default config and that's all we need, we don't need any other mingw addition. So, unless it's disabled for some reason on FreeBSD, you shouldn't need anything else.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #37 from Alex S iwtcex@gmail.com --- (In reply to Jacek Caban from comment #36)
I don't know what's problematic about getting mingw-w64 to work on FreeBSD,
mingw-w64 works fine, but it's a bit intimidating to package.
but for other options, recent Wine may be built with PE support using plain Clang. Clang supports cross compilation to PE targets with its default config and that's all we need, we don't need any other mingw addition.
That looks promising, however Clang can't find stdarg.h. I tried on the whim stdarg.h from FreeBSD, Glibc and Mingw-w64: Wine only sucessfully compiles with the header from Glibc. What's the deal with that?
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #38 from Jacek Caban jacek@codeweavers.com --- (In reply to Alex S from comment #37)
That looks promising, however Clang can't find stdarg.h. I tried on the whim stdarg.h from FreeBSD, Glibc and Mingw-w64: Wine only sucessfully compiles with the header from Glibc. What's the deal with that?
stdarg.h is usually shipped with the compiler and Clang should provide one. Is it missing in your Clang installation (see eg. /usr/lib/clang/12.0.0/include/stdarg.h) for some reason?
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #39 from Alex S iwtcex@gmail.com --- (In reply to Jacek Caban from comment #38)
stdarg.h is usually shipped with the compiler and Clang should provide one. Is it missing in your Clang installation (see eg. /usr/lib/clang/12.0.0/include/stdarg.h) for some reason?
Somehow it is missing; probably an oversight. Thank you for clarification though, at least I learned where to grab the correct header.
Now we only have to hunt down a few extremely obnoxious Clang-related regressions*... Like the one where clang/lld builds a few remaining .dll.so's such as (BaseOfCode << 32) + AddressOfEntryPoint < ImageBase, which fixup_rva_ptrs seems to further mess up.
* https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231010
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #40 from Jacek Caban jacek@codeweavers.com --- Note that you may use a different compiler for .dll.so (I guess you were using GCC and you may continue to do so) and use clang only for PE parts. That's what configure should do by default when it can't mingw and clang is found, but if you want to be explicit, it's something like:
configure CROSSCC=clang
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #41 from Alex S iwtcex@gmail.com --- I filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257533 regarding the PE build (for emulators/wine-devel port). We'll see how it goes.
https://bugs.winehq.org/show_bug.cgi?id=50257
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #42 from Fabian Maurer dark.shadow4@web.de --- Is there any news regarding the original issue? The last posts seem to have gotten quite on a tangent.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #43 from Alex S iwtcex@gmail.com --- I'd suggest reading the thread again. And a few more times, if necessary.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #44 from Fabian Maurer dark.shadow4@web.de ---
I'd suggest reading the thread again. And a few more times, if necessary.
Rude. There hasn't been talk about the original issue for almost a year, therefore I feel the question is warranted. We're currently in bug-fix season, so IMHO this would be a good point to address the issue for the next stable.
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #45 from Alex S iwtcex@gmail.com --- It's not at all a secret I positively _hate_ people with poor reading comprehension. The original issue (a presumed dynamic linker bug) is out of scope of Wine, it was reported to FreeBSD (PR 252307) and is quite unlikely to be fixed unless it inconveniences a significant number of people.
https://bugs.winehq.org/show_bug.cgi?id=50257
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|pgofman@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #46 from Austin English austinenglish@gmail.com --- (In reply to Alex S from comment #45)
It's not at all a secret I positively _hate_ people with poor reading comprehension.
That doesn't mean you need to reply in a rude way, particularly since the comment wasn't even directed at you, but on the bug in general, in such you're one of _several_ participants.
https://bugs.winehq.org/show_bug.cgi?id=50257
Alex S iwtcex@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|iwtcex@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=50257
--- Comment #47 from Fabian Maurer dark.shadow4@web.de --- Thank you Austin. Anyways, should be mark this as NOTOURBUG and simply wait for a FreeBSD fix?
https://bugs.winehq.org/show_bug.cgi?id=50257
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTOURBUG Status|NEW |RESOLVED CC| |nerv@dawncrow.de
--- Comment #48 from André H. nerv@dawncrow.de --- (In reply to Fabian Maurer from comment #47)
Thank you Austin. Anyways, should be mark this as NOTOURBUG and simply wait for a FreeBSD fix?
yes :)
https://bugs.winehq.org/show_bug.cgi?id=50257
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|regression |
-
WineHQ Bugzilla