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. > 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? -- [email protected]
pgpwUeR9LbZ03.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
