On Thu, Jun 26, 2014 at 11:19:40AM -0700, Keith Packard wrote: > Thierry Reding <[email protected]> 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
pgplSqDxgFcZO.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
