telinit in current snapshot

2012-08-11 Thread jimux
I am attempting to cross-compile an SH4 version of the current snapshot for a satellite set top box. All other tools work fine, but attempts to restart init from a telnet session (ie init 4: sleep 8: enigma2 ) fail with a 'init must be PID1' message. I do have a 'ln -sf /bin/busybox

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi Tito ! Had to modify the script a little Doesn't matter. The gawk check was just for comparison. # use prefered applet feature awk awk -f w.awk w.txt This is the one still failing on my side :-( Did you use my configuration to compile your Busybox binary? Which gcc and glibc versions?

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread walter harms
Am 11.08.2012 11:23, schrieb Harald Becker: Hi Tito ! Had to modify the script a little Doesn't matter. The gawk check was just for comparison. # use prefered applet feature awk awk -f w.awk w.txt This is the one still failing on my side :-( Did you use my configuration to

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi Walter ! perhaps you can create a busybox with awk only ? That wont't help. If Busybox awk is called direct or via symlink it works correct. The problem arrise with the standalone/preferred applet feature. Which I really want to work, as Busybox sit on a System with most GNU utilities

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Michael Tokarev
On 11.08.2012 14:03, Harald Becker wrote: Hi Walter ! perhaps you can create a busybox with awk only ? That wont't help. If Busybox awk is called direct or via symlink it works correct. The problem arrise with the standalone/preferred applet feature. Which I really want to work, as

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi Michael ! PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Sure, it is possible to create a directory with all the symlinks to Busybox ... but that's definitely not what I want. I used this prefer applet feature for a long time within my

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread walter harms
Am 11.08.2012 12:36, schrieb Harald Becker: Hi Michael ! PATH=/busybox:$PATH ./busybox.shell.script where /busybox contains (sym)links for all busybox applets. Sure, it is possible to create a directory with all the symlinks to Busybox ... but that's definitely not what I want. I

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi Tito ! GNU C Library (Debian EGLIBC 2.11.3-3) stable release version 2.11.3, Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.32 system on 2012-02-13. ./busybox BusyBox v1.21.0.git (2012-08-10 21:15:09 CEST) multi-call binary. BusyBox is copyrighted by many authors between 1998-2012.

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Tito
On Saturday 11 August 2012 18:20:29 Harald Becker wrote: Hi Tito ! GNU C Library (Debian EGLIBC 2.11.3-3) stable release version 2.11.3, Compiled by GNU CC version 4.4.5. Compiled on a Linux 2.6.32 system on 2012-02-13. ./busybox BusyBox v1.21.0.git (2012-08-10 21:15:09 CEST) multi-call

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi Walter ! I have no idea about your environment, but i had a similar problem some time ago and found mount --bind handy. My current system was the first approach to this vserver like installation. Over the time it summed up of over 100 active mount --bind ... and I'm planing to reorganize and

Re: Busybox awk throws glibc failure if using standalone/preferred applet feature

2012-08-11 Thread Harald Becker
Hi All ! I think some strace or gdb or valgrind is needed to see what this memory refers to. As this machine is not installed for development those debugging aids are not available ... but I fiddled a bit and got strace running ... ... first result: Running the script via strace did not trigger