From: Antoine M. <an...@na...> - 2004-10-24 14:13:16
|
> > make linux ARCH=um > > So the UML patches are now in the official 2.6.9 kernel from kernel.org? > And i can build a UML without any additional patches now? Blaisorblade said it should work, but I can't make it work. Blaisorblade, did you mention a new FAQ or help page? I assumed that what I was seeing was due to the missing target. I can run the binary created by make vmlinux, but it stops right at the start (but it does not die): ** [root - uml]# ./linux-2.6.9uml ubd0=./rootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:0,fd:1 Checking for the skas3 patch in the host...found Checking for /proc/mm...found [1]+ Stopped ./linux-2.6.9uml ubd0=./rootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:0,fd:1 ** And the processes are there, just defunct: ** root 7961 7877 0 14:58 pts8 00:00:00 ./linux-2.6.9uml ubd0=root_fs mem=256M con root 7963 7961 0 14:58 pts8 00:00:00 [linux-2.6.9uml] <defunct> ** I can bring the process back to the foreground with 'fg' but it does not help (being <defunct> by then) Should I try with TT and not skas? Cheers Antoine |
From: BlaisorBlade <bla...@ya...> - 2004-10-25 20:39:01
|
On Monday 25 October 2004 04:15, Antoine Martin wrote: > On Sun, 2004-10-24 at 15:13 +0100, Antoine Martin wrote: > > > > make linux ARCH=um > > > > > > So the UML patches are now in the official 2.6.9 kernel from > > > kernel.org? And i can build a UML without any additional patches now? > > > > Blaisorblade said it should work, but I can't make it work. > > more details below > > > Blaisorblade, did you mention a new FAQ or help page? > > Sorry! I found it on the archived list. DOH! > (I must have missed a digest) > > But I still have the same problem running it (see previous email quoted) > I also tried it on amd64, but it doesn't build. Well, building a 32bit UML on amd64 is hard - you need to build it on a 32bit system (or even a 32bit chroot). Building it on a 64-bit system is possible, but not supported. > So I tried applying all the patches I could find on the patches page, > and it still doesn't build (goes slightly further): Those patches are not actually against 2.6.9 - some of them are already included. > /usr/src/linux-2.6.9uml/arch/um/Makefile:159: warning: overriding > commands for target `arch/um/kernel/vmlinux.lds.S' > /usr/src/linux-2.6.9uml/arch/um/Makefile:106: warning: ignoring old > commands for target `arch/um/kernel/vmlinux.lds.S' In fact, the above should not happen. This happens because some patches are already applied. > CHK include/linux/version.h > UPD include/linux/version.h > SYMLINK include/asm -> include/asm-um > SPLIT include/linux/autoconf.h -> include/config/* > scripts/Makefile.build:13: /Makefile: No such file or directory > scripts/Makefile.build:64: kbuild: Makefile.build is included improperly > make[1]: *** No rule to make target `/Makefile'. Stop. > make: *** [/mk_sc] Error 2 > > Anyone got any patches or instructions to make it build and run on > amd64? > The last kernel I could build for this platform is 2.6.4-bk? and it is > quite old and very buggy (and does not play well with latest host > kernels) > > Whilst I was at it, I tried applying the same patches on a i386 build: > gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno- > common -O2 -fomit-frame-pointer -Wdeclaration-after-statement -U__i386__ > -Ui386 -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -fno- > unit-at-a-time -Iarch/um/include - > I/usr/src/linux-2.6.9uml-22-10-2004/arch/um/kernel/skas/include - > D_GNU_SOURCE -c -o arch/um/os-Linux/signal.o arch/um/os-Linux/signal.c > arch/um/os-Linux/signal.c: In function `sig_handler': > arch/um/os-Linux/signal.c:16: warning: implicit declaration of function > `CHOOSE_MODE_PROC' > arch/um/os-Linux/signal.c:16: error: `sig_handler_common_tt' undeclared > (first use in this function) > arch/um/os-Linux/signal.c:16: error: (Each undeclared identifier is > reported only once > arch/um/os-Linux/signal.c:16: error: for each function it appears in.) > arch/um/os-Linux/signal.c: In function `alarm_handler': > arch/um/os-Linux/signal.c:32: error: `sig_handler_common_tt' undeclared > (first use in this function) > make[1]: *** [arch/um/os-Linux/signal.o] Error 1 > make: *** [arch/um/os-Linux] Error 2 > > > Cheers > Antoine > > > I assumed that what I was seeing was due to the missing target. > > I can run the binary created by make vmlinux, but it stops right at the > > start (but it does not die): > > ** > > [root - uml]# ./linux-2.6.9uml ubd0=./rootfs/root_fs.http-ssh-myqsl > > mem=256M con0=fd:0,fd:1 > > Checking for the skas3 patch in the host...found > > Checking for /proc/mm...found > > > > [1]+ Stopped ./linux-2.6.9uml > > ubd0=./rootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:0,fd:1 > > ** > > > > And the processes are there, just defunct: > > ** > > root 7961 7877 0 14:58 pts8 00:00:00 ./linux-2.6.9uml > > ubd0=root_fs mem=256M con > > root 7963 7961 0 14:58 pts8 00:00:00 [linux-2.6.9uml] > > <defunct> > > ** > > I can bring the process back to the foreground with 'fg' but it does not > > help (being <defunct> by then) > > Should I try with TT and not skas? > > > > Cheers > > Antoine > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > User-mode-linux-user mailing list > Use...@li... > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Antoine M. <an...@na...> - 2004-10-26 00:12:23
|
> > But I still have the same problem running it (see previous email quoted) > > > I also tried it on amd64, but it doesn't build. > Well, building a 32bit UML on amd64 is hard - you need to build it on a 32bit > system (or even a 32bit chroot). Building it on a 64-bit system is possible, > but not supported. I built the 32-bit binary on an equivalent 32-bit system (same version of the libs) and copied it over. I was hoping to build the 64-bit binary with 2.6.9, does anyone have a working build/patches for amd64? > > So I tried applying all the patches I could find on the patches page, > > and it still doesn't build (goes slightly further): > Those patches are not actually against 2.6.9 - some of them are already > included. Which ones? I've read a few emails on the -devel- ml, but it isn't yet clear to me what I need to get a working build for amd64. http://user-mode-linux.sourceforge.net/patches.html Seems to indicate that the patches are against 2.6.9 (there is no other version number after that - or am I reading the page wrong?) Thanks Antoine |
From: BlaisorBlade <bla...@ya...> - 2004-10-25 21:44:51
|
On Sunday 24 October 2004 23:41, Sven K=F6hler wrote: > > [root - uml]# ./linux-2.6.9uml ubd0=3D./rootfs/root_fs.http-ssh-myqsl > > mem=3D256M con0=3Dfd:0,fd:1 > > Checking for the skas3 patch in the host...found > > Checking for /proc/mm...found > > > > [1]+ Stopped ./linux-2.6.9uml > > ubd0=3D./rootfs/root_fs.http-ssh-myqsl mem=3D256M con0=3Dfd:0,fd:1 > > ** > > This looks like a problem i had too! It was caused by compiling/running > the kernel on a NPTL-enabled system. So i downgraded to a > non-NPTL-glibc, and everything worked fine again. It would work also on a NPTL glibc, but it must be setup as in mainstream=20 distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i.e.=20 in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does not=20 work. > On the other hand, i'm having problems with linux 2.6.9 UML too. For > example if i run it without any command-line-paramter, the kernel > starts, and should complain about a non-existing rootfs, but the kernel > just hangs. Well, UML does not exit correctly on 2.6.9 kernels (actually UML has used a= n=20 undocumented behaviour, which has worked until 2.6.8.1). This happens even= =20 when UML exits normally: UML leaves one or more stopped threads. You must=20 killall -KILL them and then kilalll -CONT them (and again kill -KILL, until= =20 it works - should work even if done once only, but just to be sure). There = is=20 a patch floating around - search for " 2.6.9 zombie UMLs" in the UML-user=20 list. Bye =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: <sko...@up...> - 2004-10-26 00:18:39
|
>>This looks like a problem i had too! It was caused by compiling/running >>the kernel on a NPTL-enabled system. So i downgraded to a >>non-NPTL-glibc, and everything worked fine again. > > It would work also on a NPTL glibc, but it must be setup as in mainstream > distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i.e. > in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does not > work. So UML will not run on NPTL-enabled gentoo-systems, since gentoo-ebuilds won't build two glibcs (actually they will in the future, but those ebuilds aren't stable yet). And what happens if UML is not statically linked? Will the right libc.so from /lib be loaded instead of the one from /lib/tls? >>On the other hand, i'm having problems with linux 2.6.9 UML too. For >>example if i run it without any command-line-paramter, the kernel >>starts, and should complain about a non-existing rootfs, but the kernel >>just hangs. > > Well, UML does not exit correctly on 2.6.9 kernels (actually UML has used an > undocumented behaviour, which has worked until 2.6.8.1). This happens even > when UML exits normally: UML leaves one or more stopped threads. You must > killall -KILL them and then kilalll -CONT them (and again kill -KILL, until > it works - should work even if done once only, but just to be sure). There is > a patch floating around - search for " 2.6.9 zombie UMLs" in the UML-user > list. This is exactly what i happened to me. I will try the fix. |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 00:33:29
|
On Tuesday 26 October 2004 02:30, Sven K=F6hler wrote: > >>This looks like a problem i had too! It was caused by compiling/running > >>the kernel on a NPTL-enabled system. So i downgraded to a > >>non-NPTL-glibc, and everything worked fine again. > > > > It would work also on a NPTL glibc, but it must be setup as in mainstre= am > > distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i.e. > > in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does n= ot > > work. > > So UML will not run on NPTL-enabled gentoo-systems, since gentoo-ebuilds > won't build two glibcs (actually they will in the future, but those > ebuilds aren't stable yet). Ah, so that is the only problem? And "not stable" means that it is=20 "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anyway. > And what happens if UML is not statically linked? > Will the right libc.so=20 > from /lib be loaded instead of the one from /lib/tls? On my MDK it works quite fine. And it has glibc2.3.3 (actually this is=20 meaningless, since distros anyway must use snapshots). OTOH, tt mode off, static link on does not work. I think that it broke with= =20 recent toolchain/glibcs. I've got some ideas about how to fix that, but not= =20 yet tested well so far. > >>On the other hand, i'm having problems with linux 2.6.9 UML too. For > >>example if i run it without any command-line-paramter, the kernel > >>starts, and should complain about a non-existing rootfs, but the kernel > >>just hangs. > > Well, UML does not exit correctly on 2.6.9 kernels (actually UML has us= ed > > an undocumented behaviour, which has worked until 2.6.8.1). This happens > > even when UML exits normally: UML leaves one or more stopped threads. Y= ou > > must killall -KILL them and then kilalll -CONT them (and again kill > > -KILL, until it works - should work even if done once only, but just to > > be sure). There is a patch floating around - search for " 2.6.9 zombie > > UMLs" in the UML-user list. > This is exactly what i happened to me. I will try the fix. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: <sko...@up...> - 2004-10-26 00:58:48
|
>>>It would work also on a NPTL glibc, but it must be setup as in mainstream >>>distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i.e. >>>in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does not >>>work. >> >>So UML will not run on NPTL-enabled gentoo-systems, since gentoo-ebuilds >>won't build two glibcs (actually they will in the future, but those >>ebuilds aren't stable yet). > > Ah, so that is the only problem? And "not stable" means that it is > "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anyway. For gentoo-users with NPTL enabled, this may be the only problem, yes. You can recognize the new glibc-ebuilds which build two glibc-version by looking at their useflags: the new ebuilds have the "nptlonly" use-flag which will force the old behaviour (building only one version of glibc) again. |
From: Jeremy U. <jer...@gm...> - 2004-10-26 05:03:28
|
On Tue, 26 Oct 2004 02:31:59 +0200, BlaisorBlade <bla...@ya...> wrote: > On Tuesday 26 October 2004 02:30, Sven K=F6hler wrote: > > >>This looks like a problem i had too! It was caused by compiling/runni= ng > > >>the kernel on a NPTL-enabled system. So i downgraded to a > > >>non-NPTL-glibc, and everything worked fine again. > > > > > > It would work also on a NPTL glibc, but it must be setup as in mainst= ream > > > distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i= .e. > > > in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does= not > > > work. Which would mean that no binaries compiled on that system will be linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, this still needs to be resolved in some way. > > > > So UML will not run on NPTL-enabled gentoo-systems, since gentoo-ebuild= s > > won't build two glibcs (actually they will in the future, but those > > ebuilds aren't stable yet). > Ah, so that is the only problem? And "not stable" means that it is > "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anyway. >=20 > > And what happens if UML is not statically linked? >=20 > > Will the right libc.so > > from /lib be loaded instead of the one from /lib/tls? >=20 > On my MDK it works quite fine. And it has glibc2.3.3 (actually this is > meaningless, since distros anyway must use snapshots). MDK's glibc, even in 10.0, is NOT using NPTL - it's still using linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and see the output - you'll note there's no mention of NPTL. What needs to happen is for someone VERY familiar with the UML code to dig in, and find out why the binutils assertion failure keeps tripping up. That's the only error that currently comes about, and it causes any UML kernel to segfault immediately upon execution. I have straces available of the linux binary showing where it segfaults. -J- |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 11:19:06
|
On Tuesday 26 October 2004 02:14, Antoine Martin wrote: > > > But I still have the same problem running it (see previous email > > > quoted) > > > I also tried it on amd64, but it doesn't build. > > Well, building a 32bit UML on amd64 is hard - you need to build it on a > > 32bit system (or even a 32bit chroot). Building it on a 64-bit system is > > possible, but not supported. > I built the 32-bit binary on an equivalent 32-bit system (same version > of the libs) and copied it over. Hmm, what's your host distro? I would like to know if you are using a=20 NPTL-enabled glibc, as Sven K=F6hler suggests, or if the problem is another= =20 one. Also I don't understand the failure reason, actually. > I was hoping to build the 64-bit binary with 2.6.9, does anyone have a > working build/patches for amd64? 1) I think the only working one is the old one for 2.6.4 2) Use the 32-bit binary on a 32-bit host kernel. Really. A 64-bit one woul= d=20 be much slower, because no SKAS support is yet available. I've tried the=20 porting but got inside some difficulties. > > > So I tried applying all the patches I could find on the patches page, > > > and it still doesn't build (goes slightly further): > > Those patches are not actually against 2.6.9 - some of them are already > > included. > Which ones? I've read a few emails on the -devel- ml Which describe what patches are already included (the thread named "What to= =20 send Andrew next"). > , but it isn't yet=20 > clear to me what I need to get a working build for amd64. I don't even know if that is yet possible. > http://user-mode-linux.sourceforge.net/patches.html > Seems to indicate that the patches are against 2.6.9 (there is no other > version number after that - or am I reading the page wrong?) You read that perfectly. Only problem is that the patches are not actually= =20 against 2.6.9. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Antoine M. <an...@na...> - 2004-10-26 18:49:53
|
> > > Well, building a 32bit UML on amd64 is hard - you need to build it = on a > > > 32bit system (or even a 32bit chroot). Building it on a 64-bit syst= em is > > > possible, but not supported. >=20 > > I built the 32-bit binary on an equivalent 32-bit system (same versio= n > > of the libs) and copied it over. >=20 > Hmm, what's your host distro? I would like to know if you are using a=20 > NPTL-enabled glibc, as Sven K=C3=B6hler suggests, or if the problem is = another=20 > one. Also I don't understand the failure reason, actually. It is a gentoo 2004.2 After reading the other thread about nptl, I searched through gentoo's pages and found this: http://www.gentoo-portage.com/sys-libs/glibc/ChangeLog Extract: "28 Sep 2004; Travis Tilley <lv...@ge...> +files/2.3.4/glibc-2.3.4-dl_execstack-PaX-support.patch, +files/2.3.4/glibc-sec-hotfix-20040916.patch, +glibc-2.3.4.20040928.ebuild: new snapshot, masked -*, with fedora-branch patches. made nptl-enabled glibc behave like the glibc in most other distributions, with nptl libs in lib/tls and a fallback linuxthreads version in lib. If the linuxthreads fallback isnt needed/wanted, you can revert to the old behavior by adding nptlonly to USE to save yourself some compile time." So, I tried to emerge this version, but there is still no /lib/tls. So my guess is that the system has a nptl-ed glibc in /lib I am not sure how to get emerge to install both nptl and non-nptl glibc but that is OT for this list. (Obviously if anyone has the answer, I would still like to hear it!) > > I was hoping to build the 64-bit binary with 2.6.9, does anyone have = a > > working build/patches for amd64? > 1) I think the only working one is the old one for 2.6.4 >=20 > 2) Use the 32-bit binary on a 32-bit host kernel. Really. A 64-bit one = would=20 > be much slower, because no SKAS support is yet available. I've tried th= e=20 > porting but got inside some difficulties. I've got to stick with this 64-bit kernel, so I guess it will have to be slow until skas is merged into x86-64. > > clear to me what I need to get a working build for amd64. >=20 > I don't even know if that is yet possible. >=20 > > http://user-mode-linux.sourceforge.net/patches.html > > Seems to indicate that the patches are against 2.6.9 (there is no oth= er > > version number after that - or am I reading the page wrong?) >=20 > You read that perfectly. Only problem is that the patches are not actua= lly=20 > against 2.6.9. Then it may be a good idea to add -rc? (or whatever change is sensible) to the page to prevent other people trying the wrong thing, wasting time and then reporting non existant bugs to this list? |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 11:30:14
|
On Tuesday 26 October 2004 07:03, Jeremy Utley wrote: > On Tue, 26 Oct 2004 02:31:59 +0200, BlaisorBlade > > <bla...@ya...> wrote: > > On Tuesday 26 October 2004 02:30, Sven K=F6hler wrote: > > > >>This looks like a problem i had too! It was caused by > > > >> compiling/running the kernel on a NPTL-enabled system. So i > > > >> downgraded to a > > > >>non-NPTL-glibc, and everything worked fine again. > > > > > > > > It would work also on a NPTL glibc, but it must be setup as in > > > > mainstream distros - i.e. a non-NPTL glibc in /lib and the NPTL one > > > > elsewhere, i.e. in /lib/tls. Otherwise, UML is linked against the > > > > NPTL glibc and does not work. > Which would mean that no binaries compiled on that system will be > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, > this still needs to be resolved in some way. No, this is (slightly) false. Or better, I've read directly the document on= =20 LD_ASSUME_KERNEL on Ulrich Drepper's homepage=20 (http://people.redhat.com/drepper/). The doc is at: http://people.redhat.com/drepper/assumekernel.html What happens on RedHat/FedoraCore: =2D ld-linux.so.2 searches first /lib/tls, then /lib/i686, then /lib (which= is=20 like modifying LD_LIBRARY_PATH, but hardcoded in the linker). This is done to match the LD_ASSUME_KERNEL orderings - ld-linux.so will loa= d a=20 library only if its ABI tag (which is stored inside the library and can be= =20 read with eu-readelf --notes) is not stricter than the running kernel. The= =20 linker does not search for the stricter requirements, so the search path mu= st=20 be the above one. $ eu-readelf --notes /lib/tls/libc.so.6 Note segment of 32 bytes at offset 0x00000154: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.25 $ eu-readelf --notes /lib//libc.so.6 Note segment of 32 bytes at offset 0x00000134: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.2.5 $ eu-readelf --notes /lib/i686/libc.so.6 Note segment of 32 bytes at offset 0x00000134: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.4.1 > > > So UML will not run on NPTL-enabled gentoo-systems, since > > > gentoo-ebuilds won't build two glibcs (actually they will in the > > > future, but those ebuilds aren't stable yet). > > Ah, so that is the only problem? And "not stable" means that it is > > "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anywa= y. > > > Will the right libc.so > > > from /lib be loaded instead of the one from /lib/tls? No, the /lib/tls one should get loaded, but in that case it seems to work. Actually, I've never heard that UML has (unfixed) bugs when linked to NPTL.= =20 Apart from link failures on recent glibc/toolchains :-(, which is not your= =20 case. > > On my MDK it works quite fine. And it has glibc2.3.3 (actually this is > > meaningless, since distros anyway must use snapshots). > MDK's glibc, even in 10.0, is NOT using NPTL - it's still using > linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and > see the output - you'll note there's no mention of NPTL. You still refuse to take a look at my point. Look at the /lib/tls one, whic= h=20 is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put a NPTL=20 enabled glibc in /lib. /lib/tls is the right location. The only current distro without NPTL support, for what I know, is Slackware= =20 10.0. $ /lib/libc.so.6 [...] Compiled by GNU CC version 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk). Compiled on a Linux 2.6.0 system on 2004-02-16. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. $ /lib/tls/libc.so.6 [...] Compiled by GNU CC version 3.3.2 (Mandrake Linux 10.0 3.3.2-4mdk). Compiled on a Linux 2.6.0 system on 2004-02-16. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others (Are you noticing this?) NPTL 0.60 by Ulrich Drepper BIND-8.2.3-T5B NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. > What needs to happen is for someone VERY familiar with the UML code to > dig in, and find out why the binutils assertion failure keeps tripping > up. That's the only error that currently comes about, and it causes > any UML kernel to segfault immediately upon execution. I have straces > available of the linux binary showing where it segfaults. I can get the assertion failure on FC2 - 64bit. I think I could run the=20 binary, but I would not be surprised that I forgot to actually make sure of= =20 that. The first thing I'm trying to do is to add "executable_start" as in the=20 default ld linker scripts. When it will work, I'll let you know. Bye =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Jeremy U. <jer...@gm...> - 2004-10-26 12:28:52
|
On Tue, 26 Oct 2004 13:31:04 +0200, BlaisorBlade <bla...@ya...> wrote: > > > Which would mean that no binaries compiled on that system will be > > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, > > this still needs to be resolved in some way. > > No, this is (slightly) false. Or better, I've read directly the document on > LD_ASSUME_KERNEL on Ulrich Drepper's homepage > (http://people.redhat.com/drepper/). The doc is at: > > http://people.redhat.com/drepper/assumekernel.html > > What happens on RedHat/FedoraCore: > - ld-linux.so.2 searches first /lib/tls, then /lib/i686, then /lib (which is > like modifying LD_LIBRARY_PATH, but hardcoded in the linker). Yep, and ld-linux.so.2 is the run-time linker. The binaries are still *compiled* against the Linuxthreads glibc, which I assume is what you meant by slightly incorrect.. This, of course, explains why only Gentoo (and the soon-to-be-released LinuxFromScratch 6.0) systems encounter this issue - as they do not create a LinuxThreads enabled glibc, and anything compiled on those two currently end up compiled against NPTL glibc. > > > > > So UML will not run on NPTL-enabled gentoo-systems, since > > > > gentoo-ebuilds won't build two glibcs (actually they will in the > > > > future, but those ebuilds aren't stable yet). > > > > Ah, so that is the only problem? And "not stable" means that it is > > > "~x86" (almost perfect) or "-*" (dangerous)? I'll check by myself anyway. > > > > > Will the right libc.so > > > > from /lib be loaded instead of the one from /lib/tls? > No, the /lib/tls one should get loaded, but in that case it seems to work. Confirmed. On my home systems, I can take a UML binary compiled on an older build of LFS (one that still used LinuxThreads), transfer the binary onto a NPTL-lib-only system (no /lib/tls), and it works beautifully. Only when UML compiles against NPTL-compiled libc.so.6 does it fail, and that failure is a constant. > > Actually, I've never heard that UML has (unfixed) bugs when linked to NPTL. > Apart from link failures on recent glibc/toolchains :-(, which is not your > case. > > > > On my MDK it works quite fine. And it has glibc2.3.3 (actually this is > > > meaningless, since distros anyway must use snapshots). > > > MDK's glibc, even in 10.0, is NOT using NPTL - it's still using > > linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and > > see the output - you'll note there's no mention of NPTL. > > You still refuse to take a look at my point. Look at the /lib/tls one, which > is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put a NPTL > enabled glibc in /lib. /lib/tls is the right location. Which exactly proves my point. /lib/tls is not a part of the compile time library search path, so the UML compile does not link to a NPTL glibc. ld-linux.so.2 includes it at run time, which does not expose the problem. And if this dual-libc setup is the "right thing" to do, it begs to wonder why the glibc sources, as downloaded from CVS, don't do this by default - I know, not your area. > > The only current distro without NPTL support, for what I know, is Slackware > 10.0. Agreed, and point taken on Mandrake - I'd never looked at /lib/tls there (I seldom actually use distributions, as the little quirks you get from them drive me crazy, and I hate fighting package manager dependencies). > > > What needs to happen is for someone VERY familiar with the UML code to > > dig in, and find out why the binutils assertion failure keeps tripping > > up. That's the only error that currently comes about, and it causes > > any UML kernel to segfault immediately upon execution. I have straces > > available of the linux binary showing where it segfaults. > > I can get the assertion failure on FC2 - 64bit. I think I could run the > binary, but I would not be surprised that I forgot to actually make sure of > that. I get the assertion failure on ANY UML compile linked against NPTL glibc at compile-time, as opposed to just at run-time, irregardless of what versions of gcc and binutils I use (I've tried this on as low as 2.14 FSF binutils and GCC 3.3.3). In case it helps you, this web link has strace output from a UML kernel binary compiled against a NPTL-only glibc: http://hurricane.jutley.org/~jeremy/uml/umltrace.txt > > The first thing I'm trying to do is to add "executable_start" as in the > default ld linker scripts. When it will work, I'll let you know. Great! Please let me know if there's anything I can do to help - I'm not much of a coder, but I've always got spare CPU cycles to test things out, and the offer I made before of a shell on a NPTL-only system still stands. -J- |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 14:04:42
|
On Tuesday 26 October 2004 14:28, Jeremy Utley wrote: > On Tue, 26 Oct 2004 13:31:04 +0200, BlaisorBlade > > <bla...@ya...> wrote: > > > Which would mean that no binaries compiled on that system will be > > > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, > > > this still needs to be resolved in some way. > > > > No, this is (slightly) false. Or better, I've read directly the document > > on LD_ASSUME_KERNEL on Ulrich Drepper's homepage > > (http://people.redhat.com/drepper/). The doc is at: > > > > http://people.redhat.com/drepper/assumekernel.html > > > > What happens on RedHat/FedoraCore: > > - ld-linux.so.2 searches first /lib/tls, then /lib/i686, then /lib (which > > is like modifying LD_LIBRARY_PATH, but hardcoded in the linker). > > Yep, and ld-linux.so.2 is the run-time linker. > The binaries are still > *compiled* against the Linuxthreads glibc, Well, static binaries are compiled against /usr/lib/libc.a, which is non-NPTL. So you are right for static binaries. For dynamic binaries, they are linked against /usr/lib/libc.so, which "includes" the references to libc.so.6. But no actual code is bundled, and the references are resolved against whatever library is choosen by the linker. So, for dynamic binaries (i.e. most ones, apart UML) your last sentence is wrong. If you wonder why /usr/lib/libc.so is used, the answer is that /usr/lib/libc_nonshared.a contains some special wrappers, which call functions like mknod() with a "mknod ABI version" argument. > which I assume is what you > meant by slightly incorrect. "Slightly incorrect" meant that, actually, it is like setting LD_LIBRARY_PATH="/lib/tls:/lib/i686:/lib"; only this is bundled within the compiler. > This, of course, explains why only > Gentoo (and the soon-to-be-released LinuxFromScratch 6.0) systems > encounter this issue - as they do not create a LinuxThreads enabled > glibc, and anything compiled on those two currently end up compiled > against NPTL glibc. UML is not the only app which breaks with NPTL. Why don't you try the double libc road? > > > > > So UML will not run on NPTL-enabled gentoo-systems, since > > > > > gentoo-ebuilds won't build two glibcs (actually they will in the > > > > > future, but those ebuilds aren't stable yet). > > > > > Will the right libc.so > > > > > from /lib be loaded instead of the one from /lib/tls? > > No, the /lib/tls one should get loaded, but in that case it seems to > > work. > Confirmed. On my home systems, I can take a UML binary compiled on an > older build of LFS (one that still used LinuxThreads), transfer the > binary onto a NPTL-lib-only system (no /lib/tls), and it works > beautifully. Only when UML compiles against NPTL-compiled libc.so.6 > does it fail, and that failure is a constant. > > Actually, I've never heard that UML has (unfixed) bugs when linked to > > NPTL. Apart from link failures on recent glibc/toolchains :-(, which is > > not your case. > > > > On my MDK it works quite fine. And it has glibc2.3.3 (actually this > > > > is meaningless, since distros anyway must use snapshots). > > > > > > MDK's glibc, even in 10.0, is NOT using NPTL - it's still using > > > linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and > > > see the output - you'll note there's no mention of NPTL. > > > > You still refuse to take a look at my point. Look at the /lib/tls one, > > which is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put > > a NPTL enabled glibc in /lib. /lib/tls is the right location. > > Which exactly proves my point. /lib/tls is not a part of the compile > time library search path, so the UML compile does not link to a NPTL > glibc. ld-linux.so.2 includes it at run time, which does not expose > the problem. And if this dual-libc setup is the "right thing" to do, > it begs to wonder why the glibc sources, as downloaded from CVS, don't > do this by default - I know, not your area. I think that's likely. Probably you'll have to look either at Gentoo new ebuilds or at FC source RPMs. > > The only current distro without NPTL support, for what I know, is > > Slackware 10.0. > > > What needs to happen is for someone VERY familiar with the UML code to > > > dig in, and find out why the binutils assertion failure keeps tripping > > > up. That's the only error that currently comes about, and it causes > > > any UML kernel to segfault immediately upon execution. I have straces > > > available of the linux binary showing where it segfaults. > > I can get the assertion failure on FC2 - 64bit. I think I could run the > > binary, but I would not be surprised that I forgot to actually make sure > > of that. > I get the assertion failure on ANY UML compile linked against NPTL > glibc at compile-time, as opposed to just at run-time, irregardless of > what versions of gcc and binutils I use (I've tried this on as low as > 2.14 FSF binutils and GCC 3.3.3). Here is what I use for binutils: root [~: 15:35 (0)] # ld -v GNU ld version 2.14.90.0.7 20031029 > In case it helps you, this web link > has strace output from a UML kernel binary compiled against a > NPTL-only glibc: So the assertion failure comes or does not with the SAME binutils but different libc's? > http://hurricane.jutley.org/~jeremy/uml/umltrace.txt > > The first thing I'm trying to do is to add "executable_start" as in the > > default ld linker scripts. When it will work, I'll let you know. > Great! Please let me know if there's anything I can do to help - I'm > not much of a coder, but I've always got spare CPU cycles to test > things out, and the offer I made before of a shell on a NPTL-only > system still stands. My current Gentoo installation is of that kind. I still need to switch to Gentoo, and the failure with 2.6.9 host kernels is pretty urgent. Plus I need to release an updated patch for the 2.4 kernel tree. However, I'm working on this, too. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: <sko...@up...> - 2004-10-26 11:34:48
|
>>>>>This looks like a problem i had too! It was caused by compiling/running >>>>>the kernel on a NPTL-enabled system. So i downgraded to a >>>>>non-NPTL-glibc, and everything worked fine again. >>>> >>>>It would work also on a NPTL glibc, but it must be setup as in mainstream >>>>distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, i.e. >>>>in /lib/tls. Otherwise, UML is linked against the NPTL glibc and does not >>>>work. > > Which would mean that no binaries compiled on that system will be > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, > this still needs to be resolved in some way. UML's Makefile may explicitly link against the glibc in /lib which shouldn't be a NPTL-one. I think it can be done with LD_RUN_PATH and stuff like that. The UML-kernel-binary will than not just contain "libc.so" but the full path "/lib/libc.so" AFAIK. |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 12:39:57
|
On Tuesday 26 October 2004 13:34, Sven K=F6hler wrote: > >>>>>This looks like a problem i had too! It was caused by > >>>>> compiling/running the kernel on a NPTL-enabled system. So i > >>>>> downgraded to a > >>>>>non-NPTL-glibc, and everything worked fine again. > >>>> > >>>>It would work also on a NPTL glibc, but it must be setup as in > >>>> mainstream distros - i.e. a non-NPTL glibc in /lib and the NPTL one > >>>> elsewhere, i.e. in /lib/tls. Otherwise, UML is linked against the NP= TL > >>>> glibc and does not work. > > > > Which would mean that no binaries compiled on that system will be > > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, > > this still needs to be resolved in some way. Let's make some clarity. Jeremy says that with the NPTL glibc in /lib/tls a= nd=20 a non-NPTL one in /lib/ all normal binaries would be linked against the /li= b=20 one. Which is false, as I explained in my answer to his mail. > UML's Makefile may explicitly link against the glibc in /lib which > shouldn't be a NPTL-one. I think it can be done with LD_RUN_PATH and > stuff like that. The UML-kernel-binary will than not just contain > "libc.so" but the full path "/lib/libc.so" AFAIK. The static linking is always done against a non-NPTL glibc, on sane system= =20 (and the normal Gentoo ebuilds are "broken", in this regard). For the dynam= ic=20 linking, your suggestion may make sense... But the problem is, that very fe= w=20 people exclude CONFIG_MODE_TT from the compile (even because that way it=20 easily breaks), so UML is almost always statically linked. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Nix <ni...@es...> - 2004-11-04 16:13:15
|
On Tue, 26 Oct 2004, Sven K=F6hler stipulated: >>>>>It would work also on a NPTL glibc, but it must be setup as in mains= tream >>>>>distros - i.e. a non-NPTL glibc in /lib and the NPTL one elsewhere, = i.e. >>>>>in /lib/tls. Otherwise, UML is linked against the NPTL glibc and doe= s not >>>>>work. >> Which would mean that no binaries compiled on that system will be >> linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO, >> this still needs to be resolved in some way. >=20 > UML's Makefile may explicitly link against the glibc in /lib which > shouldn't be a NPTL-one. I think it can be done with LD_RUN_PATH and > stuff like that. The UML-kernel-binary will than not just contain > "libc.so" but the full path "/lib/libc.so" AFAIK. If you set LD_ASSUME_KERNEL to 2.2.5 or something like that before running UML, ld-linux.so.2 will look in the right directory automatically. --=20 `Preliminary analysis reveal there are few impact craters on Titan. This suggests Cassini has an active surface constantly being resurfaced.' --- BBC News Online introduces a new planetary body |
From: <sko...@up...> - 2004-10-26 11:58:07
|
> Actually, I've never heard that UML has (unfixed) bugs when linked to NPTL. > Apart from link failures on recent glibc/toolchains :-(, which is not your > case. Well, in the past i already posted that UML won't run if compiled/linked/run against a NPTL glibc. Of course i used gentoo, and that NPTL-enabled gentoo-systems only had one glibc installed. So if it works on the other Ditros like Redhat and Mandrake etc. that install two glibcs, i guess that UML somehow compiles against the non-NPTL glibc, but on gentoo, it doesn't seem to have a choice, and crashes. Does a "lsof" really show, that UML is running with /lib/tls/libc.so? |
From: Jeremy U. <jer...@gm...> - 2004-10-26 12:56:14
|
On Tue, 26 Oct 2004 13:57:59 +0200, Sven K=F6hler <sko...@up...> wrote: > > Actually, I've never heard that UML has (unfixed) bugs when linked to N= PTL. > > Apart from link failures on recent glibc/toolchains :-(, which is not y= our > > case. >=20 > Well, in the past i already posted that UML won't run if > compiled/linked/run against a NPTL glibc. Of course i used gentoo, and > that NPTL-enabled gentoo-systems only had one glibc installed. >=20 > So if it works on the other Ditros like Redhat and Mandrake etc. that > install two glibcs, i guess that UML somehow compiles against the > non-NPTL glibc, but on gentoo, it doesn't seem to have a choice, and > crashes. >=20 > Does a "lsof" really show, that UML is running with /lib/tls/libc.so? As mentioned in my previous post, there's a difference between the linking done at compile time vs the .so's used at run time. Compile time linking is performed by the /usr/bin/ld program (part of binutils) and the GCC Specs file, and it's default setting is to only search /usr/local/lib, /lib, and /usr/lib (I believe in that exact order, however the last 2 may be backwards - /usr/local/lib is always searched first by default). Runtime loading of .so's is handled by /lib/ld-linux.so.2, and as indicated by BlaisorBlade's very informative post, it does things a little different in "mainstream" distros. I'm not sure if this functionality is built into the glibc source code, or handled by patches that are in use by the major distros (I haven't done a lot of investigating on this as of yet). However, it seems that ld-linux.so.2 uses certain characteristics of a binary to determine which of the libc.so.6's it's best to run against. So, on "mainstream" distros, while a UML kernel links against a LinuxThreads libc.so.6 located in /lib at the time of compile, it actually runs by loading the NPTL libc.so.6 located in /lib/tls. Confused? I was for a while, until Blaisor's last post. This explains why the UML root filesystems run with /lib/tls moved out of the way, but do not run with it in place, because a UML kernel does not support TLS (unless that's changed recently, I haven't tried this since about 2.6.4). -J- |
From: Nix <ni...@es...> - 2004-11-09 13:09:12
|
On Tue, 26 Oct 2004, Jeremy Utley yowled: > Runtime loading of .so's is handled by /lib/ld-linux.so.2, and as > indicated by BlaisorBlade's very informative post, it does things a > little different in "mainstream" distros. I'm not sure if this > functionality is built into the glibc source code It is. See the calls to is_hwcap_platform() and path_hwcap() in elf/ldconfig.c. On IA32 platforms, subdirectories named after the current hardware platform (e.g. i686), `mmx' (see HWCAP_IMPORTANT for x86; overrideable at ldconfig time by setting the LD_HWCAP_MASK environment variable), and `tls' are searched, as are things like `i686/tls'. Similar rules are used on other platforms (the same rules, actually, except that the valid platforms and hardware capabilities differ). This is used e.g. to put a v8-optimized OpenSSL (with the integer multiply instructions) in /usr/lib/v8, and a version using the UltraSPARC VIS instructions in /usr/lib/v9, while keeping a SPARCv7 copy in /usr/lib. (This fix alone can reduce the overhead of ssh on SPARC by orders of magnitude.) > However, it seems that > ld-linux.so.2 uses certain characteristics of a binary to determine > which of the libc.so.6's it's best to run against. ldconfig records the capabilities which each library is matched to (see `ldconfig -pv' to see this record), and the kernel's auxiliary vector communicates info about what the hardware is actually capable of to the dynamic linker, in the AT_HWCAP and AT_PLATFORM entries (to see them, run, e.g., `LD_SHOW_AUXV=true ls'). The linker looks for libraries which match the capabilities marked as important (either by HWCAP_IMPORTANT or by the LD_HWCAP_MASK env var, if set), and if they're found, uses them in preference to any less well-matched ones in the cache. > So, on "mainstream" distros, while a UML kernel links against a > LinuxThreads libc.so.6 located in /lib at the time of compile, it > actually runs by loading the NPTL libc.so.6 located in /lib/tls. Naturally, if all these variants of a shared library (libfoo.so.2, tls/libfoo.so.2, i686/libfoo.so.2, i586/mmx/libfoo.so.2, and what have you) don't have compatible sets of symbols exported, you'll have problems. :) > Confused? I was for a while, until Blaisor's last post. This > explains why the UML root filesystems run with /lib/tls moved out of > the way, but do not run with it in place, because a UML kernel does > not support TLS (unless that's changed recently, I haven't tried this > since about 2.6.4). Quite so; the problem is that unlike all the hardware capabilities stuff, the dynamic linker *assumes* that if a tls/ directory is present and the kernel is new enough and of a suitable architecture, TLS is supported. (This is true for i686 with new enough kernels: alas, it's not true under UML. The dynamic linker really needs to respect some sort of overriding `no TLS please' AUXV entry, but no such entry presently exists, and convincing Ulrich to add support to glibc might be tricky; he has very little patience with kludges.) -- `Random line noise picked up from an RS432 cable hung in front of a faulty radar transmitter. ' --- Greg Hennessy on sendmail.cf |
From: Jeremy U. <jer...@gm...> - 2004-10-26 16:09:41
|
On Tue, 26 Oct 2004 16:05:30 +0200, BlaisorBlade <bla...@ya...> wrote: > > > This, of course, explains why only > > Gentoo (and the soon-to-be-released LinuxFromScratch 6.0) systems > > encounter this issue - as they do not create a LinuxThreads enabled > > glibc, and anything compiled on those two currently end up compiled > > against NPTL glibc. > > UML is not the only app which breaks with NPTL. Why don't you try the double > libc road? Mostly, because I don't know how to properly set up glibc in this way - I'll have to take a look at the Gentoo ebuild, and see what I can come up with. But, in 300-some odd packages I compile for my desktop systems, UML kernels is the only place I've seen this one come up. There's some minor problems with apps that link against db4 on a NPTL system, but these are easily worked around with a little LDFLAGS trickery. Beyond that, just about everything I've seen compiles on a NPTL-only system. > > > > > > > So UML will not run on NPTL-enabled gentoo-systems, since > > > > > > gentoo-ebuilds won't build two glibcs (actually they will in the > > > > > > future, but those ebuilds aren't stable yet). > > > > > > > Will the right libc.so > > > > > > from /lib be loaded instead of the one from /lib/tls? > > > > No, the /lib/tls one should get loaded, but in that case it seems to > > > work. > > > Confirmed. On my home systems, I can take a UML binary compiled on an > > older build of LFS (one that still used LinuxThreads), transfer the > > binary onto a NPTL-lib-only system (no /lib/tls), and it works > > beautifully. Only when UML compiles against NPTL-compiled libc.so.6 > > does it fail, and that failure is a constant. > > > > Actually, I've never heard that UML has (unfixed) bugs when linked to > > > NPTL. Apart from link failures on recent glibc/toolchains :-(, which is > > > not your case. > > > > > > On my MDK it works quite fine. And it has glibc2.3.3 (actually this > > > > > is meaningless, since distros anyway must use snapshots). > > > > > > > > MDK's glibc, even in 10.0, is NOT using NPTL - it's still using > > > > linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and > > > > see the output - you'll note there's no mention of NPTL. > > > > > > You still refuse to take a look at my point. Look at the /lib/tls one, > > > which is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put > > > a NPTL enabled glibc in /lib. /lib/tls is the right location. > > > > Which exactly proves my point. /lib/tls is not a part of the compile > > time library search path, so the UML compile does not link to a NPTL > > glibc. ld-linux.so.2 includes it at run time, which does not expose > > the problem. And if this dual-libc setup is the "right thing" to do, > > it begs to wonder why the glibc sources, as downloaded from CVS, don't > > do this by default - I know, not your area. > > I think that's likely. Probably you'll have to look either at Gentoo new > ebuilds or at FC source RPMs. > > > > The only current distro without NPTL support, for what I know, is > > > Slackware 10.0. > > > > > What needs to happen is for someone VERY familiar with the UML code to > > > > dig in, and find out why the binutils assertion failure keeps tripping > > > > up. That's the only error that currently comes about, and it causes > > > > any UML kernel to segfault immediately upon execution. I have straces > > > > available of the linux binary showing where it segfaults. > > > > I can get the assertion failure on FC2 - 64bit. I think I could run the > > > binary, but I would not be surprised that I forgot to actually make sure > > > of that. > > > I get the assertion failure on ANY UML compile linked against NPTL > > glibc at compile-time, as opposed to just at run-time, irregardless of > > what versions of gcc and binutils I use (I've tried this on as low as > > 2.14 FSF binutils and GCC 3.3.3). > Here is what I use for binutils: > > root [~: 15:35 (0)] # ld -v > GNU ld version 2.14.90.0.7 20031029 > > > In case it helps you, this web link > > has strace output from a UML kernel binary compiled against a > > NPTL-only glibc: > > So the assertion failure comes or does not with the SAME binutils but > different libc's? The assertion failure ONLY occurs when compiled against a NPTL-only glibc. I can take the exact same system, install a linuxthreads glibc into some oddball location, compile the UML against that, and have a successful compile. > > > http://hurricane.jutley.org/~jeremy/uml/umltrace.txt > > > > The first thing I'm trying to do is to add "executable_start" as in the > > > default ld linker scripts. When it will work, I'll let you know. > > > Great! Please let me know if there's anything I can do to help - I'm > > not much of a coder, but I've always got spare CPU cycles to test > > things out, and the offer I made before of a shell on a NPTL-only > > system still stands. > > My current Gentoo installation is of that kind. I still need to switch to > Gentoo, and the failure with 2.6.9 host kernels is pretty urgent. Plus I need > to release an updated patch for the 2.4 kernel tree. > > However, I'm working on this, too. Glad to hear it. I know you guys have a lot on your plate, so I'm patient, but it's something I would like to see fixed, and am willing to help out anywhere I can. -J- |
From: <sko...@up...> - 2004-10-28 14:26:12
|
>>UML is not the only app which breaks with NPTL. Why don't you try the double >>libc road? > > Mostly, because I don't know how to properly set up glibc in this way > - I'll have to take a look at the Gentoo ebuild, and see what I can > come up with. But, in 300-some odd packages I compile for my desktop > systems, UML kernels is the only place I've seen this one come up. > There's some minor problems with apps that link against db4 on a NPTL > system, but these are easily worked around with a little LDFLAGS > trickery. Beyond that, just about everything I've seen compiles on a > NPTL-only system. Just use one of the newer glibc ebuilds that are still ~x86. They build two glibcs. You will recognize the ebuild by the new "nptlonly" use-flag. ACCEPT_KEYWORDS="~x86" emerge glibc -vp should do the trick for you. > The assertion failure ONLY occurs when compiled against a NPTL-only > glibc. I can take the exact same system, install a linuxthreads glibc > into some oddball location, compile the UML against that, and have a > successful compile. Confirmed. The same happened to me too. |
From: Blaisorblade <bla...@ya...> - 2004-10-28 19:08:13
|
On Thursday 28 October 2004 16:26, Sven K=F6hler wrote: > >>UML is not the only app which breaks with NPTL. Why don't you try the > >> double libc road? > > > > Mostly, because I don't know how to properly set up glibc in this way > > - I'll have to take a look at the Gentoo ebuild, and see what I can > > come up with. But, in 300-some odd packages I compile for my desktop > > systems, UML kernels is the only place I've seen this one come up. > > There's some minor problems with apps that link against db4 on a NPTL > > system, but these are easily worked around with a little LDFLAGS > > trickery. Beyond that, just about everything I've seen compiles on a > > NPTL-only system. > > Just use one of the newer glibc ebuilds that are still ~x86. They build > two glibcs. You will recognize the ebuild by the new "nptlonly" use-flag. > > ACCEPT_KEYWORDS=3D"~x86" emerge glibc -vp > > should do the trick for you. > > > The assertion failure ONLY occurs when compiled against a NPTL-only > > glibc. I can take the exact same system, install a linuxthreads glibc > > into some oddball location, compile the UML against that, and have a > > successful compile. Yes, it is true normally. But what with the patch I sent to fix the symbol= =20 clash? However, now I'm running Gentoo - just give me the time. > Confirmed. The same happened to me too. =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: <sko...@up...> - 2004-10-24 21:40:10
|
> [root - uml]# ./linux-2.6.9uml ubd0=./rootfs/root_fs.http-ssh-myqsl > mem=256M con0=fd:0,fd:1 > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > > [1]+ Stopped ./linux-2.6.9uml > ubd0=./rootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:0,fd:1 > ** This looks like a problem i had too! It was caused by compiling/running the kernel on a NPTL-enabled system. So i downgraded to a non-NPTL-glibc, and everything worked fine again. On the other hand, i'm having problems with linux 2.6.9 UML too. For example if i run it without any command-line-paramter, the kernel starts, and should complain about a non-existing rootfs, but the kernel just hangs. |
From: Antoine M. <an...@na...> - 2004-10-25 02:13:18
|
On Sun, 2004-10-24 at 15:13 +0100, Antoine Martin wrote: > > > make linux ARCH=um > > > > So the UML patches are now in the official 2.6.9 kernel from kernel.org? > > And i can build a UML without any additional patches now? > > Blaisorblade said it should work, but I can't make it work. more details below > Blaisorblade, did you mention a new FAQ or help page? Sorry! I found it on the archived list. DOH! (I must have missed a digest) But I still have the same problem running it (see previous email quoted) I also tried it on amd64, but it doesn't build. So I tried applying all the patches I could find on the patches page, and it still doesn't build (goes slightly further): /usr/src/linux-2.6.9uml/arch/um/Makefile:159: warning: overriding commands for target `arch/um/kernel/vmlinux.lds.S' /usr/src/linux-2.6.9uml/arch/um/Makefile:106: warning: ignoring old commands for target `arch/um/kernel/vmlinux.lds.S' CHK include/linux/version.h UPD include/linux/version.h SYMLINK include/asm -> include/asm-um SPLIT include/linux/autoconf.h -> include/config/* scripts/Makefile.build:13: /Makefile: No such file or directory scripts/Makefile.build:64: kbuild: Makefile.build is included improperly make[1]: *** No rule to make target `/Makefile'. Stop. make: *** [/mk_sc] Error 2 Anyone got any patches or instructions to make it build and run on amd64? The last kernel I could build for this platform is 2.6.4-bk? and it is quite old and very buggy (and does not play well with latest host kernels) Whilst I was at it, I tried applying the same patches on a i386 build: gcc -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno- common -O2 -fomit-frame-pointer -Wdeclaration-after-statement -U__i386__ -Ui386 -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE -fno- unit-at-a-time -Iarch/um/include - I/usr/src/linux-2.6.9uml-22-10-2004/arch/um/kernel/skas/include - D_GNU_SOURCE -c -o arch/um/os-Linux/signal.o arch/um/os-Linux/signal.c arch/um/os-Linux/signal.c: In function `sig_handler': arch/um/os-Linux/signal.c:16: warning: implicit declaration of function `CHOOSE_MODE_PROC' arch/um/os-Linux/signal.c:16: error: `sig_handler_common_tt' undeclared (first use in this function) arch/um/os-Linux/signal.c:16: error: (Each undeclared identifier is reported only once arch/um/os-Linux/signal.c:16: error: for each function it appears in.) arch/um/os-Linux/signal.c: In function `alarm_handler': arch/um/os-Linux/signal.c:32: error: `sig_handler_common_tt' undeclared (first use in this function) make[1]: *** [arch/um/os-Linux/signal.o] Error 1 make: *** [arch/um/os-Linux] Error 2 Cheers Antoine > I assumed that what I was seeing was due to the missing target. > I can run the binary created by make vmlinux, but it stops right at the > start (but it does not die): > ** > [root - uml]# ./linux-2.6.9uml ubd0=./rootfs/root_fs.http-ssh-myqsl > mem=256M con0=fd:0,fd:1 > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > > [1]+ Stopped ./linux-2.6.9uml > ubd0=./rootfs/root_fs.http-ssh-myqsl mem=256M con0=fd:0,fd:1 > ** > > And the processes are there, just defunct: > ** > root 7961 7877 0 14:58 pts8 00:00:00 ./linux-2.6.9uml > ubd0=root_fs mem=256M con > root 7963 7961 0 14:58 pts8 00:00:00 [linux-2.6.9uml] > <defunct> > ** > I can bring the process back to the foreground with 'fg' but it does not > help (being <defunct> by then) > Should I try with TT and not skas? > > Cheers > Antoine |