[Buildroot] ldconfig - unknown machine 40

[Buildroot] ldconfig - unknown machine 40

[Ciarán Rehill]

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.

--
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;
 }
 
 #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 ;-).

[Buildroot] ldconfig - unknown machine 40

[Milton Soares Filho]

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

[Buildroot] ldconfig - unknown machine 40

[Ciarán Rehill]

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?

[Buildroot] ldconfig - unknown machine 40

[Milton Soares Filho]

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

[Buildroot] ldconfig - unknown machine 40

[cir.vfi at gmail.com]

Milton Soares Filho wrote
> On 2 July 2013 08:49, Ciar?n Rehill <

> cir.vfi@

> > 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.

[Buildroot] ldconfig - unknown machine 40

[Matthias 'muh' Pauligk]

Hi,

I faced the same problem using buildroot's toolchain.
The ld-config is present in the host directory, but the Makefile is looking
at the wrong path.
So I made a small patch to fix this issue, which is working fine for me:

--- a/Makefile
+++ b/Makefile
@@ -161,6 +161,7 @@
 # initial definition so that 'make clean' works for most users, even
without
 # .config. HOST_DIR will be overwritten later when .config is included.
 HOST_DIR := $(BASE_DIR)/host
+LDCONF_DIR := $(HOST_DIR)/usr/arm-buildroot-linux-gnueabi/sysroot/sbin

 LEGAL_INFO_DIR = $(BASE_DIR)/legal-info
 REDIST_SOURCES_DIR_TARGET = $(LEGAL_INFO_DIR)/sources
@@ -597,9 +598,9 @@
        # for recent versions of ldconfig
        touch $(TARGET_DIR)/etc/ld.so.conf
        mkdir -p $(TARGET_DIR)/var/cache/ldconfig
-       if [ -x "$(TARGET_CROSS)ldconfig" ]; \
+       if [ -x "$(LDCONF_DIR)/ldconfig" ]; \
        then \
-               $(TARGET_CROSS)ldconfig -r $(TARGET_DIR); \
+               $(LDCONF_DIR)/ldconfig -r $(TARGET_DIR); \
        else \
                /sbin/ldconfig -r $(TARGET_DIR); \
        fi


Just apply it in buildroot's root directory. 
Maybe this is also working for external toolchains, depending on where
ld-config is located there.

Best regards.




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

[Buildroot] ldconfig - unknown machine 40

[Thomas Petazzoni]

Dear Matthias 'muh' Pauligk,

On Thu, 15 Jan 2015 06:23:54 -0800 (PST), Matthias 'muh' Pauligk wrote:

> I faced the same problem using buildroot's toolchain.
> The ld-config is present in the host directory, but the Makefile is looking
> at the wrong path.
> So I made a small patch to fix this issue, which is working fine for me:

The problem is unfortunately not that simple: yes you have a ldconfig
for glibc toolchains. But not for uClibc based toolchains.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] ldconfig - unknown machine 40

[rdkehn at yahoo.com]

 Thomas,

Thomas Petazzoni <thomas.petazzoni@...> writes:

> 
> Dear Matthias 'muh' Pauligk,
> 
> On Thu, 15 Jan 2015 06:23:54 -0800 (PST), Matthias 'muh' Pauligk wrote:
> 
> > I faced the same problem using buildroot's toolchain.
> > The ld-config is present in the host directory, but the Makefile is looking
> > at the wrong path.
> > So I made a small patch to fix this issue, which is working fine for me:
> 
> The problem is unfortunately not that simple: yes you have a ldconfig
> for glibc toolchains. But not for uClibc based toolchains.
> 
> Best regards,
> 
> Thomas
>

... sorry for dredging up an old thread; however, I was wondering if
you would mind commenting more on ldconfig for glibc toolchains.
Should a host ldconfig be build for Buildroot built glibc
toolchains?

I built a glibc 2.20 arm-buildroot-linux-gnueabihf toolchain from
Buildroot 2015.05-git-00331-gcef6a78 and I don't have an
arm-buildroot-linux-gnueabihf-ldconfig.  Thus, when the build gets
to the finalizing target directory stage, I observe the 'ldconfig -
unknown machine 40' message.

    :
    :
# Mandatory configuration file and auxilliary cache directory
# for recent versions of ldconfig
touch /home/dkehn/devel/buildroot/output/target/etc/ld.so.conf
mkdir -p
/home/dkehn/devel/buildroot/output/target/var/cache/ldconfig
if [ -x
"/home/dkehn/devel/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-ldconfig"
]; \
then \
  /home/dkehn/devel/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-ldconfig
  -r /home/dkehn/devel/buildroot/output/target; \
  else \
      /sbin/ldconfig -r /home/dkehn/devel/buildroot/output/target;
      \
      fi
      /sbin/ldconfig:
      /usr/lib/libglibmm_generate_extra_defs-2.4.so.1 is for
      unknown machine 40.

      /sbin/ldconfig: /usr/lib/libxslt.so.1.1.28 is for unknown
      machine 40.
    :
    :

I thought arm-buildroot-linux-gnueabihf-ldconfig would be present.

Thanks and Regards,
..doug