Hi Dan > What happens is that the NPTL enabled libc and friends go in /lib/tls > and /usr/lib/tls and the linuxthreads enabled ones go in /lib and > /usr/lib. If you ever strace a binary, you will see it looking in > /lib/tls first and then /lib. This is designed into the dynamic > linker ld.so for this exact reason.
That's interesting information, thanks 8o). I actually used --enable-addons=linuxthreads so I don't think I've got any NPTL libc libraries at all, but I may have a look just to make sure I did what I thought I was doing! > Anyway, very interesting stuff. Someone should send a note to Maple to > get with the program and build their binaries with NPTL support. No > doubt it would be much faster. In fact the problem is not with Maple itself, but with the third-party installer that they use (called InstallAnywhere). I can copy the Maple binaries from the Slackware installation that I have and they run properly (after I tell it where to find its java). This was my workaround for a while. My hope is that the next version of Maple will use a suitably updated installer and I can go back to LFS with NPTL, but I doubt that'll happen for a few months at least. I started a thread on MaplePrimes about it, and several of the developers post there so I think that they know about it. However, LFS is not a supported distribution for them, but someone posted the same error from Fedora Core 5 so they may take a bit more notice of that. Anyhow, back to work. Dave -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
