[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#20102: closed (Problem with ld.so RUNPATH on armhf

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#20102: closed (Problem with ld.so RUNPATH on armhf)
Date: Thu, 09 Apr 2015 06:58:03 +0000

Your message dated Thu, 09 Apr 2015 08:57:39 +0200
with message-id <address@hidden>
and subject line Re: bug#20102: Problem with ld.so RUNPATH on armhf
has caused the debbugs.gnu.org bug report #20102,
regarding Problem with ld.so RUNPATH on armhf
to be marked as done.

(If you believe you have received this mail in error, please contact

20102: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20102
GNU Bug Tracking System
Contact address@hidden with problems
--- 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

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:
warning: failed to install locale: Invalid argument
@ build-started 
/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv - 
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 
failed with exit code 1
@ build-failed 
/gnu/store/14kf28i9qkzrdjn5m150zk6dxijssk2k-glibc-utf8-locales-2.21.drv - 1 
builder for 
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---
  /* 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---
I have no 
address@hidden:/gnu/store/l2bkyclkm0lph48mfs6jbndj9p0y41g8-glibc-2.21/bin$ exit
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,


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
   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: 
--8<---------------cut here---------------end--------------->8---

Any ideas what went wrong here?


--- 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}" \
>> 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.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]