[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