David Shen <davidshe...@googlemail.com> posted 53e35fd50906190041j35d95488lbcf3c7eb1efa8...@mail.gmail.com, excerpted below, on Fri, 19 Jun 2009 15:41:30 +0800:
> I am trying to install Xen VM on my gentoo 2008 x64. According to what > http://en.gentoo-wiki.com/wiki/Xen said, I should run "mv /usr/lib/tls > /usr/lib/tls.disabled" and re-compile glibc and gcc to disable the 'tls' > feature. But I found that my system *DOES NOT* have the /usr/lib/tls > file/directory. Does this changed its place, or this prerequisite does > not apply to x64 system? First, note for future reference that "x64" is a rather ambiguous term, as it's (AFAIK) unofficial and could be equally argued to apply to Intel's ia64 aka "itanium" aka "itanic" architecture or to AMD's amd64 aka x86_64 architecture. Of course, this list is for the amd64 arch and it can be assumed you are referring to that here, but as I said, for future reference. =:^O Meanwhile, to your question: I don't do xen but based on my knowledge of Gentoo and Linux history from the 2004 time frame, that doesn't apply to a modern Gentoo Linux system. "tls" refers to "thread local storage". I'm somewhat confused on the exact relationships (whether tls was the nptl on or off version, a google produced some hints that it was the nptl on version, but nothing definitive), but tls was related to nptl, "native posix thread library", which was introduced by Red Hat back in 2002 and was just becoming a big thing on Gentoo about the time I switched to Gentoo around May, 2004. Prior to that, Linux had normally used Linux threads for threading. However, Linux-threads was Linux-only and wasn't entirely POSIX compatible, among other issues. NPTL was higher performing, and gradually took over and became the standard, both due to the better performance and because it WAS POSIX compliant and therefore made easier porting between Linux and the BSDs and various UNIX variants. NPTL did/does require either a 2.6 kernel or a patched 2.4 kernel, and was supported by glibc. Just checking the older glibc versions still in the tree, thru glibc 2.5*, the Gentoo glibc ebuilds have the nptl and nptlonly USE flags. With glibc 2.6, Gentoo was apparently dropping mainline kernel 2.4 support and nptl (and nptlonly) apparently became the un-USE-flagged default. Anyway, back when glibc was built for both nptl and linux-threads, /usr/lib/tls contained one version, while the other was in the standard /lib and /usr/lib locations (where lib means lib64 on amd64, with an equivalent 32-bit version for multilib users). BTW, x86(32) and amd64 no-multilib users now build glibc only once, while amd64 multilib users (the default) build it twice, once for 32-bit and once for 64-bit. During the linux-threads/nptl both era, that was doubled, so amd64 multilib users were actually building glibc four times, one each for nptl and linux-threads, for each of 32-bit and 64-bit! No WONDER emerging glibc seemed to take so long back then! So assuming you're using a 2.6 kernel and glibc >= 2.6 as well, /usr/lib(64)/tls should not exist, unless for some reason it wasn't removed properly during whatever glibc emerge would have gotten rid of it (the first 2.6 version if users hadn't been running USE=nptl nptlonly, the first glibc emerge after they switched to those USE flags if they did run them). The same should apply to the corresponding 32-bit libdir, for those still running multilib (I'm running no-multilib and don't remember where the 32-bit dir was, anymore). Thus, apparently that step of the the xen guide is either still around for the legacy installs still using old glibc versions, or it's there to ensure people remove the dir if it's unused cruft that didn't get cleaned up properly for whatever reason. Since you don't have that dir, you shouldn't have to worry about it. Here's some wikipedia links that should serve as beginning points for further research, if you're curious: http://en.wikipedia.org/wiki/Thread-local_storage http://en.wikipedia.org/wiki/Nptl http://en.wikipedia.org/wiki/LinuxThreads (stub article) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
