Patchwork ldconfig - unknown machine 40

login
register
mail settings
Submitter Ciarán Rehill
Date June 28, 2013, 4:55 p.m.
Message ID <loom.20130628T172450-675@post.gmane.org>
Download mbox | patch
Permalink /patch/255486/
State Rejected
Delegated to: Thomas De Schampheleire
Headers show

Comments

Ciarán Rehill - June 28, 2013, 4:55 p.m.
Hello,

(Actual questions are below, on lines starting with "*** ", but some 
explanation of context is required first.)

I'm cross-compiling on an x86_64 build machine for an ARMv6 target using an 
external CodeSourcery toolchain.  The build machine is running Fedora 18, 
with glibc 2.16.
I notice that in the "target-finalize" stage, "ldconfig -r ..." is printing 
out a lot of lines like:

    /lib:
    /sbin/ldconfig: /lib/libnsl.so.1 is for unknown machine 40.
    ...
    /sbin/ldconfig: /lib/libthread_db-1.0.so is for unknown machine 40.
    /sbin/ldconfig: /lib/libgcc_s.so.1 is for unknown machine 40.
    ...
    /sbin/ldconfig: /lib/ld-linux.so.3 is for unknown machine 40.
    /sbin/ldconfig: /lib/libm.so.6 is for unknown machine 40.
    ...
    /sbin/ldconfig: /lib/libc.so.6 is for unknown machine 40.

and so on.  You'll notice these are toolchain-provided libraries; the same 
happens for all generated libraries too.
These are _not_ just warnings; ldconfig ignores the library content, so 
"output/target/etc/ld.so.cache" is left unpopulated, meaning that the 
target device will not boot successfully due to missing libraries (the 
libraries are on the file-system, just the ld.so.cache does not list them).

The same build works on a Ubuntu machine with (e)glibc 2.15 and older 
Fedora machines with earlier versions of glibc.

Since v2.15 appears to work and v2.16 does not, I grabbed the glibc git 
repo and did some digging in the commits between the two releases.  The one 
that grabbed my attention was commit 
f1a77b01f4e3a80782171297120e77ab112ce85d, in particular the change in 
"sysdeps/unix/sysv/linux/i386/readelflib.c" (equivalently the x86_64 
version after this commit too).

The patch is relatively small for this file so I'll include it here.

--
 #undef __ELF_NATIVE_CLASS
--


So, instead of just accepting the class identifier (ELFCLASS32, which 
includes most ARM binaries) and moving on, it now tests the machine and 
*then* the class.  Unfortunately, the list of accepted machines does not 
include ARM, so the "unknown machine 40" (40 being EM_ARM) is spat out and 
the attempt to process is abandoned.

*** Firstly, anyone else seeing this?  Searching doesn't turn up much.

*** Second, is my train of thought above correct?

*** Most importantly, any ideas on how to successfully use Buildroot on an 
F18 machine for ARM (or any non-Intel arch, I suppose)?

The act of typing the above line now makes me suspicious that I *am* the 
only one seeing this so there's something wrong on my end, but I have 
confirmed that this error *is* emitted with the top of current master 
branch (a2d06655e5684c10f6a02cc065aaf481f56a8c64) though, using the 
following defconfig:

--
BR2_arm=y
BR2_arm1136jf_s_r0=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_PATH="$(HOME)/CodeSourcery/Sourcery_G++/libc/usr"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_PREFIX="$(ARCH)-none-linux-gnueabi"
BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
# BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set
# BR2_TARGET_ROOTFS_TAR is not set
--


Sorry for the long message, but I think everything mentioned is relevant 
(except this line ;-).
Milton Soares Filho - July 1, 2013, 10:25 p.m.
On 28 June 2013 13:55, Ciarán Rehill <cir.vfi@gmail.com> wrote:
>     /sbin/ldconfig: /lib/libnsl.so.1 is for unknown machine 40.
> [...]
> *** Firstly, anyone else seeing this?  Searching doesn't turn up much.

Me too! Trying to build a ST sh4 target using an external toolchain.
My host machine has Ubuntu 13.04 x86-64 installed and ships ldconfig
version 2.17.

> *** Most importantly, any ideas on how to successfully use Buildroot on an
> F18 machine for ARM (or any non-Intel arch, I suppose)?

Still have no idea on how to fix this issue, since my external
toolchain is pre-compiled and does not ship cross-ldconfig within it.
I have done a workaround using LD_LIBRARY_PATH on the target
initialization scripts, but assuming it's a sub-optimal solution.

Best regards.

[]s, milton
Ciarán Rehill - July 2, 2013, 11:49 a.m.
On Luan, 2013-07-01 at 19:25 -0300, Milton Soares Filho wrote:

Hello Milton,

> On 28 June 2013 13:55, Ciarán Rehill <cir.vfi@gmail.com> wrote:
> >     /sbin/ldconfig: /lib/libnsl.so.1 is for unknown machine 40.
> > [...]
> > *** Firstly, anyone else seeing this?  Searching doesn't turn up much.
> 
> Me too! Trying to build a ST sh4 target using an external toolchain.
> My host machine has Ubuntu 13.04 x86-64 installed and ships ldconfig
> version 2.17.

Is it normal not to supply a cross-ldconfig with a toolchain release or
is there a standard policy on this?

> > *** Most importantly, any ideas on how to successfully use Buildroot on an
> > F18 machine for ARM (or any non-Intel arch, I suppose)?
> 
> Still have no idea on how to fix this issue, since my external
> toolchain is pre-compiled and does not ship cross-ldconfig within it.
> I have done a workaround using LD_LIBRARY_PATH on the target
> initialization scripts, but assuming it's a sub-optimal solution.

Is it possible to build the ldconfig from source without going through a
full toolchain build process, given that the majority of the components
already exist?  Maybe some essential parts are lost in the binary
distribution and there's still the need to use that intermediate stage
toolchain to generate this.  I saw some other traffic on the list
mentioning that stage may not be necessary any more though, but it may
not be relevant here.  Any toolchain experts want to chime in?
Milton Soares Filho - July 2, 2013, 4:31 p.m.
On 2 July 2013 08:49, Ciarán Rehill <cir.vfi@gmail.com> wrote:
> Is it normal not to supply a cross-ldconfig with a toolchain release or
> is there a standard policy on this?

I haven't found a cross-ldconfig within both sh4 and broadcom
toolchains which I have available.

> Is it possible to build the ldconfig from source without going through a
> full toolchain build process, given that the majority of the components
> already exist?

Oh, I've lamely tried a 'make host-ldconfig' before reasearching the issue :-P

[]s, milton
Ciarán Rehill - July 3, 2013, 9:49 p.m.
Milton Soares Filho wrote
> On 2 July 2013 08:49, Ciarán Rehill &lt;

> cir.vfi@

> &gt; wrote:
>> Is it normal not to supply a cross-ldconfig with a toolchain release or
>> is there a standard policy on this?
> 
> I haven't found a cross-ldconfig within both sh4 and broadcom
> toolchains which I have available.

Same story with the cross compiler in the yum repos for Fedora
(gcc-arm-linux-gnu): no ldconfig.

Anyway, what seems to be a (dirty) workaround is to take the
"/sbin/ldconfig.real" from a Ubuntu 12.04 system and place it into the
cross-compiler bin/ directory, renaming with the toolchain tuple,
"~/CodeSourcery/Sourcery_G++/bin/arm-none-linux-gnueabi-ldconfig" in this
case.  The file can be extracted from a .rpm or .deb for the appropriate
version.
I know it's wrong, but it gets over this bump in the absence of a better
solution.  Hopefully one of the elders of the list will suggest something
more appropriate.



--
View this message in context: http://buildroot-busybox.2317881.n4.nabble.com/ldconfig-unknown-machine-40-tp47588p47834.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.

Patch

diff --git a/sysdeps/unix/sysv/linux/i386/readelflib.c b/sysdeps/unix/sysv/
linux/i386/readelflib.c
index bdd5e70..fab830e 100644
--- a/sysdeps/unix/sysv/linux/i386/readelflib.c
+++ b/sysdeps/unix/sysv/linux/i386/readelflib.c
@@ -32,40 +32,52 @@  process_elf_file (const char *file_name, const char 
*lib, int *flag,
           size_t file_length)
 {
   ElfW(Ehdr) *elf_header = (ElfW(Ehdr) *) file_contents;
-  int ret;
+  int ret, file_flag = 0;
 
-  if (elf_header->e_ident [EI_CLASS] == ELFCLASS32)
-    return process_elf32_file (file_name, lib, flag, osversion, soname,
-                   file_contents, file_length);
-  else
+  switch (elf_header->e_machine)
     {
-      switch (elf_header->e_machine)
+    case EM_X86_64:
+      if (elf_header->e_ident[EI_CLASS] == ELFCLASS64)
+    /* X86-64 64bit libraries are always libc.so.6+.  */
+    file_flag = FLAG_X8664_LIB64|FLAG_ELF_LIBC6;
+      else
+    /* X32 libraries are always libc.so.6+.  */
+    file_flag = FLAG_X8664_LIBX32|FLAG_ELF_LIBC6;
+      break;
+#ifndef SKIP_EM_IA_64
+    case EM_IA_64:
+      if (elf_header->e_ident[EI_CLASS] == ELFCLASS64)
     {
-    case EM_IA_64:
-    case EM_X86_64:
+      /* IA64 64bit libraries are always libc.so.6+.  */
+      file_flag = FLAG_IA64_LIB64|FLAG_ELF_LIBC6;
       break;
-    default:
-      error (0, 0, _("%s is for unknown machine %d.\n"),
-         file_name, elf_header->e_machine);
-      return 1;
     }
+      goto failed;
+#endif
+    case EM_386:
+      if (elf_header->e_ident[EI_CLASS] == ELFCLASS32)
+    break;
+      /* Fall through.  */
+    default:
+#ifndef SKIP_EM_IA_64
+failed:
+#endif
+      error (0, 0, _("%s is for unknown machine %d.\n"),
+         file_name, elf_header->e_machine);
+      return 1;
+    }
 
-      ret = process_elf64_file (file_name, lib, flag, osversion, soname,
-                file_contents, file_length);
-      /* IA64/X86-64 64bit libraries are always libc.so.6+.  */
-      if (!ret)
-    switch (elf_header->e_machine)
-      {
-      case EM_IA_64:
-        *flag = FLAG_IA64_LIB64|FLAG_ELF_LIBC6;
-        break;
-      case EM_X86_64:
-        *flag = FLAG_X8664_LIB64|FLAG_ELF_LIBC6;
-        break;
-      }
+  if (elf_header->e_ident[EI_CLASS] == ELFCLASS32)
+    ret = process_elf32_file (file_name, lib, flag, osversion, soname,
+                  file_contents, file_length);
+  else
+    ret = process_elf64_file (file_name, lib, flag, osversion, soname,
+                  file_contents, file_length);
 
-      return ret;
-    }
+  if (!ret && file_flag)
+    *flag = file_flag;
+
+  return ret;
 }