https://bugs.winehq.org/show_bug.cgi?id=38713
--- Comment #6 from Ken Thomases ken@codeweavers.com --- Created attachment 51676 --> https://bugs.winehq.org/attachment.cgi?id=51676 configure check for libunwind
(In reply to Erich E. Hoover from comment #3)
Created attachment 51673 [details] ntdll: Link to libunwind on x86-64 Linux.
Thanks for this.
Please try the attached on Mac :) I used UNWIND_LIBS instead of LIBUNWIND_LIBS since that seems to match the current convention for these libraries.
Hmm. Well, on the Mac it's mostly harmless. There is no separate library for the libunwind functionality. It's present in the C library that's linked by default. So, your check doesn't find any library and the link goes fine.
However, it does emit an unnecessary notice.
I think that checking for _Unwind_RaiseException probably is a good solution to the symbol renaming that the header does for things like unw_init_local(). With that, we can use AC_SEARCH_LIBS, which I think is the more appropriate checking macro. It explicitly supports the possibility that no library may be necessary for the target symbol. I'm attaching an alternative patch using that approach.
It adds a new config.h define, HAVE_LIBUNWIND, and changes the code in signal_x86_64.c to test that. So, the code is only used if both the header and the symbol are available.
I've eliminated the notice. If libunwind is not available, I'm not sure that's a problem that the user/builder/packager needs to address. It will just go back to the situation before my commit, which was mostly fine. The only problem (that I'm aware of) was on OS X, where there's not really any question that libunwind will be available. If desired, we can add the notice back based on the variable ac_cv_search__Unwind_RaiseException.
Can you test on x86-64 Linux? Thanks again.