[Clfs-support] CLFS support

Andrew Bradford andrew at bradfordembedded.com
Tue Feb 11 05:58:12 PST 2014


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.

Thanks,
Andrew

> On Mon, Feb 10, 2014 at 7:43 PM, Kevyn-Alexandre Paré
> <kapare at rogue-research.com> wrote:
>> I add a test -L
>> "/mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1"
>>
>> after make install in Section 4.8. musl-libc-0.9.14 and everything is fine
>>
>> But after the section of # 4.9. GCC-4.7.3 - Final the link doesn't
>> exist anymore?
>> ../gcc-4.7.3/configure \
>>   --prefix=${CLFS}/cross-tools \
>>   --build=${CLFS_HOST} \
>>   --target=${CLFS_TARGET} \
>>   --host=${CLFS_HOST} \
>>   --with-sysroot=${CLFS}/cross-tools/${CLFS_TARGET} \
>>   --disable-nls \
>>   --enable-languages=c,c++ \
>>   --enable-c99 \
>>   --enable-long-long \
>>   --disable-libmudflap \
>>   --disable-multilib \
>>   --with-mpfr-include=$(pwd)/../gcc-4.7.3/mpfr/src \
>>   --with-mpfr-lib=$(pwd)/mpfr/src/.libs \
>>   --with-arch=${CLFS_ARM_ARCH} \
>>   --with-float=${CLFS_FLOAT} \
>>   --with-fpu=${CLFS_FPU}
>> make -j${NBJOBS} > /dev/null
>> make install
>>
>>
>> So the make install seem to be the problem here:
>> here my log:
>> http://pastebin.com/z56HN2yY
>>
>> I searching for something that effect
>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib
>>
>> thx
>>
>> -KA
>>
>> On Mon, Feb 10, 2014 at 6:14 PM, Kevyn-Alexandre Paré
>> <kapare at rogue-research.com> wrote:
>>>>> ./tools/install.sh -D -l /lib/libc.so
>>>>> /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1 ||
>>>>> true
>>>>
>>>> <snip>
>>>>
>>>>> Don't see the ld-musl-armhf.so?
>>>>
>>>> Just before my snip is the ld-musl-armhf.so.1 getting installed as a
>>>> symlink to /lib/libc.so.  If this fails, the "|| true" makes sure it
>>>> doesn't cause an error.  The symlink failing isn't an error condition if
>>>> you're just making a cross compiler and not also a root fs, thus it
>>>> shouldn't fail most of the time for the way the musl devs use it.
>>>>
>>>> Since the symlink's target is a full path, if you weren't actually
>>>> running a root file system using musl, that symlink may point to your
>>>> build host's libc which likely isn't musl.
>>>>
>>>
>>> So since I have created a script, bash, that run all the procedure
>>> this particular command in the script was failing ? But if I run it
>>> manually it works...
>>>
>>> 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
>>> clfs at knight:/mnt/clfs/sources$ ls /lib/libc.so
>>> ls: cannot access /lib/libc.so: No such file or directory
>>> clfs at knight:/mnt/clfs/sources$ cd musl-0.9.14
>>> clfs at knight:/mnt/clfs/sources/musl-0.9.14$ ./tools/install.sh -D -l
>>> /lib/libc.so /mnt/clfs/cross-tools/arm-linux-musleabihf/lib/ld-musl-armhf.so.1
>>> || true
>>> clfs at knight:/mnt/clfs/sources/musl-0.9.14$ 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
>>>
>>> I made smaller script that do only musl cross compilation and it's
>>> working file and creating the symlink so I will try to see why my
>>> script is not behaving as expected.
>>>
>>> thx,
>>>
>>> -KA




More information about the Clfs-support mailing list