From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: [PATCH] gnu: Add gobject-introspection. Date: Sun, 15 Sep 2013 23:09:16 +0200 Message-ID: <87y56xkd1f.fsf@gnu.org> References: <1378942761-23687-1-git-send-email-tipecaml@gmail.com> <87d2oeqvnv.fsf@gnu.org> <5235C7F5.4070000@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLJeD-0004aM-13 for guix-devel@gnu.org; Sun, 15 Sep 2013 17:14:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLJe6-0002mQ-Di for guix-devel@gnu.org; Sun, 15 Sep 2013 17:14:24 -0400 Received: from hera.aquilenet.fr ([141.255.128.1]:60460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLJe6-0002mM-2q for guix-devel@gnu.org; Sun, 15 Sep 2013 17:14:18 -0400 In-Reply-To: <5235C7F5.4070000@gmail.com> (Cyril Roelandt's message of "Sun, 15 Sep 2013 16:45:09 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Cyril Roelandt Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cyril Roelandt skribis: > On 09/12/2013 10:41 AM, Ludovic Court=C3=A8s wrote: >> No. Could you try to grep the source to see what produces this message? > > Oh, I thought the message was directly produced by libtool or the > linker, but yes, it's definitely an error message from > gobject-introspection. I investigated this a bit. During the 'build' > phase, the '_resolve_non_libtool' method is called from > giscanner/shlibs.py. It tries to get the path to some libraries (here, > gobject-2.0 and glib-2.0). In order to do this, it runs this command: > > $ /nix/store/2awqnfxjrcm2b8s481zwsnfdic3inkdi-bash-4.2/bin/bash \ > ./libtool --mode=3Dexecute ldd \ > /tmp/nix-build-gobject-introspection-1.37.6.drv-0/gobject-introspection-1= .37.6/tmp-introspectS0TNXv/GLib-2.0 > > (tmp-instropectS0TNXv is a random directory) > > On i686, this works perfectly. On x86-64, I get: > > 'not a dynamic executable' Yes, we actually have a problem with ldd (I had noticed, but thought this would change with the moon phase or something): --8<---------------cut here---------------start------------->8--- $ sh -x ~/.guix-profile/bin/ldd $(which ls) + TEXTDOMAIN=3Dlibc + TEXTDOMAINDIR=3D/nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/sh= are/locale + RTLDLIST=3D'/nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/lib/ld= -linux.so.2 /nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/lib64/ld= -linux-x86-64.so.2 /nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/l= ibx32/ld-linux-x32.so.2' + warn=3D + bind_now=3D + verbose=3D + test 1 -gt 0 + case "$1" in + break + add_env=3D'LD_TRACE_LOADED_OBJECTS=3D1 LD_WARN=3D LD_BIND_NOW=3D' + add_env=3D'LD_TRACE_LOADED_OBJECTS=3D1 LD_WARN=3D LD_BIND_NOW=3D LD_LIBRA= RY_VERSION=3D$verify_out' + add_env=3D'LD_TRACE_LOADED_OBJECTS=3D1 LD_WARN=3D LD_BIND_NOW=3D LD_LIBRA= RY_VERSION=3D$verify_out LD_VERBOSE=3D' + test '' =3D yes + set -o pipefail + case $# in + single_file=3Dt + result=3D0 + for file in '"$@"' + test t =3D t + case $file in + : + test '!' -e /home/ludo/.guix-profile/bin/ls + test '!' -f /home/ludo/.guix-profile/bin/ls + test -r /home/ludo/.guix-profile/bin/ls + test -x /home/ludo/.guix-profile/bin/ls + RTLD=3D + ret=3D1 + for rtld in '${RTLDLIST}' + test -x /nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/lib/ld-lin= ux.so.2 + for rtld in '${RTLDLIST}' + test -x /nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/lib64/ld-l= inux-x86-64.so.2 + for rtld in '${RTLDLIST}' + test -x /nix/store/53afsq4c7r10hn77h3iyyavy2bs02403-glibc-2.17/libx32/ld-= linux-x32.so.2 + case $ret in + nonelf /home/ludo/.guix-profile/bin/ls + return 1 + echo ' not a dynamic executable' not a dynamic executable + result=3D1 + exit 1 --8<---------------cut here---------------end--------------->8--- It=E2=80=99s looking for ld.so in the wrong place (under lib64/). I believe this wonderful patch fixes the problem: --=-=-= Content-Type: text/x-patch Content-Disposition: inline --- glibc-2.17/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed~ 2012-12-25 04:02:13.000000000 +0100 +++ glibc-2.17/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2013-09-15 23:08:03.000000000 +0200 @@ -1,3 +1,3 @@ /LD_TRACE_LOADED_OBJECTS=1/a\ add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out" -s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[ ]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6"_ +s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[ ]*$_\1"\2\4\6 \2\4-x86-64\6 \2x32\4-x32\6"_ --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 DQpJ4oCZbGwgdHJ5IGl0IGluIOKAmGNvcmUtdXBkYXRlc+KAmSBhbmQgcmVwb3J0IGJhY2suDQoN ClRoYW5rcywNCkx1ZG/igJkuDQo= --=-=-=--