[Clfs-support] CLFS support

[Andrew Bradford]

On 02/11/2014 09:16 AM, Andrew Bradford wrote:
> On 02/11/2014 08:58 AM, Andrew Bradford wrote:
>> On 02/10/2014 08:01 PM, Kevyn-Alexandre Paré wrote:
>>> The ldconfig in the make install in the 4.9 section is the problem:
>>>
>>> ls /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1
>>> clfs at knight:/mnt/clfs/sources/musl-0.9.14$ /sbin/ldconfig -n
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib
>>> /sbin/ldconfig.real:
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/libstdc++.so.6.0.17-gdb.py
>>> is not an ELF file - it has the wrong magic bytes at the start.
>>
>> What are you doing here?  Maybe the formatting got ugly via the line-wrap?
>>
>> Why are you running ldconfig manually on the build host?
>>
>>> clfs at knight:/mnt/clfs/sources/musl-0.9.14$ ls
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1
>>> ls: cannot access
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1: No
>>> such file or directory
>>>
>>> So since the
>>> ls -l /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1
>>> lrwxrwxrwx 1 clfs clfs 12 Feb 10 19:54
>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1 ->
>>> /lib/libc.so
>>> clfs at knight:/mnt/clfs/sources/musl-0.9.14$ ls -al /lib/libc.so
>>> ls: cannot access /lib/libc.so: No such file or directory
>>>
>>> To solve the issue I just made a test by doing:
>>> sudo touch /lib/libc.so
>>> Then when ldconfig is called the  ld-musl-armhf.so.1 is not deleted.
>>>
>>> His there a better way to fix that?
>>
>> In my attempt to reproduce this, after building and installing musl in
>> section 4.8, I see:
>>
>> $ ls -lh ${CLFS}/cross-tools/arm-linux-musleabihf/lib
>> total 2.4M
>> -rw-r--r-- 1 clfs clfs  988 Feb 11 08:35 Scrt1.o
>> -rw-r--r-- 1 clfs clfs  916 Feb 11 08:35 crt1.o
>> -rw-r--r-- 1 clfs clfs  828 Feb 11 08:35 crti.o
>> -rw-r--r-- 1 clfs clfs  808 Feb 11 08:35 crtn.o
>> lrwxrwxrwx 1 clfs clfs   12 Feb 11 08:35 ld-musl-arm.so.1 -> /lib/libc.so
>> drwxr-xr-x 2 clfs clfs 4.0K Feb 11 08:24 ldscripts
>> -rw-r--r-- 1 clfs clfs 1.7M Feb 11 08:35 libc.a
>> -rwxr-xr-x 1 clfs clfs 694K Feb 11 08:35 libc.so
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libcrypt.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libdl.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libm.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libpthread.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libresolv.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 librt.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libutil.a
>> -rw-r--r-- 1 clfs clfs    8 Feb 11 08:35 libxnet.a
>>
>> Which is as expected.  There is no /lib/libc.so on my system (Debian
>> Wheezy amd64) and I do not touch one.
>>
>> Then I end up having a similar situation to you where there is no link
>> from ld-musl-arm.so.1 back to /lib/libc.so after gcc-final's "make
>> install" step.  Interesting...
>>
>> I also have an automated script, based off of CLFS embedded and
>> musl-cross which, I believe, does not have this problem.  I'll try to
>> look into why that is.  Touching /lib/libc.so is not reasonable, to me.
> 
> OK, so this is a glibc thing...  It seems that glibc on the host thinks
> it can own creation *AND* deletion of symlinks via ldconfig.  If
> ldconfig finds a symlink that doesn't actually go anywhere, it assumes
> it's a dead link left over from some libs that aren't installed anymore
> and will delete it for you.  That's annoying.
> 
> For now, it seems the simple thing to do is to touch /lib/libc.so or
> else build and install musl again after gcc-final in order to assure
> that the target has a proper configuration of musl.  This isn't horrible
> but it is annoying given the way the embedded book is written since the
> same set of libs that are used for building are also used for the target
> and since musl's DESTDIR install will create a symlink that goes nowhere.
> 
> I'm not sure the best approach to this...  Any recommendations?

Possibly by using the '-X' switch to ldconfig, then the symlink won't be
removed.  But I believe this will mean patching gcc, but a quick check
means up to 212 times ldconfig can be called from gcc install and that
seems silly to patch all of them.  Or does it?

Would it be better to simply patch musl to have the symlink be relative
instead of absolute?  Although that's a better question for the musl ml
I think as I'm sure there's a good reason it's absolute...

Sorry I don't have any solution right now.  I thought this was working
well but apparently what ever my machine configuration was when I made
the edits to add musl meant that ldconfig wasn't doing what it does on
stock Debian Wheezy.  That's unfortunate.

-Andrew