Alexey Orishko | 18 Feb 21:50 2014

DHCPCD: bonding

Hi guys,

Booting clfs 2.1.0 with two separate eth i/f works fine, but no
description for making bonding work.
I was not able to find any useful info on the subject and its author
replied to the question with
"asking your linux distro vendor".. Well, it is hard in CLFS case :-)
The only option I see now to compile dhcpd client instead and use old
lfs-6.3 setup I have.

Have anyone managed to configure bonding with dhcpcd for at least two
eth interfaces (eth0 and eth1)?

thomas kaeding | 17 Feb 21:28 2014

where are the patches kept?


Where are the cross-blfs patches?  At the moment I need
the multilib patch for Python, but I know I will need to find
others.  But I can't find a link on the wiki.  I can only find
the blfs patches, which are not multilib.

Alexey Orishko | 17 Feb 17:26 2014

Re: Mounting Kernel Filesystems

On Mon, Feb 17, 2014 at 7:05 AM, Chris Staub <chris <at>> wrote:
> Looks like you didn't chown the /tools and /cross-tools directory to root.
no cross tools mentioned in chapter 8.5 Entering the Chroot Environment (CLFS):
chroot "${CLFS}" /tools/bin/env -i \
    HOME=/root TERM="${TERM}" PS1='\u:\w\$ ' \
    PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
    /tools/bin/bash --login +h

Alexey Orishko | 17 Feb 01:40 2014

Mounting Kernel Filesystems

Hi guys,

I'm doing chroot CLFS 2.1.0 x86 variant and I need a clarification in
the chapter 8.10.1 for two mount commands:
mount -vt devpts -o gid=5,mode=620 none /dev/pts
mount -vt tmpfs none /dev/shm

Am I supposed to run them in chroot environment or would it be
sufficient to do similar commands in 8.3 executed as host's root user?

While doing them in chroot I got an error:
chroot. root:/$ id
uid=0(root) gid=0(root) groups=0(root)
chroot. root:/$ mount -vt tmpfs none /dev/shm
mount: only root can use "--types" option (effective UID is 2xxx)

where 2xxx is the UID of the local clfs user on host system.
How could clfs user be involved?

Alexey Orishko | 16 Feb 22:24 2014

CLFS eudev vs LFS udev

Hi guys,

I have an old LFS 6.3 system I'm going to upgrade.
I've noticed that LFS-7.4 and CLFS 2.1.0 have two different udev variants.

A few questions related to that:
- Will CLFS and LFS go different ways in package selection? (udev in particular)
- Which one udev variant CLFS Eudev-1.3 or LFS Udev-206 (Extracted
from systemd-206)
  would you recommend?
  I'm aiming at minimum changes needed while moving from legacy udev.

Sela Selah | 13 Feb 13:59 2014

issue about gcc and e2fsprogs

In chapter 6.10, after modify the Makefile by sed:

If xxxLIBS & xxxINC = /tools/, make will results the header error.

If xxxLIBS & xxxINC = /cross-tools/, make will results the wrong lib format error.

Only xxxLIBS = /tools/ && xxxINC=/cross-tools/, the compiling could complete.

This issue I had meet ever. Now I do the compiling in a new platform (hardware and os), the same issue remains.


In chapter 7.7

The compiling results error: conflict type.

in the build/lib/ext2fs/ext2_type.h, the _u64 typedef with unsigned long long,

but in the kernel header, the _u64 typedef with unsigned long.

The type _s64 has similar comfliction

Maybe it’s a e2fsprogs bug:

In file root/lib/ext2fs/

Line 89, the comment about SIZEOF_LONG_LONG/SIZEOF_LONG is *NOT* consists with the if-else branch:

#ifdef __U64_TYPEDEF

typedef __U64_TYPEDEF __u64;


#if ( <at> SIZEOF_INT <at> == 8)

typedef unsigned int        __u64;


#if ( <at> SIZEOF_LONG_LONG <at> == 8) // < ------- should long branch

typedef unsigned long long      __u64;


#if ( <at> SIZEOF_LONG <at> == 8)

typedef unsigned long     __u64;  // < ------- should long long branch

#endif /* SIZEOF_LONG_LONG == 8 */

#endif /* SIZEOF_LONG == 8 */

#endif /* SIZEOF_INT == 8 */

#endif /* __U64_TYPEDEF */


#ifdef __S64_TYPEDEF

typedef __S64_TYPEDEF __s64;


#if ( <at> SIZEOF_INT <at> == 8)

typedef int                 __s64;


#if ( <at> SIZEOF_LONG_LONG <at> == 8)

#if defined(__GNUC__)    // < --------------- should long branch

typedef __signed__ long long __s64;


typedef signed long long __s64;

#endif /* __GNUC__ */


#if ( <at> SIZEOF_LONG <at> == 8)

typedef long              __s64; // < ------------ should long long branch

#endif /* SIZEOF_LONG_LONG == 8 */

#endif /* SIZEOF_LONG == 8 */

#endif /* SIZEOF_INT == 8 */

#endif /* __S64_TYPEDEF */


After I exchange the inconsist branches, all things work fine.


Clfs-support mailing list
Clfs-support <at>
Alexey Orishko | 12 Feb 20:57 2014

Test failed for 10.7. EGLIBC-2.18

Hi all,

I'm building i686-pc-linux-gnu-gcc target on Ubuntu 64-bit (intel).
While running test suite for EGLIBC ch.10.7 I've got some errors:
make[2]: Leaving directory `/sources/eglibc-2.18/elf'
scripts/ sysdeps/unix/sysv/linux/i386/nptl/ g++
      > /sources/eglibc-build/c++-types-check.out
AWK='gawk' scripts/ \
  "/usr/include" "/sources/eglibc-build/" >
/usr/bin/perl scripts/ argp/argp.h assert/assert.h
wctype/wctype.h > /sources/eglibc-build/begin-end-check.out
make[1]: Target `check' not remade because of errors.
make[1]: Leaving directory `/sources/eglibc-2.18'
make: *** [check] Error 2
make[2]: *** [/sources/eglibc-build/posix/tst-getaddrinfo4.out] Error 1
make[2]: [/sources/eglibc-build/posix/annexc.out] Error 1 (ignored)
make[1]: *** [posix/tests] Error 2
make[2]: [/sources/eglibc-build/conform/run-conformtest.out] Error 1 (ignored)
make[2]: *** [/sources/eglibc-build/debug/tst-backtrace6.out] Error 1
make[1]: *** [debug/tests] Error 2
make: *** [check] Error 2

posix/annexc.out has a lot of messages:
Tested files:
=== aio.h ===
*  invalid macro `SIGEV_THREAD_ID'
*  invalid macro `sigev_notify_function'
*  invalid macro `sigev_notify_attributes'
** macro `FD_CLOEXEC' not defined
** macro `F_DUPFD' not defined
=== dirent.h ===
*  invalid macro `d_fileno'
=== errno.h ===
=== fcntl.h ===
*  invalid macro `F_EXLCK'
=== limits.h ===
*  invalid macro `SSIZE_MAX'
*  invalid macro `XATTR_SIZE_MAX'
*  invalid macro `HOST_NAME_MAX'

I'm building clfs exactly as book says for x86 on x86_64, so should I really
worry about these negative test results or simply ignore them?

thomas kaeding | 12 Feb 02:30 2014


These refer to git-20140202, x86_64 multilib

1.  sec 10.37: the patch makes 'make get' unnecessary

2.  sec 10.36:  "check" is missing from "make NON_ROOT_USERNAME=dummy"

3.  sec 10.26 & 27:  the symlinks and includes make an
     infinite loop involving &
thomas kaeding | 10 Feb 06:02 2014

final gcc build failing in git-20140202 x86_64 multilib


final gcc build failing in git-20140202 x86_64 multilib in section 10.23

configure: error: in `/sources/gcc-build/x86_64-unknown-linux-gnu/32/libgcc':
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
Makefile:14626: recipe for target 'configure-stage1-target-libgcc' failed
make[2]: *** [configure-stage1-target-libgcc] Error 1
make[2]: Leaving directory '/sources/gcc-build'
Makefile:18767: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sources/gcc-build'
Makefile:885: recipe for target 'all' failed
make: *** [all] Error 2

even after doing `ln -s /tools/bin/cpp /lib/' and rerunning the configuration:

In file included from /usr/include/features.h:388:0,
                 from /usr/include/stdio.h:27,
                 from ../../../../gcc-4.8.2/libgcc/../gcc/tsystem.h:87,
                 from ../../../../gcc-4.8.2/libgcc/libgcc2.c:27:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such
file or directory
 # include <gnu/stubs-32.h>
compilation terminated.
Makefile:460: recipe for target '_muldi3.o' failed
make[5]: *** [_muldi3.o] Error 1
make[5]: Leaving directory
Makefile:1104: recipe for target 'multi-do' failed
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory '/sources/gcc-build/x86_64-unknown-linux-gnu/libgcc'
Makefile:113: recipe for target 'all-multi' failed
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory '/sources/gcc-build/x86_64-unknown-linux-gnu/libgcc'
Makefile:14905: recipe for target 'all-stage1-target-libgcc' failed
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/sources/gcc-build'
Makefile:18767: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sources/gcc-build'
Makefile:885: recipe for target 'all' failed
make: *** [all] Error 2
Alexey Orishko | 9 Feb 16:21 2014

Errata for CLFS 2.1.0

Hi Guys,

I have a couple of questions regarding errata for CLFS 2.1

1. While reading ch.8.2 and errata "Boot and Chroot method Util-Linux"
" ..Hosts with Pkg-config installed Add PKG_CONFIG= before ./configure
PKG_CONFIG= ./configure ... "

I'm a bit confused about errata meaning. Having space after equal sign and
no `` signs, what are we supposed to do in bash with PKG_CONFIG env var?

2. In 8.4.1 it was suggested to extract the "Automake-1.12.4" tarball and cd
into the created directory. Then execute the following to see what the
detected target triplet is by config.guess:

Well, I don't see build-aux in extracted tar ball.
After extracting tar ball and cd into extracted dir I found

Should command in ch. 8.4.1 be corrected?

Kevyn-Alexandre Paré | 7 Feb 01:25 2014

Fwd: CLFS support


---------- Forwarded message ----------
From: Kevyn-Alexandre Paré <kapare <at>>
Date: Thu, Feb 6, 2014 at 6:54 PM
Subject: Re: [Clfs-support] CLFS support
To: Andrew Bradford <andrew <at>>


On Thu, Feb 6, 2014 at 2:17 PM, Andrew Bradford
<andrew <at>> wrote:
> On 02/06/2014 02:08 PM, Kevyn-Alexandre Paré wrote:
>> no symlink for /lib/ in the target. When this
>> symlink is suppose to be created?
> In section 4.8 (musl-libc), the 'make install' should create it for you
> properly as long as you're using DESTDIR as specified in the book.

Here what I'm using in my script:
CC=${CLFS_TARGET}-gcc ./configure \
  --prefix=/ \
CC=${CLFS_TARGET}-gcc make
DESTDIR=${CLFS}/cross-tools/${CLFS_TARGET} make install

> So long as you're using a book newer than 20131023, this should work.
> Books prior to 20131023 which were musl based required a manual creation
> of this symlink due to incorrect 'make install' instructions for the way
> musl's install works.

I'm using your git repo directly:

Version GIT-20131024-arm