From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6770 Path: news.gmane.org!not-for-mail From: "Matias A. Fonzo" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Failed to execute /init (error -2) for system-wide musl libc Date: Wed, 31 Dec 2014 17:08:52 -0300 Message-ID: <20141231170852.7e17953d@dragora.org> References: <20141231193540.GD3156@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1420056393 14518 80.91.229.3 (31 Dec 2014 20:06:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 31 Dec 2014 20:06:33 +0000 (UTC) Cc: musl@lists.openwall.com To: "piranna@gmail.com" Original-X-From: musl-return-6783-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 31 21:06:28 2014 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Y6PXH-0005zi-Hp for gllmg-musl@m.gmane.org; Wed, 31 Dec 2014 21:06:27 +0100 Original-Received: (qmail 32188 invoked by uid 550); 31 Dec 2014 20:06:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32177 invoked from network); 31 Dec 2014 20:06:25 -0000 In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.10; x86_64-dragora-linux-gnu) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - titan.astranetwork.net X-AntiAbuse: Original Domain - lists.openwall.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dragora.org X-Get-Message-Sender-Via: titan.astranetwork.net: authenticated_id: selk@dragora.org X-Source: X-Source-Args: X-Source-Dir: Xref: news.gmane.org gmane.linux.lib.musl.general:6770 Archived-At: Hola Jes=FAs, El Wed, 31 Dec 2014 20:49:06 +0100 "piranna@gmail.com" escribi=F3: > > i think if static init works then try to use > > that to boot up the system and then debug the > > dynamic case.. >=20 > It's a good idea, didn't though about it :-) >=20 >=20 > > you can run libc.so with a dynamic executable > > as argument then you can debug the loader >=20 > Definitely I can be able to use Node.js child_process module to launch > libc.so, I'll try it :-) >=20 >=20 > > 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 >=20 > 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... >=20 >=20 > >> 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 >=20 > 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... >=20 >=20 > >> 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 >=20 > 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... :-/ >=20 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=3D"${CLFS_TARGET}-" to the environment. >=20 > > i've seen the symlink disappearing on openwrt buildsystem once > > (that one was not deterministic) i'm not sure what caused it >=20 > 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 :-/ >=20 >=20