[PATCH] Fix libunwind build on ARM
Thierry Reding
thierry.reding at gmail.com
Thu Jun 26 07:55:41 PDT 2014
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>
More information about the xorg-devel
mailing list