--- Begin Message ---
|
Subject: |
Problem with ld.so RUNPATH on armhf |
|
Date: |
Fri, 13 Mar 2015 14:56:46 -0400 |
I recently tried rebuilding Guix on armhf, specifically master since the
recent core-updates merge, and have run into a snag. I'm able to build
a lot of stuff, including our full 'emacs' package (with Gtk+), but I'm
unable to build 'glibc-utf8-locales', which means I can't build any
profiles at all, because the ca-certificates-bundle uses
glibc-utf8-locales.
Here's what happens when I try to build 'glibc-utf8-locales' manually:
--8<---------------cut here---------------start------------->8---
address@hidden:~$ guix build -K glibc-utf8-locales
The following derivation will be built:
/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv
warning: failed to install locale: Invalid argument
@ build-started
/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv -
armhf-linux
/var/log/guix/drvs/14//kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv.bz2
Inconsistency detected by ld.so: get-dynamic-info.h: 142: elf_get_dynamic_info:
Assertion `info[29] == ((void *)0)' failed!
note: keeping build directory `/tmp/nix-build-glibc-utf8-locales-2.21.drv-0'
builder for
`/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv'
failed with exit code 1
@ build-failed
/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv - 1
builder for
`/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv'
failed with exit code 1
killing process 1498
guix build: error: build failed: build of
`/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv' failed
--8<---------------cut here---------------end--------------->8---
The key line being:
Inconsistency detected by ld.so: get-dynamic-info.h: 142: elf_get_dynamic_info:
Assertion `info[29] == ((void *)0)' failed!
Here's the relevant bit of code from glibc-2.21/elf/get-dynamic-info.h:
--8<---------------cut here---------------start------------->8---
#ifdef RTLD_BOOTSTRAP
/* Only the bind now flags are allowed. */
assert (info[VERSYMIDX (DT_FLAGS_1)] == NULL
|| (info[VERSYMIDX (DT_FLAGS_1)]->d_un.d_val & ~DF_1_NOW) == 0);
assert (info[DT_FLAGS] == NULL
|| (info[DT_FLAGS]->d_un.d_val & ~DF_BIND_NOW) == 0);
/* Flags must not be set for ld.so. */
assert (info[DT_RUNPATH] == NULL);
assert (info[DT_RPATH] == NULL);
--8<---------------cut here---------------end--------------->8---
"assert (info[DT_RUNPATH] == NULL)" is the assertion that fails here.
This happens while trying to run 'localedef' from the 'glibc' that's an
input to 'glibc-utf8-locales'. Interestingly, 'bash' works from the
same store item:
--8<---------------cut here---------------start------------->8---
address@hidden:/gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/bin$
./bash
I have no
address@hidden:/gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/bin$ exit
address@hidden:/gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/bin$
./localedef
Inconsistency detected by ld.so: get-dynamic-info.h: 142: elf_get_dynamic_info:
Assertion `info[29] == ((void *)0)' failed!
--8<---------------cut here---------------end--------------->8---
readelf reveals that indeed, the ld.so used by localedef,
/gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/lib/ld-linux-armhf.so.3
does have RUNPATH set: (excerpt of "readelf -a" output)
--8<---------------cut here---------------start------------->8---
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
EXIDX 0x01681c 0x0001681c 0x0001681c 0x00098 0x00098 R 0x4
LOAD 0x000000 0x00000000 0x00000000 0x168b4 0x168b4 R E 0x10000
LOAD 0x016c80 0x00026c80 0x00026c80 0x00c00 0x00cc8 RW 0x10000
DYNAMIC 0x016f3c 0x00026f3c 0x00026f3c 0x000c0 0x000c0 RW 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x10
GNU_RELRO 0x016c80 0x00026c80 0x00026c80 0x00380 0x00380 R 0x1
Section to Segment mapping:
Segment Sections...
00 .ARM.exidx
01 .hash .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_d .rel.dyn
.rel.plt .plt .text .rodata .ARM.extab .ARM.exidx
02 .data.rel.ro .dynamic .got .data .bss
03 .dynamic
04
05 .data.rel.ro .dynamic
Dynamic section at offset 0x16f3c contains 20 entries:
Tag Type Name/Value
0x0000000e (SONAME) Library soname: [ld-linux-armhf.so.3]
0x0000001d (RUNPATH) Library runpath:
[/gnu/store/fbdjazgwy3zyx8qc5z4ag0j78k2d7raw-glibc-2.21/lib]
--8<---------------cut here---------------end--------------->8---
Any ideas what went wrong here?
Mark
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20102: Problem with ld.so RUNPATH on armhf |
|
Date: |
Thu, 09 Apr 2015 08:57:39 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> address@hidden (Ludovic Courtès) writes:
>
>> With a bit of additional debug, I can print the value of ‘libs’ in the
>> ‘ld-wrapper’ procedure:
>>
>> ;;; (libs
>> ("/gnu/store/fbdjazgwy3zyx8qc5z4ag0j78k2d7raw-glibc-2.21/lib/ld-linux-armhf.so.3"))
>>
>> This one comes from the -dynamic-linker flag, which is not passed on
>> x86_64.
>>
>> I believe this extra -dynamic-linker flag comes from a bogus ‘link’ spec
>> on ARM, solved by this:
>>
>> --- gcc-4.8.4/gcc/config/arm/linux-elf.h.orig 2015-04-08
>> 20:31:20.376900478 +0200
>> +++ gcc-4.8.4/gcc/config/arm/linux-elf.h 2015-04-08 20:31:36.437014437
>> +0200
>> @@ -65,7 +65,7 @@
>> %{symbolic:-Bsymbolic} \
>> %{!static: \
>> %{rdynamic:-export-dynamic} \
>> - -dynamic-linker " GNU_USER_DYNAMIC_LINKER "} \
>> + %{!shared:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
>> -X \
>> %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>> SUBTARGET_EXTRA_LINK_SPEC
>>
>> That way it would match GNU_USER_TARGET_LINK_SPEC in i386/gnu-user.h,
>> where -dynamic-linker appears within %{!static ... %{!shared ...}}.
>>
>> So, could you do:
>>
>> (define patched-gcc
>> (package
>> (inherit gcc-4.8)
>> (sources (origin (inherit (package-source gcc-4.8))
>> (patches ...)))))
>>
>> build it, and then use it in the failed glibc build tree to rebuild
>> ld.so?
>
> Yes, this fixed the problem. I went ahead and pushed 1421afa94a to
> core-updates to apply this patch to gcc-4.8, gcc-4.9, and cross-gcc.
>
> I started both Hydra and my Novena building the new core-updates.
Cool, thanks!
(There’s a small typo in the comment in the patch: it should be “Don’t
pass -dynamic-linker when shared.”)
I will push the ld-wrapper fix in the next core-updates cycle then.
Ludo’.
--- End Message ---