On Wed, Jun 25, 2014 at 11:53:46AM -0700, Keith Packard wrote:
> Thierry Reding <[email protected]> writes:
> 
> > From: Thierry Reding <[email protected]>
> >
> > 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

Attachment: pgpAG96Qlf9Eb.pgp
Description: PGP signature

_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Reply via email to