[PATCH] Fix libunwind build on ARM
keithp at keithp.com
Thu Jun 26 11:19:40 PDT 2014
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
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
objdump -x libunwind*1 | grep libgcc
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
Size: 810 bytes
Desc: not available
More information about the xorg-devel