Has anyone successfully built a debian package with the necessary glibc changes? I created a dpatch and modified the cflags, but ran into some weirdness. Then I realized I needed gcc-3.4 so I got a backport gcc-3.4, but now there are some compile errors. So before I go crazy trying to make this package build, I thought I would check and see if anyone else has tried. I know lots of people use Debian for their DomU''s, someone else must want a proper libc as well. mark _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Petersen wrote:> Has anyone successfully built a debian package with the necessary > glibc changes? I created a dpatch and modified the cflags, but ran > into some weirdness. Then I realized I needed gcc-3.4 so I got a > backport gcc-3.4, but now there are some compile errors. So before I > go crazy trying to make this package build, I thought I would check > and see if anyone else has tried. I know lots of people use Debian > for their DomU''s, someone else must want a proper libc as well.which type of debian version would you like to use? For sarge I have made it: https://einstein.ki.iif.hu/~szferi/xen/debian -- Regards Ferenc Szalai _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi> Has anyone successfully built a debian package with the > necessary glibc changes? I created a dpatch and modified the > cflags, but ran into some weirdness. Then I realized I > needed gcc-3.4 so I got a backport gcc-3.4, but now there are > some compile errors. So before I go crazy trying to make > this package build, I thought I would check and see if anyone > else has tried. I know lots of people use Debian for their > DomU''s, someone else must want a proper libc as well.Well, I do. deb http://debian-packages.sh-solutions.de/ xen/ But be warned: Those are build for / from and in etch: Packages.gz Release glibc-doc_2.3.6-3_all.deb libc6-amd64_2.3.6-3_i386.deb libc6-dbg_2.3.6-3_i386.deb libc6-dev-amd64_2.3.6-3_i386.deb libc6-dev_2.3.6-3_i386.deb libc6-i686_2.3.6-3_i386.deb libc6-pic_2.3.6-3_i386.deb libc6-prof_2.3.6-3_i386.deb libc6_2.3.6-3_i386.deb locales_2.3.6-3_all.deb nscd_2.3.6-3_i386.deb Regards, Steffen _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Mar 20, 2006 at 05:27:59PM -0600, Mark Petersen wrote:> Has anyone successfully built a debian package with the necessary > glibc changes? I created a dpatch and modified the cflags, but ran > into some weirdness. Then I realized I needed gcc-3.4 so I got a > backport gcc-3.4, but now there are some compile errors. So before I > go crazy trying to make this package build, I thought I would check > and see if anyone else has tried. I know lots of people use Debian > for their DomU''s, someone else must want a proper libc as well.There are various fixes for this being discussed on the pkg-xen-devel list: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-March/000366.html http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-March/000310.html http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-March/000311.html and the followups to those threads. There are a couple of workarounds suggested too. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Mar 21, 2006 at 10:02:55AM +0000, Dominic Hargreaves wrote:> There are various fixes for this being discussed on the pkg-xen-devel > list:And, indeed, there are now test packages available by a glibc maintainer: http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-March/000382.html -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Mark Petersen schrieb:> Has anyone successfully built a debian package with the necessary > glibc changes? I created a dpatch and modified the cflags, but ran > into some weirdness. Then I realized I needed gcc-3.4 so I got a > backport gcc-3.4, but now there are some compile errors. So before I > go crazy trying to make this package build, I thought I would check > and see if anyone else has tried. I know lots of people use Debian > for their DomU''s, someone else must want a proper libc as well.Why would I want a specialized glibc? What is wrong with the standard one? Dirk _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Dienstag, 21. März 2006 18:10 schrieb Dirk H. Schulz:> Mark Petersen schrieb: > > Has anyone successfully built a debian package with the necessary > > glibc changes? I created a dpatch and modified the cflags, but ran > > into some weirdness. Then I realized I needed gcc-3.4 so I got a > > backport gcc-3.4, but now there are some compile errors. So before I > > go crazy trying to make this package build, I thought I would check > > and see if anyone else has tried. I know lots of people use Debian > > for their DomU''s, someone else must want a proper libc as well. > > Why would I want a specialized glibc? What is wrong with the standard one? > > Dirkfirst of all, this is only interessting for i386. amd64 (and probably other architectures) doesn''t have this problem at all. With the std. libc6 package you need to move /lib/tls away on i386 xen hosts, because otherwise you would loose a lot of performance. I think every user already saw xen warning about that at boot time. but moving /lib/tls away is not optimal for more than one reason: - it''s no permanent solution. You have to do this after each glibc upgrade on each dom0 and domU. - if you switch a lot between a non-xenified kernel and the xen hypervisor+kernel you will end up in moving the /lib/tls directory a lot. - moving /lib/tls away disabled more features than needed. java and some other programs will lose performance because of /lib/tls is missing completly. - this solution isn''t user-friendly at all. With the glibc packages by Aurelien Jarno (part of the official debian-glibc team) all these problems will be fixed. You have to install "libc6-xen" once, but afterwards never need to take care of this again. - if no xen kernel is running the default libc6 is used like libc6-xen never had been installed. - when a xen kernel is running then the xen optimized version is used for optimal performance without the user have to do something. with this special libc6 package java, mysql and other applications should benifit and have a better performance - this setup will not break on libc6 upgrades - it works in dom0 and domU''s. - this solution will be "officially" supported by debian (if xen3 and these packages are officially released in debian). you can fill bug reports if something is not working as expected... I think (if no big problems are found) this will go in debian unstable with the next glibc upgrade. But for now, these libc6 packages are not tested! Everybody may use them, but without any promise that it is really working as expected... Some team members of the pkg-xen debian group (including me) will test these libc6 packages in the next days. --Ralph _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Mar 21 ''06 at 18:33, Ralph Passgang wrote:> > Why would I want a specialized glibc? What is wrong with the standard one? > [ ... ] > but moving /lib/tls away is not optimal for more than one reason: > - it''s no permanent solution. You have to do this after each glibc upgrade on > each dom0 and domU.Just some nitpicking here: dpkg-divert will make the move permanent. I use it on all my 32bit (only 4 left ;-) ) virtual domains, since i switched to debian, as even uml needs(/needed?) it. -- /"\ Goetz Bock at blacknet dot de -- secure mobile Linux everNETting \ / (c) 2006 Creative Commons, Attribution-ShareAlike 2.0 de X [ 1. Use descriptive subjects - 2. Edit a reply for brevity - ] / \ [ 3. Reply to the list - 4. Read the archive *before* you post ] _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
>> Why would I want a specialized glibc? What is wrong with the standard >> one? >> >> Dirk > > first of all, this is only interessting for i386. amd64 (and probably > other architectures) doesn''t have this problem at all.I wouldn''t expect it to be a problem for anything but 32 bit x86. The problem is the glibc exploits a - rather bizarre - feature of the x86 segmentation hardware. Because we don''t use the segmentation hardware to protect Xen on x86_64, it''s not a problem on that architecture. AFAIK, neither Xen nor glibc use nasty segmentation features on other architectures (I''m not even sure that the other architectures we support actually have rich enough - or any - segmentation features for this to work in any case) will do something different again, so it shouldn''t be a problem there either. Cheers, Mark> > With the std. libc6 package you need to move /lib/tls away on i386 xen > hosts, because otherwise you would loose a lot of performance. I think > every user already saw xen warning about that at boot time. > > but moving /lib/tls away is not optimal for more than one reason: - it''s > no permanent solution. You have to do this after each glibc upgrade on > each dom0 and domU. - if you switch a lot between a non-xenified kernel > and the xen hypervisor+kernel you will end up in moving the /lib/tls > directory a lot. - moving /lib/tls away disabled more features than > needed. java and some other programs will lose performance because of > /lib/tls is missing completly. - this solution isn''t user-friendly at > all. > > With the glibc packages by Aurelien Jarno (part of the official > debian-glibc team) all these problems will be fixed. > > You have to install "libc6-xen" once, but afterwards never need to take > care of this again. > > - if no xen kernel is running the default libc6 is used like libc6-xen > never had been installed. - when a xen kernel is running then the xen > optimized version is used for optimal performance without the user have > to do something. with this special libc6 package java, mysql and other > applications should benifit and have a better performance - this setup > will not break on libc6 upgrades - it works in dom0 and domU''s. - this > solution will be "officially" supported by debian (if xen3 and these > packages are officially released in debian). you can fill bug reports if > something is not working as expected... > > I think (if no big problems are found) this will go in debian unstable > with the next glibc upgrade. > > But for now, these libc6 packages are not tested! Everybody may use them, > but without any promise that it is really working as expected... Some > team members of the pkg-xen debian group (including me) will test these > libc6 packages in the next days. > >--Ralph > >_______________________________________________ >Xen-users mailing list >Xen-users@lists.xensource.com >http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Dienstag, 21. März 2006 18:41 schrieb Goetz Bock:> On Tue, Mar 21 ''06 at 18:33, Ralph Passgang wrote: > > > Why would I want a specialized glibc? What is wrong with the standard > > > one? > > > > [ ... ] > > but moving /lib/tls away is not optimal for more than one reason: > > - it''s no permanent solution. You have to do this after each glibc > > upgrade on each dom0 and domU. > > Just some nitpicking here: dpkg-divert will make the move permanent. > > I use it on all my 32bit (only 4 left ;-) ) virtual domains, since i > switched to debian, as even uml needs(/needed?) it.you right, you can use dpkg-divert for this... but in my opinion this is only a hook/hack and not a really cool solutoin for the debian distribution. - diverting all files in /lib/tls doesn''t handle the situation where you switching from a xenified kernel to a normal one. of couse you can have /lib/tls disabled all the time, but it''s not the optimal solution. - it''s not really user-firendly. having the official debian xen3 packages (which will be available in future) recommend/suggest libc6-xen is way better! - and last but definitly not least: it should bring better performance than just disabling /lib/tls completly... --Ralph p.s.: in theory the libc6-xen package should also work on uml and fix the /lib/tls problem there (because it''s basicly the same issue). but I am absolutly not sure if glibc wouldn''t needed to get patched addionally for also supporting/detecting uml kernels... as far as I know there is no plan to officially support uml with it''s own seperate glibc-flavour. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, I had compiled a XenSpecificGlibc on an etch dom0. After installing it on dom0 and an etch domU, the warning stopped as expected. Now I have installed a sarge dom0 and after installing the previously compiled libc6, the warning does not go away. Why could this be? Chris. On 3/21/06, Ralph Passgang <ralph@debianbase.de> wrote:> Am Dienstag, 21. März 2006 18:41 schrieb Goetz Bock: > > On Tue, Mar 21 ''06 at 18:33, Ralph Passgang wrote: > > > > Why would I want a specialized glibc? What is wrong with the standard > > > > one? > > > > > > [ ... ] > > > but moving /lib/tls away is not optimal for more than one reason: > > > - it''s no permanent solution. You have to do this after each glibc > > > upgrade on each dom0 and domU. > > > > Just some nitpicking here: dpkg-divert will make the move permanent. > > > > I use it on all my 32bit (only 4 left ;-) ) virtual domains, since i > > switched to debian, as even uml needs(/needed?) it. > > you right, you can use dpkg-divert for this... but in my opinion this is only > a hook/hack and not a really cool solutoin for the debian distribution. > > - diverting all files in /lib/tls doesn''t handle the situation where you > switching from a xenified kernel to a normal one. of couse you can > have /lib/tls disabled all the time, but it''s not the optimal solution. > > - it''s not really user-firendly. having the official debian xen3 packages > (which will be available in future) recommend/suggest libc6-xen is way > better! > > - and last but definitly not least: it should bring better performance than > just disabling /lib/tls completly... > > --Ralph > > p.s.: in theory the libc6-xen package should also work on uml and fix > the /lib/tls problem there (because it''s basicly the same issue). but I am > absolutly not sure if glibc wouldn''t needed to get patched addionally for > also supporting/detecting uml kernels... as far as I know there is no plan to > officially support uml with it''s own seperate glibc-flavour. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Am Mittwoch, 22. März 2006 08:26 schrieb Chris Fanning:> Hi, > > I had compiled a XenSpecificGlibc on an etch dom0. After installing it > on dom0 and an etch domU, the warning stopped as expected. > > Now I have installed a sarge dom0 and after installing the previously > compiled libc6, the warning does not go away. > > Why could this be?two possibilites... you have created the initrd at a time where /lib/tls was activated without a special libc6 version and that''s why you get this warning, or the libc6 package you compiled is missing something. I think because glibc is older in sarge you have to patch it and not just add a compiler flag. But I am not a glibc maintainer and can''t help you really. I hope you haven''t installed the libc6 package mentioned in this thread, because this was only meant to be for sid and is not working as expected anyways...> Chris. > > On 3/21/06, Ralph Passgang <ralph@debianbase.de> wrote: > > Am Dienstag, 21. März 2006 18:41 schrieb Goetz Bock: > > > On Tue, Mar 21 ''06 at 18:33, Ralph Passgang wrote: > > > > > Why would I want a specialized glibc? What is wrong with the > > > > > standard one? > > > > > > > > [ ... ] > > > > but moving /lib/tls away is not optimal for more than one reason: > > > > - it''s no permanent solution. You have to do this after each glibc > > > > upgrade on each dom0 and domU. > > > > > > Just some nitpicking here: dpkg-divert will make the move permanent. > > > > > > I use it on all my 32bit (only 4 left ;-) ) virtual domains, since i > > > switched to debian, as even uml needs(/needed?) it. > > > > you right, you can use dpkg-divert for this... but in my opinion this is > > only a hook/hack and not a really cool solutoin for the debian > > distribution. > > > > - diverting all files in /lib/tls doesn''t handle the situation where you > > switching from a xenified kernel to a normal one. of couse you can > > have /lib/tls disabled all the time, but it''s not the optimal solution. > > > > - it''s not really user-firendly. having the official debian xen3 packages > > (which will be available in future) recommend/suggest libc6-xen is way > > better! > > > > - and last but definitly not least: it should bring better performance > > than just disabling /lib/tls completly... > > > > --Ralph > > > > p.s.: in theory the libc6-xen package should also work on uml and fix > > the /lib/tls problem there (because it''s basicly the same issue). but I > > am absolutly not sure if glibc wouldn''t needed to get patched addionally > > for also supporting/detecting uml kernels... as far as I know there is no > > plan to officially support uml with it''s own seperate glibc-flavour. > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dominic Hargreaves writes ("Re: [Xen-users] Debian XenSpecificGlibc"):> There are various fixes for this being discussed on the pkg-xen-devel > list:I have added some extra references to XenSpecificGlibc, including one to my xen-divert-tls-libc script, at http://wiki.xensource.com/xenwiki/DebianTlsLibcDiversion. It''s a moderately grotty approach but it has the benefit of being very unintrusive to the guest Debian installation (no need to patch the libc each time a new one comes out - upgrades work just fine) and also being surprisingly straightforward. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> two possibilites... you have created the initrd at a time where /lib/tls was > activated without a special libc6 version and that''s why you get this > warning,that was it! :) thanks. On 3/22/06, Ralph Passgang <ralph@debianbase.de> wrote:> Am Mittwoch, 22. März 2006 08:26 schrieb Chris Fanning: > > Hi, > > > > I had compiled a XenSpecificGlibc on an etch dom0. After installing it > > on dom0 and an etch domU, the warning stopped as expected. > > > > Now I have installed a sarge dom0 and after installing the previously > > compiled libc6, the warning does not go away. > > > > Why could this be? > > two possibilites... you have created the initrd at a time where /lib/tls was > activated without a special libc6 version and that''s why you get this > warning, or the libc6 package you compiled is missing something. I think > because glibc is older in sarge you have to patch it and not just add a > compiler flag. But I am not a glibc maintainer and can''t help you really. > > I hope you haven''t installed the libc6 package mentioned in this thread, > because this was only meant to be for sid and is not working as expected > anyways... > > > Chris. > > > > On 3/21/06, Ralph Passgang <ralph@debianbase.de> wrote: > > > Am Dienstag, 21. März 2006 18:41 schrieb Goetz Bock: > > > > On Tue, Mar 21 ''06 at 18:33, Ralph Passgang wrote: > > > > > > Why would I want a specialized glibc? What is wrong with the > > > > > > standard one? > > > > > > > > > > [ ... ] > > > > > but moving /lib/tls away is not optimal for more than one reason: > > > > > - it''s no permanent solution. You have to do this after each glibc > > > > > upgrade on each dom0 and domU. > > > > > > > > Just some nitpicking here: dpkg-divert will make the move permanent. > > > > > > > > I use it on all my 32bit (only 4 left ;-) ) virtual domains, since i > > > > switched to debian, as even uml needs(/needed?) it. > > > > > > you right, you can use dpkg-divert for this... but in my opinion this is > > > only a hook/hack and not a really cool solutoin for the debian > > > distribution. > > > > > > - diverting all files in /lib/tls doesn''t handle the situation where you > > > switching from a xenified kernel to a normal one. of couse you can > > > have /lib/tls disabled all the time, but it''s not the optimal solution. > > > > > > - it''s not really user-firendly. having the official debian xen3 packages > > > (which will be available in future) recommend/suggest libc6-xen is way > > > better! > > > > > > - and last but definitly not least: it should bring better performance > > > than just disabling /lib/tls completly... > > > > > > --Ralph > > > > > > p.s.: in theory the libc6-xen package should also work on uml and fix > > > the /lib/tls problem there (because it''s basicly the same issue). but I > > > am absolutly not sure if glibc wouldn''t needed to get patched addionally > > > for also supporting/detecting uml kernels... as far as I know there is no > > > plan to officially support uml with it''s own seperate glibc-flavour. > > > > > > _______________________________________________ > > > Xen-users mailing list > > > Xen-users@lists.xensource.com > > > http://lists.xensource.com/xen-users > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users