[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKfGGh20HySR4v7LDGbfgE1LsSk+OcepuyDJOhLh-hGgXgz2oQ@mail.gmail.com>
Date: Wed, 31 Dec 2014 20:49:06 +0100
From: "piranna@...il.com" <piranna@...il.com>
To: musl@...ts.openwall.com
Subject: Re: Failed to execute /init (error -2) for system-wide musl libc
> i think if static init works then try to use
> that to boot up the system and then debug the
> dynamic case..
It's a good idea, didn't though about it :-)
> you can run libc.so with a dynamic executable
> as argument then you can debug the loader
Definitely I can be able to use Node.js child_process module to launch
libc.so, I'll try it :-)
> if you have no debug tools on the target then
> i think you can add dprintf's to early loader
> code in src/ldso/dynlink.c which may help in
> figuring out what fails
It's just a Node.js REPL, so no debug tools here (at least, no C ones,
like GDB), but knowing that src/ldso/dynlink.c has the code of the
dynamic linker, add some debug printf's seems a good idea, I believe
although it's in the boot process it should write some output to the
console...
>> executables compiled with the cross-toolchain works on our desktops
>> but they don't on QEmu, and we've added all the dynamic libraries that
>> readelf request (only libc.so, libstdc++.so & libgcc_s.so). As a
>
> libgcc_s.so shouldnt be needed
It's shown as a dependency of libstdc++.so both by ldd and readelf -d.
Maybe could this be the issue? Both libstdc++.so & libgcc_s.so are
compiled against musl...
>> curious side note, when installing the musl-linked gcc libraries, the
>> /lib/ld-musl-i386.so.1 link dissapear from the cross-toochain folder,
>
> sounds like a clfs buildsystem issue
Or CLFS, or gcc, but it's something curious because before the
compilation of libstdc++.so & libgcc_s.so against musl the symbolic
link is there, and after compile them the symbolic link has
dissapear... It doesn't makes sense... :-/
> i've seen the symlink disappearing on openwrt buildsystem once
> (that one was not deterministic) i'm not sure what caused it
In my case is deterministic, allways happens on the libstdc++.so &
libgcc_s.so generation step (more exactly, the make install on the
cross-toolchain directory), checked by doing them by hand :-/
--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
