From rob at landley.net Mon Mar 5 17:03:33 2012 From: rob at landley.net (Rob Landley) Date: Mon, 05 Mar 2012 11:03:33 -0600 Subject: [Aboriginal] aboriginal lx questions In-Reply-To: References: Message-ID: <4F54F1E5.2020801@landley.net> On 03/05/2012 07:30 AM, Darren Mackay wrote: > I recently found your aboriginal linux build scripts. I have previously > used buildroot which I found to be bloated for my needs, and yocto, which > is perhaps too complex also. > > Just wondering what your thoughts are on using earlier kernel versions > with the current release of aboriginal linux? Go for it? It should mostly just work... Your largest problem is going to be sources/patches/linux-*.patch not applying. You can delete the three linux-noperl-*.patch files if you export HOST_EXTRA=perl (or set it in config) to tell the build to use perl out of the host environment. (The resulting system won't be able to entirely rebuild itself under itself unless you first build/install perl, but I doubt you care. And if your kernel is before 2.6.25 it didn't require perl anyway, this is relatively recent brain-damage from Peter Anvin.) The rest of the patches are target-specific, and you can probably just delete them all if your kernel already works for the board you want to run it on. (The ones with arm/sh4/mips in the name are obvious. The pmacorder one is for powerpc. The bootraw one is mips. The ubi one fixes a 3.2 bug that doesn't apply to earlier kernels anyway...) Everything else should probably just work for a 2.6 kernel. Other than patches in sources/patches not applying, the only version-specific bit in aboriginal linux is the url in download.sh. Everything else is as version-agnostic as I can make it. For a 2.4 kernel, you won't have "make headers_install". (Actually before around 2.6.15 you won't have that.) So you'll need to modify sources/sections/linux-headers.sh to install your kernel headers instead of running make headers_install if you go that far back. Let me know how it goes, Rob 1330967013.0 From rob at landley.net Fri Mar 16 12:05:46 2012 From: rob at landley.net (Rob Landley) Date: Fri, 16 Mar 2012 07:05:46 -0500 Subject: [Aboriginal] I Live! Message-ID: <4F632C9A.1070904@landley.net> Sorry for the radio silence, between day job, buying a new house, and toybox all my spare time's been taken up with other things recently. That said, it's about time for a new kernel release and I try to keep up to date with those. Plus uClibc 0.9.33 is out and I should move to that. I believe I have two pending todo items: ccwrap should wrap cpp, and distcc isn't working reliably? Sigh. Distcc is a chronic problem: there's version skew on various hosts and its diagnostics when something goes wrong are horrible (no explanation of what the PROBLEM was). I've been meaning to write my own replacement for years, what it does is reasonably simple... Lemme see what I can get done this weekend, Rob 1331899546.0 From rob at landley.net Sat Mar 17 02:38:20 2012 From: rob at landley.net (Rob Landley) Date: Fri, 16 Mar 2012 21:38:20 -0500 Subject: [Aboriginal] mdadm issue, including qemu images. In-Reply-To: <4F63BFA2.3040301@gmail.com> References: <4F63BFA2.3040301@gmail.com> Message-ID: <4F63F91C.2000900@landley.net> On 03/16/2012 05:33 PM, Piotr Karbowski wrote: > Attached two qemu images, one contain bootloader (extlinux), initramfs > (better-initramfs v0.5 + your strace binary) and kernel and another is > empty raid1 array with one device set as missing, without any filesystem > on it, you can run it via: > > qemu-kvm -hda better-initramfs-boot.qcow2 -hdb small-raid1.qcow2 > > If you wish to test it more, you can grab better-initramfs from > github.com/slashbeast/better-initramfs, it should be failry easy to use, > before 'make image' you can place whatever you want in sourceroot/ dir, > then replace output/initramfs.cpio.gz with the one inside > better-initramfs-boot.qcow2 and you should be good. mknod("/dev/.tmp.md.785:8:17", S_IFBLK|0600, makedev(8, 17,)) = 0 open("/dev/.tmp.md.785:8:17", O_RDWR|O_EXCL|O_DIRECT|O_LARGEFILE) = 6 ioctl(6, BLKPG, 0xbfd22f88) = -1 EINVAL Last line repeated bunches of times. According to linux/blkpg.h BLKPG is some random constant (_IO(0x1s,105)) and then the argument is: struct blkpg_ioctl_arg { int op; int flags; int datalen; void *data; }; And then it gets complicated. Since strace isn't dumping the associated structure argument, so I need to rebuild the command and stick printf() calls into it to dump out the structure contents. Where do I get mdadm and is there anything to building it other than ./configure; make; make install? Rob 1331951900.0 From rob at landley.net Mon Mar 19 00:11:01 2012 From: rob at landley.net (Rob Landley) Date: Sun, 18 Mar 2012 19:11:01 -0500 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: References: Message-ID: <4F667995.9030507@landley.net> On 03/17/2012 03:35 PM, Denys Vlasenko wrote: > I've got a native-compiler build failure, > dug a bit deeper, and here what I found: > > The failure happens when we try to run libstdc++-v3 configure. Um, what's the symptom? (There's an error message?) Building for which target, from which host, presumably using hg-tip, etc... In _theory_ the native-compiler stage has been through host-tools.sh and the airlock step put only busybox in the $PATH, and you're testing with a new busybox version hence the altered behavior? (I'm guessing here. It'll also reach out and take #!/bin/sh and such off the host so distro does still matter a bit...) > I added a shell invocation to experiment > interactively just before failing command: > > build/packages/gcc-core/Makefile.in > > configure-target-libstdc++-v3: > ... > srcdiroption="--srcdir=$${topdir}/libstdc++-v3"; \ > libsrcdir="$$s/libstdc++-v3"; \ > rm -f no-such-file || : ; \ > DBG==> sh /dev/tty 2>&1; \ > FAIL=> CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \ > $(TARGET_CONFIGARGS) $${srcdiroption} \ > || exit 1 > @endif target-libstdc++-v3 Huh. $$ should be current shell PID and then I'd think {srcdiroption} would be passed through verbatim, but that's just a guess. Weird construction, there... Ah, _make_. Ok, so $$ becomes literal $ but $(SHELL) and $(TARGET_CONFIGARGS) are both interpreted as make variables. So from the "FAIL" line's point of view, those are evaluated before the exec() and then the other two are evaluated after by the shell make runs. The above construction is COMPLETELY INSANE because make will _run_ each of its commands through $(SHELL) so if $(SHELL) is /bin/hush and $(TARGET_CONFIGARGS) is "fruit juice" make will do '/bin/hush -c "CONFIG_SITE=no-such-file /bin/hush ${libsrcdir}/configure fruit juice ${srcdiroption} || exit 1"' Which seems kinda roundabout, but *shrug*. > So, I sit in my debug sh session: > > $ ls -l /bin/sh > lrwxrwxrwx 1 root root 4 Dec 7 15:39 /bin/sh -> bash > ls -l /bin/bash > -rwxr-xr-x 1 root root 888112 Nov 24 23:00 /bin/bash > > Invocation of /bin/sh by configure script's #!/bin/sh > will try to load my host's /bin/bash. The problem is, > > (running in another, ordinary host shell w/o tweaked environment, > so that /usr/bin/ldd is accessible and works:) > $ ldd /bin/bash > linux-gate.so.1 => (0xb776d000) > libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000) > libdl.so.2 => /lib/libdl.so.2 (0xb7754000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000) > libc.so.6 => /lib/libc.so.6 (0xb75a6000) > /lib/ld-linux.so.2 (0xb776e000) > > At this point in build process LD_LIBRARY_PATH is set: > > $ env | grep LIBRARY > LD_LIBRARY_PATH=/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libstdc++-v3/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libmudflap/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libssp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libgomp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./gcc:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./prev-gcc Huh. I wonder who set that? grep LD_LIBRARY_PATH *.sh sources/*.sh sources/sections/*.sh No hits there. Hmmm... build/packages/gcc-core/config-ml.in: ml_config_env="$ml_config_env LD_LIBRARY_PATH=$LD_LIBRARY_PATH_" Ok, I guess that then? > and the following file exists: > > /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1 Built by gcc itself, presumably during this very compile run or it wouldn't still be in temp-i686. > Second-to-last LD_LIBRARY_PATH element points to that dir. > Attempt to load /bin/sh -> /bin/bash will load wrong libgcc_s.so.1, > and we end up with: > > /bin/sh: error while loading shared libraries: libc.so.0: cannot open > shared object file: No such file or directory Do you have an /etc/profile that's unsetting LD_LIBRARY_PATH? I note that when you call bash via the name "sh", the behavior is different. From the bash man page: --norc Do not read and execute the system wide initialization file /etc/bash.bashrc and the personal initialization file ~/.bashrc if the shell is interactive. This option is on by default if the shell is invoked as sh. Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1332115861.0 From piotr.karbowski at gmail.com Sat Mar 17 15:57:14 2012 From: piotr.karbowski at gmail.com (Piotr Karbowski) Date: Sat, 17 Mar 2012 16:57:14 +0100 Subject: [Aboriginal] mdadm issue, including qemu images. In-Reply-To: <4F63F91C.2000900@landley.net> References: <4F63BFA2.3040301@gmail.com> <4F63F91C.2000900@landley.net> Message-ID: <4F64B45A.9090102@gmail.com> On 03/17/2012 03:38 AM, Rob Landley wrote: > mknod("/dev/.tmp.md.785:8:17", S_IFBLK|0600, makedev(8, 17,)) = 0 > open("/dev/.tmp.md.785:8:17", O_RDWR|O_EXCL|O_DIRECT|O_LARGEFILE) = 6 > ioctl(6, BLKPG, 0xbfd22f88) = -1 EINVAL > > Last line repeated bunches of times. > > According to linux/blkpg.h BLKPG is some random constant (_IO(0x1s,105)) > and then the argument is: > > struct blkpg_ioctl_arg { > int op; > int flags; > int datalen; > void *data; > }; > > And then it gets complicated. Since strace isn't dumping the associated > structure argument, so I need to rebuild the command and stick printf() > calls into it to dump out the structure contents. > > Where do I get mdadm and is there anything to building it other than > ./configure; make; make install? You can use better-initramfs's scripts, like cd better-initramfs/bootstrap and: ./lebuild init i686 ./lebuild build mdadm first will fetch and unpack aboriginal i686 into build_dir/ next will unpack sources and build it into chroot, thus it need to be run as root. the scripts to build mdadm are in lebuilds/mdadm.lebuild, if you have any patches you can place it under patches/mdadm/ and lebuild will apply them. after build mdadm the mdadm binary will be in output/mdadm repo https://slashbeast at github.com/slashbeast/better-initramfs.git -- Piotr. 1331999834.0 From vda.linux at googlemail.com Sat Mar 17 20:35:23 2012 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Sat, 17 Mar 2012 21:35:23 +0100 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: References: Message-ID: I've got a native-compiler build failure, dug a bit deeper, and here what I found: The failure happens when we try to run libstdc++-v3 configure. I added a shell invocation to experiment interactively just before failing command: build/packages/gcc-core/Makefile.in configure-target-libstdc++-v3: ? ? ? ?... ? ? ? ?srcdiroption="--srcdir=$${topdir}/libstdc++-v3"; \ ? ? ? ?libsrcdir="$$s/libstdc++-v3"; \ ? ? ? ?rm -f no-such-file || : ; \ DBG==> ?sh /dev/tty 2>&1; \ FAIL=> ?CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \ ? ? ? ? ?$(TARGET_CONFIGARGS) $${srcdiroption} ?\ ? ? ? ? ?|| exit 1 @endif target-libstdc++-v3 So, I sit in my debug sh session: $ ls -l /bin/sh lrwxrwxrwx ? ?1 root ? ? root ? ? ? ? ? ? 4 Dec ?7 15:39 /bin/sh -> bash ls -l /bin/bash -rwxr-xr-x ? ?1 root ? ? root ? ? ? ?888112 Nov 24 23:00 /bin/bash Invocation of /bin/sh by configure script's #!/bin/sh will try to load my host's /bin/bash. The problem is, (running in another, ordinary host shell w/o tweaked environment, so that /usr/bin/ldd is accessible and works:) $ ldd /bin/bash ? ? ? ?linux-gate.so.1 => ?(0xb776d000) ? ? ? ?libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000) ? ? ? ?libdl.so.2 => /lib/libdl.so.2 (0xb7754000) ? ? ? ?libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000) ? ? ? ?libc.so.6 => /lib/libc.so.6 (0xb75a6000) ? ? ? ?/lib/ld-linux.so.2 (0xb776e000) At this point in build process LD_LIBRARY_PATH is set: $ env | grep LIBRARY LD_LIBRARY_PATH=/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libstdc++-v3/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libmudflap/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libssp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libgomp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./gcc:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./prev-gcc and the following file exists: /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1 Second-to-last LD_LIBRARY_PATH element points to that dir. Attempt to load /bin/sh -> /bin/bash will load wrong libgcc_s.so.1, and we end up with: /bin/sh: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory -- vda 1332016523.0 From vda.linux at googlemail.com Mon Mar 19 03:28:49 2012 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 19 Mar 2012 04:28:49 +0100 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: <4F667995.9030507@landley.net> References: <4F667995.9030507@landley.net> Message-ID: <201203190428.50009.vda.linux@googlemail.com> On Monday 19 March 2012 01:11, Rob Landley wrote: > On 03/17/2012 03:35 PM, Denys Vlasenko wrote: > > I've got a native-compiler build failure, > > dug a bit deeper, and here what I found: > > > > The failure happens when we try to run libstdc++-v3 configure. > > Um, what's the symptom? (There's an error message?) Building for which > target, from which host, presumably using hg-tip, etc... The message is: /bin/sh: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory Basically, it means that attempt to load /bin/sh failed; and since we see a library name which is not supposed to be there, it strongly suggest that library search path is screwed. hg-tip. Fedora 16. > In _theory_ the native-compiler stage has been through host-tools.sh and > the airlock step put only busybox in the $PATH, and you're testing with > a new busybox version hence the altered behavior? (I'm guessing here. > It'll also reach out and take #!/bin/sh and such off the host so distro > does still matter a bit...) $PATH is not consulted when kernel processes #!/bin/sh of configure script's first line; neither it will be considered if $(SHELL) resolves to absolute name. > > I added a shell invocation to experiment > > interactively just before failing command: > > > > build/packages/gcc-core/Makefile.in > > > > configure-target-libstdc++-v3: > > ... > > srcdiroption="--srcdir=$${topdir}/libstdc++-v3"; \ > > libsrcdir="$$s/libstdc++-v3"; \ > > rm -f no-such-file || : ; \ > > DBG==> sh /dev/tty 2>&1; \ > > FAIL=> CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \ > > $(TARGET_CONFIGARGS) $${srcdiroption} \ > > || exit 1 > > @endif target-libstdc++-v3 > > Huh. $$ should be current shell PID and then I'd think {srcdiroption} > would be passed through verbatim, but that's just a guess. Weird > construction, there... > > Ah, _make_. Ok, so $$ becomes literal $ but $(SHELL) and > $(TARGET_CONFIGARGS) are both interpreted as make variables. So from > the "FAIL" line's point of view, those are evaluated before the exec() > and then the other two are evaluated after by the shell make runs. > > The above construction is COMPLETELY INSANE because make will _run_ each > of its commands through $(SHELL) so if $(SHELL) is /bin/hush and > $(TARGET_CONFIGARGS) is "fruit juice" make will do '/bin/hush -c > "CONFIG_SITE=no-such-file /bin/hush ${libsrcdir}/configure fruit juice > ${srcdiroption} || exit 1"' > > Which seems kinda roundabout, but *shrug*. I think it will run entire multi-line (\-continuated) make command via sh -c CMD, not just the part I indicated as "FAIL". > > So, I sit in my debug sh session: > > > > $ ls -l /bin/sh > > lrwxrwxrwx 1 root root 4 Dec 7 15:39 /bin/sh -> bash > > ls -l /bin/bash > > -rwxr-xr-x 1 root root 888112 Nov 24 23:00 /bin/bash > > > > Invocation of /bin/sh by configure script's #!/bin/sh > > will try to load my host's /bin/bash. The problem is, > > > > (running in another, ordinary host shell w/o tweaked environment, > > so that /usr/bin/ldd is accessible and works:) > > $ ldd /bin/bash > > linux-gate.so.1 => (0xb776d000) > > libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000) > > libdl.so.2 => /lib/libdl.so.2 (0xb7754000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000) > > libc.so.6 => /lib/libc.so.6 (0xb75a6000) > > /lib/ld-linux.so.2 (0xb776e000) > > > > At this point in build process LD_LIBRARY_PATH is set: > > > > $ env | grep LIBRARY > > LD_LIBRARY_PATH=/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libstdc++-v3/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libmudflap/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libssp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libgomp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./gcc:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./prev-gcc > > Huh. I wonder who set that? Presumably, gcc or libstdc++-v3 build machinery. > grep LD_LIBRARY_PATH *.sh sources/*.sh sources/sections/*.sh > > No hits there. Hmmm... > > build/packages/gcc-core/config-ml.in: ml_config_env="$ml_config_env > LD_LIBRARY_PATH=$LD_LIBRARY_PATH_" > > Ok, I guess that then? Probably. > > and the following file exists: > > > > /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1 > > Built by gcc itself, presumably during this very compile run or it > wouldn't still be in temp-i686. Yes. > > Second-to-last LD_LIBRARY_PATH element points to that dir. > > Attempt to load /bin/sh -> /bin/bash will load wrong libgcc_s.so.1, > > and we end up with: > > > > /bin/sh: error while loading shared libraries: libc.so.0: cannot open > > shared object file: No such file or directory > > Do you have an /etc/profile that's unsetting LD_LIBRARY_PATH? It should not be relevant. Failure happens before /bin/sh has a chance to run anything. -- vda 1332127729.0 From rob at landley.net Mon Mar 19 14:22:37 2012 From: rob at landley.net (Rob Landley) Date: Mon, 19 Mar 2012 09:22:37 -0500 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: <201203190428.50009.vda.linux@googlemail.com> References: <4F667995.9030507@landley.net> <201203190428.50009.vda.linux@googlemail.com> Message-ID: <4F67412D.8050302@landley.net> On 03/18/2012 10:28 PM, Denys Vlasenko wrote: > On Monday 19 March 2012 01:11, Rob Landley wrote: >> On 03/17/2012 03:35 PM, Denys Vlasenko wrote: >>> I've got a native-compiler build failure, >>> dug a bit deeper, and here what I found: >>> >>> The failure happens when we try to run libstdc++-v3 configure. >> >> Um, what's the symptom? (There's an error message?) Building for which >> target, from which host, presumably using hg-tip, etc... > > The message is: > > /bin/sh: error while loading shared libraries: libc.so.0: cannot open > shared object file: No such file or directory > > Basically, it means that attempt to load /bin/sh failed; > and since we see a library name which is not supposed to be there, > it strongly suggest that library search path is screwed. > > hg-tip. > > Fedora 16. Hang on. libc.so.0 is uClibc. /bin/sh is the host shell. And you're running Fedora 16? Something doesn't add up here... >>> srcdiroption="--srcdir=$${topdir}/libstdc++-v3"; \ >>> libsrcdir="$$s/libstdc++-v3"; \ >>> rm -f no-such-file || : ; \ >>> DBG==> sh /dev/tty 2>&1; \ >>> FAIL=> CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \ >>> $(TARGET_CONFIGARGS) $${srcdiroption} \ >>> || exit 1 >>> @endif target-libstdc++-v3 >> >> Huh. $$ should be current shell PID and then I'd think {srcdiroption} >> would be passed through verbatim, but that's just a guess. Weird >> construction, there... >> >> Ah, _make_. Ok, so $$ becomes literal $ but $(SHELL) and >> $(TARGET_CONFIGARGS) are both interpreted as make variables. So from >> the "FAIL" line's point of view, those are evaluated before the exec() >> and then the other two are evaluated after by the shell make runs. >> >> The above construction is COMPLETELY INSANE because make will _run_ each >> of its commands through $(SHELL) so if $(SHELL) is /bin/hush and >> $(TARGET_CONFIGARGS) is "fruit juice" make will do '/bin/hush -c >> "CONFIG_SITE=no-such-file /bin/hush ${libsrcdir}/configure fruit juice >> ${srcdiroption} || exit 1"' >> >> Which seems kinda roundabout, but *shrug*. > > I think it will run entire multi-line (\-continuated) > make command via sh -c CMD, not just the part I indicated as "FAIL". Of course. But the way sh out of the path works and #!/bin/sh doesn't is interesting. Presumably that's busybox ash. >>> So, I sit in my debug sh session: >>> >>> $ ls -l /bin/sh >>> lrwxrwxrwx 1 root root 4 Dec 7 15:39 /bin/sh -> bash >>> ls -l /bin/bash >>> -rwxr-xr-x 1 root root 888112 Nov 24 23:00 /bin/bash >>> >>> Invocation of /bin/sh by configure script's #!/bin/sh >>> will try to load my host's /bin/bash. The problem is, >>> >>> (running in another, ordinary host shell w/o tweaked environment, >>> so that /usr/bin/ldd is accessible and works:) >>> $ ldd /bin/bash >>> linux-gate.so.1 => (0xb776d000) >>> libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000) >>> libdl.so.2 => /lib/libdl.so.2 (0xb7754000) >>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000) >>> libc.so.6 => /lib/libc.so.6 (0xb75a6000) >>> /lib/ld-linux.so.2 (0xb776e000) None of which are libc.so.0. >>> At this point in build process LD_LIBRARY_PATH is set: >>> >>> $ env | grep LIBRARY >>> LD_LIBRARY_PATH=/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libstdc++-v3/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libmudflap/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libssp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libgomp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./gcc:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./prev-gcc >> >> Huh. I wonder who set that? > > Presumably, gcc or libstdc++-v3 build machinery. > >> grep LD_LIBRARY_PATH *.sh sources/*.sh sources/sections/*.sh >> >> No hits there. Hmmm... >> >> build/packages/gcc-core/config-ml.in: ml_config_env="$ml_config_env >> LD_LIBRARY_PATH=$LD_LIBRARY_PATH_" >> >> Ok, I guess that then? > > Probably. > > >>> and the following file exists: >>> >>> /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1 Ok, libgcc_s.so.1 is presumably the file that's linked against libc.so.0 (which is why buildroot happened in the first place). And bash is getting confused because the build is including a _target_ version of libc.so.0 in the _host_ LD_LIBRARY_PATH (which is just as wrong when linked against uClibc as it would be if it was an arm binary). So how is all this inappropriate crap winding up in LD_LIBRARY_PATH? This is why I set CROSS_HOST=`uname -m`-walrus-linux and use $ARCH-unknown-linux as the target, so the names will NEVER match and it will always be forced down the full cross compiling path instead of taking stupid shortcuts. >> Built by gcc itself, presumably during this very compile run or it >> wouldn't still be in temp-i686. > > Yes. > > >>> Second-to-last LD_LIBRARY_PATH element points to that dir. >>> Attempt to load /bin/sh -> /bin/bash will load wrong libgcc_s.so.1, >>> and we end up with: >>> >>> /bin/sh: error while loading shared libraries: libc.so.0: cannot open >>> shared object file: No such file or directory >> >> Do you have an /etc/profile that's unsetting LD_LIBRARY_PATH? > > It should not be relevant. Failure happens before /bin/sh > has a chance to run anything. I'm going to have to install Fedora Core 16 in a VM and try to reproduce this breakage... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1332166957.0 From vda.linux at googlemail.com Mon Mar 19 14:33:19 2012 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 19 Mar 2012 15:33:19 +0100 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: <4F67412D.8050302@landley.net> References: <4F667995.9030507@landley.net> <201203190428.50009.vda.linux@googlemail.com> <4F67412D.8050302@landley.net> Message-ID: On Mon, Mar 19, 2012 at 3:22 PM, Rob Landley wrote: >>>> Invocation of /bin/sh by configure script's #!/bin/sh >>>> will try to load my host's /bin/bash. The problem is, >>>> >>>> (running in another, ordinary host shell w/o tweaked environment, >>>> so that /usr/bin/ldd is accessible and works:) >>>> $ ldd /bin/bash >>>> ? ? ? ?linux-gate.so.1 => ?(0xb776d000) >>>> ? ? ? ?libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000) >>>> ? ? ? ?libdl.so.2 => /lib/libdl.so.2 (0xb7754000) >>>> ? ? ? ?libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000) >>>> ? ? ? ?libc.so.6 => /lib/libc.so.6 (0xb75a6000) >>>> ? ? ? ?/lib/ld-linux.so.2 (0xb776e000) > > None of which are libc.so.0. A wrong libgcc_s.so.1 is picked up from LD_LIBRARY_PATH, and _it_ requests libc.so.0 >>>> /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1 > > Ok, libgcc_s.so.1 is presumably the file that's linked against libc.so.0 > (which is why buildroot happened in the first place). Yes. > And bash is getting confused because the build is including a _target_ > version of libc.so.0 in the _host_ LD_LIBRARY_PATH (which is just as > wrong when linked against uClibc as it would be if it was an arm binary). Yes. > So how is all this inappropriate crap winding up in LD_LIBRARY_PATH? > This is why I set CROSS_HOST=`uname -m`-walrus-linux and use > $ARCH-unknown-linux as the target, so the names will NEVER match and it > will always be forced down the full cross compiling path instead of > taking stupid shortcuts. I know, it's a giant PITA to beat gcc into not doing this :/ -- vda 1332167599.0 From hoan at wanadoo.fr Fri Mar 23 07:13:50 2012 From: hoan at wanadoo.fr (wangji) Date: Fri, 23 Mar 2012 08:13:50 +0100 Subject: [Aboriginal] elf header help Message-ID: <1332486830.2339.16.camel@ubuntu.lan> dear oldpal FirmwareLinux ! I have always been intrigued by the ELF header ,without never been able to clarify myself for understanding ! To be concise : using mipsel_rootfs from 1 openwrt (a.k.a kamikaze 7/8.x mipsel) 2 firmwareLinux_mipsel_rootfs (old one 2009,but I guess won't change with more recent version) I can only use qemu-mipsel-static from_ubuntu_nattty_10.04/10 to recognise FirmwareLinux_busybox But for openwrt_kamikaze_mipsel I need my own qemu-mipsel-static , -I don't remember how I got it (either I had compiled it or I had from google on some Portuguese site -people working on Nokia's embedded stuffs ) Could you give me a guide line how to examine this problem Here how I tested different cases : I just copy qemu-mipsel-static into mipsel_rootfs/usr/bin/ then from my ubuntu's_inside_that_mipsel_rootfs : chroot . /bin/busybox to run mips_busybox locally. (my ubuntu had binfmt-support + qemu_installed from synaptic_ubuntu by default) thanks 1332486830.0 From rob at landley.net Fri Mar 23 22:43:08 2012 From: rob at landley.net (Rob Landley) Date: Fri, 23 Mar 2012 17:43:08 -0500 Subject: [Aboriginal] elf header help In-Reply-To: <1332486830.2339.16.camel@ubuntu.lan> References: <1332486830.2339.16.camel@ubuntu.lan> Message-ID: <4F6CFC7C.4090900@landley.net> On 03/23/2012 02:13 AM, wangji wrote: > dear oldpal FirmwareLinux ! > > I have always been intrigued by the ELF header ,without never been able > to clarify myself for understanding ! The best conceptual introduction to ELF headers is: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html > To be concise : > using mipsel_rootfs from > 1 openwrt (a.k.a kamikaze 7/8.x mipsel) > 2 firmwareLinux_mipsel_rootfs (old one 2009,but I guess won't change > with more recent version) > > I can only use qemu-mipsel-static from_ubuntu_nattty_10.04/10 to > recognise FirmwareLinux_busybox Have you tried the busybox binaries I put on http://busybox.net/downloads/binaries/latest There should be a mipsel one there... > But for openwrt_kamikaze_mipsel I need my own qemu-mipsel-static , > -I don't remember how I got it (either I had compiled it or I had from > google on some Portuguese site -people working on Nokia's embedded > stuffs ) > Could you give me a guide line how to examine this problem *shrug* I use system images with system emulation, not chroots with application emulation. I haven't played with this recently. Presumably current versions work, most likely your dynamic linker path's getting misinterpreted. > Here how I tested different cases : > I just copy qemu-mipsel-static into mipsel_rootfs/usr/bin/ > then from my ubuntu's_inside_that_mipsel_rootfs : > > chroot . /bin/busybox > > to run mips_busybox locally. I submitted a patch to get qemu to do its own chroot long ago: http://www.mail-archive.com/qemu-devel at nongnu.org/msg16297.html I believe it got merged. You need to do the chroot before you exec a binary in order to get the dynamic linker path to be out of the new chroot (since it's an absolute path), but you need to run qemu in order to run the mips binary, which implies an x86 qemu binary has to be _in_ the (otherwise mips) chroot... > (my ubuntu had binfmt-support + qemu_installed from synaptic_ubuntu by > default) > thanks Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1332542588.0 From rob at landley.net Sun Mar 25 16:26:49 2012 From: rob at landley.net (Rob Landley) Date: Sun, 25 Mar 2012 11:26:49 -0500 Subject: [Aboriginal] Interesting case of aboriginal build failure In-Reply-To: References: <4F667995.9030507@landley.net> <201203190428.50009.vda.linux@googlemail.com> <4F67412D.8050302@landley.net> Message-ID: <4F6F4749.20007@landley.net> On 03/19/2012 09:33 AM, Denys Vlasenko wrote: >> So how is all this inappropriate crap winding up in LD_LIBRARY_PATH? >> This is why I set CROSS_HOST=`uname -m`-walrus-linux and use >> $ARCH-unknown-linux as the target, so the names will NEVER match and it >> will always be forced down the full cross compiling path instead of >> taking stupid shortcuts. > > I know, it's a giant PITA to beat gcc into not doing this :/ I finally reproduced this under a fedora image, I hope to get some time to debug it properly later today... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one. 1332692809.0