"unknown" architecture for libs with `ldconfig -p`

[qopit]

When you run `ldconfig -p` on a stock Corepure64 you get "unknown" for the .so variant on all libs:

Code: [Select]

tc@box:~$ ldconfig -p | tail
    libcrypt.so.1 (unknown) => /lib/libcrypt.so.1
    libcrypt.so (unknown) => /usr/lib/libcrypt.so
    libcom_err.so.2 (unknown) => /lib/libcom_err.so.2
    libcom_err.so (unknown) => /usr/lib/libcom_err.so
    libc.so.6 (unknown) => /lib/libc.so.6
    libblkid.so.1 (unknown) => /lib/libblkid.so.1
    libblkid.so (unknown) => /usr/lib/libblkid.so
    libanl.so.1 (unknown) => /lib/libanl.so.1
    libanl.so (unknown) => /usr/lib/libanl.so
    ld-linux-x86-64.so.2 (unknown) => /lib/ld-linux-x86-64.so.2

Why is this?  Does anyone know how to fix it?

This is causing a direct problem with a python program that is looking for an arch match in there (with ctypes.util.find_library specifically), but I wonder if it is going to cause additional issues.

The above output is for this iso (but various Corepure64 variants do it, going back to 6.x):
http://tinycorelinux.net/8.x/x86_64/release/CorePure64-8.0.iso

For comparison, a stock Core-8.0.iso yields the expected "libc6" or "ELF' values:

Code: [Select]

tc@box:~$ ldconfig -p | tail -n 2
    libanl.so (libc6) => /usr/lib/libanl.so
    ld-linux.so.2 (ELF) => /lib/ld-linux.so.2

[qopit]

It seems to originate with this code:

https://github.com/bminor/glibc/blob/glibc-2.26/elf/cache.c#L69

...why would the flags not match?

[curaga]

Our ldconfig comes from uclibc, since it's something like 500kb smaller for the same functionality. Checking.

[Juanito]

In fact 50kb vs 735kb for corepure64 

[curaga]

Okay, the code in question has not changed in newer uclibc versions, nor in uclibc-ng. Try compiling the latest uclibc-ng and look into what the flags are?

[curaga]

I posted a patch, uclibc-ldconfig-x64-p-option.patch, to my home dir. It applies against the last uclibc release (-p0, I think).

[curaga]

..though looking at python 3, it expects a very specific string, "libc6,x86_64" which is not what uclibc prints even with my patch (it prints just "libc6").

I'm not sure if Python or uclibc should be patched for that thing. Python's source does have an XXX requires glibc comment there, so maybe open a python bug?

[code]

Is that because it is a 32bit shared library?

[qopit]

Thanks, curaga!

Where is your home dir? I'd like to see what your patch does. Presumably it just recognizes the flags imprinted by uclibc?

I do think ctypes needs patching. Having a limited whitelist of .so variants seems overly restrictive. My initial feeling is that when only one lib variant is found by find_library() that the best option is to return that one, rather than saying nothing could be found. Maybe with an optional parameter to indicate that you're fine with a best guess response.

[curaga]

Posted a copy here:
http://patches.tinycorelinux.net/uploaded/uclibc-ldconfig-x64-p-option.patch

It just enables uclibc's own detection to work, which then finds it's a libc6 library.

@code
I tested against 64-bit libs.

[Juanito]

The 32-bit uClibc and glibc versions of ldconfig respond in the same way:

Code: [Select]

$ ldconfig -p | tail -2
        libEGL.so (libc6) => /usr/local/lib/libEGL.so
        ld-linux.so.2 (ELF) => /lib/ld-linux.so.2
However, the 64-bit versions respond like this?

Code: [Select]

$ ldconfig -p | tail -2
        libEGL.so (unknown) => /usr/local/lib/libEGL.so
        ld-linux-x86-64.so.2 (unknown) => /lib/ld-linux-x86-64.so.2

$ /home/tc/sbin/ldconfig -p | tail -2
        libEGL.so (libc6,x86-64) => /usr/local/lib/libEGL.so
        ld-linux-x86-64.so.2 (ELF,x86-64) => /lib/ld-linux-x86-64.so.2
..so I guess the patch should produce the same output?

[Juanito]

ldconfig patched in tc-8.1.1