Hello, Matthias Klose, le Wed 20 Aug 2014 23:39:40 +0200, a écrit : > I backported the proposed fix for PR61841 in 4.9.1-6, however this doesn't > seem > to fix things.
I don't see how their proposed fix could fix the issue we are having on GNU/Hurd. The issue mentioned on https://gcc.gnu.org/ml/gcc/2013-09/msg00196.html and alike are that libpthread doesn't get pulled at all due to toolchain changes, and thus PR61841 emits a reference to pthread_create to pull it. The issue we are having on GNU/Hurd, as explained by Pino, is that the symbol that libstdc++ looks for, __pthread_key_create, doesn't exist in our libpthread. The comment in libgcc/gthr-posix.h explains that it is on purpose that it looks for __pthread_key_create and not pthread_key_create: they want to avoid stumbling on a intercepted symbol. So there is little hope they change their strategy. As Pino explained, one solution is to make libstdc++ look for another symbol on GNU/Hurd, another it so just make Hurd's libpthread define __pthread_key_create just like Linux' does. > However, please see Thomas Schwinge's mail to bug-hurd about this issue. Err, which mail about which issue? The mail I can read is Subject: Re: Hurd GCC ping Date: Wed, 20 Aug 2014 01:24:36 +0200 which is about the gcc testsuite, which he says actually goes fine, but the output somehow gets corrupted and thus analysis goes wrong. (I'm very surprised by this, glibc's testsuite log goes without a fuss). I haven't seen any other mail from Thomas, let alone about the std::thread issue at stake here. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140820221039.gr3...@type.youpi.perso.aquilenet.fr