[PATCH] Fix libunwind build on ARM

[Keith Packard]

Thierry Reding <thierry.reding at gmail.com> writes:

> 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

That seems like a plausible bug; will be nice to know if the libunwind
maintainers agree and can fix it.

> 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?

I extracted the libunwind.so from the debian package and looked at it
with objdump:

objdump -x libunwind*1 | grep libgcc
  NEEDED               libgcc_s.so.1
  required from libgcc_s.so.1:

I assumed this meant that it would work, but I don't have any easy way
to verify this.

> 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...

I thought those were the symbols you expect to see in libgcc_s though?

In any case, it sounds like a kludge-around is required for at least
some distros, and I have no easy way to know which ones. You should be
able to auto-detect broken libunwind packages by just linking a trivial
program and see if that works, falling back to libunwind-generic when
libunwind is broken?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140626/0f413c06/attachment-0001.sig>