[PATCH] Fix libunwind build on ARM

[Thierry Reding]

On Wed, Jun 25, 2014 at 11:53:46AM -0700, Keith Packard wrote:
> Thierry Reding <thierry.reding at gmail.com> writes:
> 
> > From: Thierry Reding <treding at nvidia.com>
> >
> > Building the X server with libunwind support on ARM currently yields
> > these errors at link time:
> >
> > 	  CCLD     Xorg
> > 	/usr/lib/libunwind.so: undefined reference to `__aeabi_unwind_cpp_pr0'
> > 	/usr/lib/libunwind.so: undefined reference to `__aeabi_unwind_cpp_pr1'
> >
> > This is caused by the configure script looking for the libunwind.pc file
> > which ends up pulling in -lunwind. On ARM that library doesn't link with
> > libgcc_s.so where the above symbols are defined, hence the link failure.
> >
> > If instead the configure script looks for libunwind-generic.pc, then the
> > -lunwind-generic library is pulled in (it's a symlink to libunwind-arm),
> > which in turn pulls in -lunwind and -lgcc_s (via DT_NEEDED entries).
> 
> I'm afraid this conflicts with the libunwind documentation which
> explicitly states that -lunwind is the correct library to use for native
> unwinding:
> 
> FILES
>        libunwind.h
>                Headerfile to include for native (same platform) unwinding.
> 
>        libunwind-PLAT.h
>               Header file to include when the unwind target runs on
>               platform PLAT.  For example, to unwind an IA-64 program,
>               the header file libunwind-ia64.h should be included.
> 
>        -lunwind
>                Linker-switch to add when building a program that does
>               native (same platform) unwinding.
> 
>        -lunwind-PLAT
>                Linker-switch to add when building a program that unwinds
>               a program on platform PLAT.  For example, to
>               (cross-)unwind an IA-64 program, the linker switch
>               -lunwind-ia64 should be added. Note: multiple such
>               switches may need to be specified for programs that can
>               unwind programs on mul‐ tiple platforms.
> 
> It sounds like libunwind.so is just misbuilt on your platform. I just
> checked libunwind.so on Debian's armel distro and it does explicitly
> link to libgcc_s. I can't test that it works, of course, but at least
> this problem isn't present.

I'm seeing this on two systems: one that I build completely from scratch
and another that's Arch Linux ARM. Neither of those link libunwind.so to
libgcc_s. Looking at the libunwind sources this may be caused by the
following extract in configure.ac:

	if test x$GCC = xyes -a x$intel_compiler != xyes -a x$qcc_compiler != xyes; then
	  LIBCRTS="-lgcc"
	fi

If I change that to -lgcc_s, then it works as expected and I don't need
this workaround in the X server. Interestingly I can't find anything in
the Debian package that would make a similar change, so perhaps Debian
has some magic in the gcc package to resolve -lgcc to -lgcc_s somehow?

Inspecting the libgcc1 and libgcc-4.9-dev (4.9.0-7) from Debian (both
armel and armhf variants) it looks as if they don't contain the
__aeabi_unwind_cpp_pr* symbols at all...

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140626/700b8bf2/attachment.sig>