[PATCH] Fix libunwind build on ARM

[Thierry Reding]

On Thu, Jun 26, 2014 at 11:19:40AM -0700, Keith Packard wrote:
> 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.

I've sent a patch to the libunwind mailing list. I hope you don't mind
that I Cc'ed you, but since you signalled some interest in the outcome
of the discussion I figured it'd be fine.

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

Yes, I agree that this means it should work. I'd really like to know why
it properly links to libgcc_s on Debian but not when building from the
upstream sources directly or on Arch Linux. I do suspect that libtool or
gcc Debian packages may carry some patch that changes the behaviour, but
I couldn't make heads or tails of the gcc build scripts on Debian...

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

Yes, and I mistakenly looked for them using objdump -t rather than
objdump -T. objdump -T indeed confirms that these symbols are present in
the libgcc_s shipped on the armel port of Debian.

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

That sounds like an interesting work-around. I'll see if I can make that
work. I'm slightly reluctant because at this point I'm convinced that it
is not an issue in the X server's build system...

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/20140627/aeae2631/attachment.sig>