[Bug 38713] Link failure due to use of libunwind in ntdll

https://bugs.winehq.org/show_bug.cgi?id=38713

--- Comment #1 from Ken Thomases  ---
Evidently, on Linux with the libunwind package installed, it is necessary to
link against another library.  My guess is that the eventual solution will have
the effect of adding "-lunwind" to the link line.

The proper solution is for somebody who can build and test on Linux to write a
configure test which would set some configure variable such as "LIBUNWIND_LIBS"
and add that to the EXTRALIBS variable in dlls/ntdll/Makefile.in.

I would say that this should be modeled after the check for -lrt.  Search for
"RT_LIBS" in configure.ac.  However, there's a complication.  As you can see
from the link errors, the exact symbol name that's needed is not the normal
function name.  For example, the code uses unw_init_local() but that results in
a reference to _ULx86_64_init_local() (or, without UNW_LOCAL_ONLY defined,
_Ux86_64_init_local()).  We wouldn't want the configure test to use that symbol
name because it's an implementation detail.  (For example, that's not the
symbol name on OS X.)

So, the configure test is going to have to #define UNW_LOCAL_ONLY and #include
<libunwind.h> to get code that actually depends on the symbol as appropriate
for the platform.  To do this, it may be necessary to copy the definition of
AC_SEARCH_LIBS from autoconf to Wine's aclocal.m4 as, say, WINE_SEARCH_LIBS
with an additional parameter of prologue code (as taken by AC_LANG_PROGRAM(),
for example).  Then, we'd use that with a prologue of:

#ifdef HAVE_LIBUNWIND_H
# define UNW_LOCAL_ONLY
# include <libunwind.h>
#endif

and code like:

unw_context_t unw_context;
    unw_cursor_t cursor;
    unw_getcontext( &unw_context );
    unw_init_local( &cursor, &unw_context );

The reason to test both unw_getcontext() and unw_init_local() is that they seem
to be affected differently by the UNW_LOCAL_ONLY macro.