[Clfs-support] CLFS support

[Andrew Bradford]

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?

Thanks,
Andrew