From: "Matias A. Fonzo" <selk@dragora.org>
To: "piranna@gmail.com" <piranna@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: Failed to execute /init (error -2) for system-wide musl libc
Date: Wed, 31 Dec 2014 17:08:52 -0300 [thread overview]
Message-ID: <20141231170852.7e17953d@dragora.org> (raw)
In-Reply-To: <CAKfGGh20HySR4v7LDGbfgE1LsSk+OcepuyDJOhLh-hGgXgz2oQ@mail.gmail.com>
Hola Jesús,
El Wed, 31 Dec 2014 20:49:06 +0100
"piranna@gmail.com" <piranna@gmail.com> escribió:
> > 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... :-/
>
You've used CLFS-embedded, right?. Probably you are getting
dynamic-link issues because the steps used for musl in CLFS-embedded
are not linked with the cross binutils (or the binutils from the
clfs-toolchain). You need to add CROSS_COMPILE="${CLFS_TARGET}-" to the
environment.
>
> > 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 :-/
>
>
next prev parent reply other threads:[~2014-12-31 20:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-31 18:04 piranna
2014-12-31 19:35 ` Szabolcs Nagy
2014-12-31 19:49 ` piranna
2014-12-31 20:08 ` Matias A. Fonzo [this message]
[not found] ` <CAKfGGh0EoXAb7FH2pn2FW1ND7Bts8XSjj2ur-aoc6Ugbb6atNw@mail.gmail.com>
2014-12-31 21:09 ` Matias A. Fonzo
2014-12-31 21:25 ` piranna
2014-12-31 19:40 ` Isaac Dunham
2014-12-31 20:17 ` piranna
2014-12-31 20:36 ` piranna
2014-12-31 21:55 ` Isaac Dunham
2015-01-01 20:02 ` piranna
2015-01-03 23:37 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141231170852.7e17953d@dragora.org \
--to=selk@dragora.org \
--cc=musl@lists.openwall.com \
--cc=piranna@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).