From: <se...@ex...> - 2005-05-10 09:56:11
|
Hi, I remember there was a patch for uml, changing the architecture to i586, forcing glibc not to use /lib/tls. Someone knows where I can find it ? The thing is: if I do a 'apt-get upgrade' I have a good chance that the system is half-dead after then. Or is there another way of disableing tls, so that I do not have to remove /lib/tls/* ? Thank you very much ... /sebastian |
From: Blaisorblade <bla...@ya...> - 2005-05-10 10:34:50
|
On Tuesday 10 May 2005 12:02, Sebastian B=F6hm wrote: > Hi, > > I remember there was a patch for uml, changing the architecture to i586, > forcing glibc not to use /lib/tls. > > Someone knows where I can find it ? It's in http://www.suse.de/~kraxel/uml/patches/ named uml-pretend-to-be-i586 (browse the appropriate subdir). > The thing is: if I do a 'apt-get upgrade' I have a good chance that the > system is half-dead after then. > Or is there another way of disableing tls, so that I do not have to > remove /lib/tls/* ? Exporting in the environment LD_ASSUME_KERNEL=3D2.4.1 should also work, and= is a=20 bit more reliable in theory (because a distro *could* compile /lib/tls to=20 even work on i486, I've heard; since no distro does it, this remains=20 theory). =2D-=20 Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Gerd K. <kr...@by...> - 2005-05-10 11:35:23
|
Blaisorblade <bla...@ya...> writes: > > I remember there was a patch for uml, changing the architecture to i586, > > forcing glibc not to use /lib/tls. > > > > Someone knows where I can find it ? > It's in > http://www.suse.de/~kraxel/uml/patches/ > named uml-pretend-to-be-i586 (browse the appropriate subdir). Note that this is a pretty distribution-specific thing. For a few packages where it actually matters performance-wise suse ships i586 and i686 packages (where the i686 versions really use i686 features and thus don't work on i586 machines any more). glibc is one of them. The installer then decides which of the two it wants to install. For suse versions <= 9.1 the i586 version also was built without tls support, so the hack mentioned above used to worked fine. It doesn't work any more with recent suse distributions. Not sure about other vendors. > > The thing is: if I do a 'apt-get upgrade' I have a good chance that the > > system is half-dead after then. The debian people have some crazy stuff in the packaging system, IIRC it's possible for package to fiddle with files belonging to _other_ packages (and dpkg will take care that these changes survive package updates). I think it's possible to create some pseudo package which simply moves the tls libs out of the way permanently. I've never played with that stuff though. > Exporting in the environment LD_ASSUME_KERNEL=2.4.1 should also work, and is a > bit more reliable in theory (because a distro *could* compile /lib/tls to > even work on i486, I've heard; since no distro does it, this remains > theory). Drawback is that there are allways some corner cases where it doesn't work. suid-root binaries for example are usually pretty strict in what they accept from the environment for security reasons. Gerd -- -mm seems unusually stable at present. -- akpm about 2.6.12-rc3-mm3 |
From: Peter <pet...@ri...> - 2005-05-10 12:21:58
|
Note, you can prevent /lib/tls from becoming an issue on apt-get upgrade by using dpkg-divert. e.g. per the debian script here: http://downloads.rimuhosting.com/debiantls.sh But hopefully this will be a moot point shortly after Blaisorblade releases those tls patches be mentioned a week or so back. eh? Regards, Peter Gerd Knorr wrote: > Blaisorblade <bla...@ya...> writes: > > >>>I remember there was a patch for uml, changing the architecture to i586, >>>forcing glibc not to use /lib/tls. >>> >>>Someone knows where I can find it ? >> >>It's in >>http://www.suse.de/~kraxel/uml/patches/ >>named uml-pretend-to-be-i586 (browse the appropriate subdir). > > > Note that this is a pretty distribution-specific thing. For a few > packages where it actually matters performance-wise suse ships i586 > and i686 packages (where the i686 versions really use i686 features > and thus don't work on i586 machines any more). glibc is one of them. > The installer then decides which of the two it wants to install. > > For suse versions <= 9.1 the i586 version also was built without tls > support, so the hack mentioned above used to worked fine. It doesn't > work any more with recent suse distributions. Not sure about other > vendors. > > >>>The thing is: if I do a 'apt-get upgrade' I have a good chance that the >>>system is half-dead after then. > > > The debian people have some crazy stuff in the packaging system, IIRC > it's possible for package to fiddle with files belonging to _other_ > packages (and dpkg will take care that these changes survive package > updates). I think it's possible to create some pseudo package which > simply moves the tls libs out of the way permanently. I've never > played with that stuff though. > > >>Exporting in the environment LD_ASSUME_KERNEL=2.4.1 should also work, and is a >>bit more reliable in theory (because a distro *could* compile /lib/tls to >>even work on i486, I've heard; since no distro does it, this remains >>theory). > > > Drawback is that there are allways some corner cases where it doesn't > work. suid-root binaries for example are usually pretty strict in > what they accept from the environment for security reasons. > > Gerd > |
From: Blaisorblade <bla...@ya...> - 2005-05-10 14:12:11
|
On Tuesday 10 May 2005 14:21, Peter wrote: > Note, you can prevent /lib/tls from becoming an issue on apt-get upgrade > by using dpkg-divert. e.g. per the debian script here: > http://downloads.rimuhosting.com/debiantls.sh > > But hopefully this will be a moot point shortly after Blaisorblade > releases those tls patches be mentioned a week or so back. eh? Well, it won't be this week surely, and possibly I'll finish them even later. The "coding" part is finished, the "debugging" part isn't at all. > Regards, Peter -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <bla...@ya...> - 2005-05-10 14:10:32
|
On Tuesday 10 May 2005 13:30, Gerd Knorr wrote: > Blaisorblade <bla...@ya...> writes: > > > I remember there was a patch for uml, changing the architecture to > > > i586, forcing glibc not to use /lib/tls. > > > > > > Someone knows where I can find it ? > > > > It's in > > http://www.suse.de/~kraxel/uml/patches/ > > named uml-pretend-to-be-i586 (browse the appropriate subdir). > > Note that this is a pretty distribution-specific thing. For a few > packages where it actually matters performance-wise suse ships i586 > and i686 packages (where the i686 versions really use i686 features > and thus don't work on i586 machines any more). glibc is one of them. > The installer then decides which of the two it wants to install. > > For suse versions <= 9.1 the i586 version also was built without tls > support, so the hack mentioned above used to worked fine. It doesn't > work any more with recent suse distributions. Not sure about other > vendors. But that patch is still in your tree, it seems (or did you miss the time to release the current tree?) Tried an uml-pretend-to-be-i486? > > > The thing is: if I do a 'apt-get upgrade' I have a good chance that the > > > system is half-dead after then. > The debian people have some crazy stuff in the packaging system, IIRC > it's possible for package to fiddle with files belonging to _other_ > packages (and dpkg will take care that these changes survive package > updates). I think it's possible to create some pseudo package which > simply moves the tls libs out of the way permanently. I've never > played with that stuff though. > > Exporting in the environment LD_ASSUME_KERNEL=2.4.1 should also work, and > > is a bit more reliable in theory (because a distro *could* compile > > /lib/tls to even work on i486, I've heard; since no distro does it, this > > remains theory). > Drawback is that there are allways some corner cases where it doesn't > work. suid-root binaries for example are usually pretty strict in > what they accept from the environment for security reasons. Interesting point. Could someone check (and possibly fix) the Wiki about this issue? -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Nix <ni...@es...> - 2005-05-10 15:23:53
|
On Tue, 10 May 2005, bla...@ya... mused: > Exporting in the environment LD_ASSUME_KERNEL=2.4.1 should also work, and is a > bit more reliable in theory (because a distro *could* compile /lib/tls to > even work on i486, I've heard; since no distro does it, this remains > theory). Indeed: configuring glibc with --without-__thread, putting the result in /lib/tls, and linking its dynamic linker into /lib yields an NPTL installation that works on i586 without trouble. The only downside is a loss of binary compatibility for programs that use thread cancellation, but these seem to be very rare. -- `End users are just test loads for verifying that the system works, kind of like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s |
From: Blaisorblade <bla...@ya...> - 2005-05-10 15:27:14
|
On Tuesday 10 May 2005 17:23, Nix wrote: > On Tue, 10 May 2005, bla...@ya... mused: > > Exporting in the environment LD_ASSUME_KERNEL=2.4.1 should also work, and > > is a bit more reliable in theory (because a distro *could* compile > > /lib/tls to even work on i486, I've heard; since no distro does it, this > > remains theory). > Indeed: configuring glibc with --without-__thread, putting the result in > /lib/tls, and linking its dynamic linker into /lib yields an NPTL > installation that works on i586 without trouble. > The only downside is a loss of binary compatibility for programs that > use thread cancellation, but these seem to be very rare. Thanks for the info, anyhow that's probably enough to refrain many distros from doing it. Except SuSE, which has the two options (both i586 and i686, choosen by the installer as Gerd just said). -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Nix <ni...@es...> - 2005-05-11 10:49:35
|
On Tue, 10 May 2005, bla...@ya... wrote: > On Tuesday 10 May 2005 17:23, Nix wrote: >> Indeed: configuring glibc with --without-__thread, putting the result in >> /lib/tls, and linking its dynamic linker into /lib yields an NPTL >> installation that works on i586 without trouble. > >> The only downside is a loss of binary compatibility for programs that >> use thread cancellation, but these seem to be very rare. > Thanks for the info, anyhow that's probably enough to refrain many distros > from doing it. Indeed it is; but LinuxThreads isn't long for this world and i586 machines are by no means dead. So I just mentioned it in case anyone wanted to do it themselves (it doesn't seem to be documented anywhere, and if you get the options slightly wrong you get peculiar glibc build failures...) -- `End users are just test loads for verifying that the system works, kind of like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s |