LinuxQuestions.org - Directories for Package Installation 6.1.1

- Linux From Scratch (https://www.linuxquestions.org/questions/linux-from-scratch-13/)

- - Directories for Package Installation 6.1.1 (https://www.linuxquestions.org/questions/linux-from-scratch-13/directories-for-package-installation-6-1-1-a-442255/)

Directories for Package Installation 6.1.1

Hi Everbody,

I realize this is an elementary question, but I have two concerns. I have installed Binutils and GCC and am now in the process of installing Linux-Libc-Headers. The instructions directed me to create a separate build directory for Binutils and GCC, one for each. There is no such instruction for decompressing and installing the Linux-Libc-Headers package. Where do I install it? After installation, I have do this command:

Code:

cp -Rv include/asm-i386 /usr/include/asm

cp -Rv include/linux /usr/include

These locations to do not yet exist, so I am assuming these files will be found in Linux-Libc-Headers. I just don't want the files from the host system to be corrupted or interfere with this project. Does each package have to have its own build directory?

Any help would be greatly appreciated.

Bob

Not going to plan..

Well, every turn is a new advernture. Got the headers installed, now trying to install Glibc-2.3.4, per instruction and created a glibc-build directory to decompress it. Did so, and expecting to ./configure make make install, I get this:

Code:

lfs:/mnt/lfs/glibc-build/glibc-2.3.4$ ./configure --prefix=/tools \

>    --disable-profile --enable-add-ons \

>    --enable-kernel=2.6.0 --with-binutils=/tools/bin \

>    --without-gd --with-headers=/tools/include \

>    --without-selinux

configure: error: you must configure in a separate build directory

If I just move it to another directory, same error. How can you build/configure glibc-2.3.4 outside of the glibc-2.3.4 directory. Trying that just results in a "no such file or directory"

Anyone have any ideas?

Thanks

Bob

Try doing this:

Code:

cd .. &&

mv glibc-2.3.4/ ../ &&

../glibc-2.3.4/configure --prefix=/tools \

    --disable-profile --enable-add-ons \

    --enable-kernel=2.6.0 --with-binutils=/tools/bin \

    --without-gd --with-headers=/tools/include \

    --without-selinux

Since you extracted glibc in the glibc-build directory, this should do the trick.

The source and build directories for glibc should be located next to eachother, eg;
$LFS/sources/glibc-2.3.4
$LFS/sources/glibc-build

Here is an excample:

Step into your sources directory;

Code:

cd $LFS/sources

Unpack glibc and step into the directory;

Code:

bunzip2 glibc-2.3.4.tar.bz2

tar xf glibc-2.3.4.tar

cd glibc-2.3.4

Apply patch if necessary;

Code:

patch -Np1 -i ../glibc-2.3.4-fix_test-1.patch

Create the build dir one level higher and step into it;

Code:

mkdir -v ../glibc-build

cd ../glibc-build

Then from within the build dir run the configure command like next;

Code:

../glibc-2.3.4/configure --prefix=/tools \

--disable-profile --enable-add-ons \

--enable-kernel=2.6.0 --with-binutils=/tools/bin \

--without-gd --with-headers=/tools/include \

--without-selinux

EDIT; sorry for crosspost Seph64.

Thanks for your responses. Unfortunately, I suppose I am biting off more than I can chew. I did finally get glibc to compile by taking your suggestion, but added another directory called "build" one up from glibc-build, and it worked.

Now, having compiled, tested, and installed, and running the specfile linker below:

Code:

root:/mnt/lfs# SPECFILE=`gcc --print-file specs` &&

> sed 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \

>    $SPECFILE > tempspecfile &&

> mv -f tempspecfile $SPECFILE &&

> unset SPECFILE

I then run the "sanity check" commands:

Code:

lfs:/mnt/lfs$ echo 'main(){}' > dummy.

lfs:/mnt/lfs$ gcc dummy.c

lfs:/mnt/lfs$ readelf -l a.out | grep ': /tools'

and nothing happens. According to the instructions, this means somethings has gone wrong and it is not working. I don't really have the necessary knowledge to track down where I went wrong. If I can't fix it somehow and get the necessary return from these commands (Requesting Program Interpreter...), I'll just have to admit defeat on this one. I suppose I could wipre the drive and start again....but this has been alot of work already, not really keen to start again if there is any way around it.

If anyone has any suggestions, it would be very much appreciated.

Bob

Good try, I suppose

http://images.linuxquestions.org/que...s/confused.gif
Well, I will post this to see if anyone has any thoughts on what is going on, and if its to far gone to fix, I guess I will just chalk this one up to experience.

Got to the 2nd pass of Binutils, and except for some permissions errors, all seemed to be going according to the instructions. This one just might do me in on this attempt, though. Got this when I attempted "make" on the 2nd pass for binutils:

Code:

bucomm.o(.text+0x415):bucomm.c: undefined reference to `bfd_set_format'

bucomm.o(.text+0x46a):bucomm.c: undefined reference to `bfd_close_all_done'

bucomm.o(.text+0x668):bucomm.c: undefined reference to `bfd_close_all_done'

bucomm.o(.text+0x693):bucomm.c: undefined reference to `bfd_openw'

bucomm.o(.text+0x6ae):bucomm.c: undefined reference to `bfd_set_format'

bucomm.o(.text+0x726):bucomm.c: undefined reference to `bfd_get_error'

bucomm.o(.text+0x7e1):bucomm.c: undefined reference to `bfd_get_error'

bucomm.o(.text+0x9eb): In function `parse_vma':

bucomm.c: undefined reference to `bfd_scan_vma'

../bfd/.libs/libbfd.so: undefined reference to `bfd_elf32_i386_vec'

../bfd/.libs/libbfd.so: undefined reference to `bfd_efi_app_ia32_vec'

../bfd/.libs/libbfd.so: undefined reference to `symbolsrec_vec'

../bfd/.libs/libbfd.so: undefined reference to `bfd_malloc'

../bfd/.libs/libbfd.so: undefined reference to `bfd_elf32_little_generic_vec'

../bfd/.libs/libbfd.so: undefined reference to `i386linux_vec'

../bfd/.libs/libbfd.so: undefined reference to `srec_vec'

../bfd/.libs/libbfd.so: undefined reference to `binary_vec'

../bfd/.libs/libbfd.so: undefined reference to `ihex_vec'

../bfd/.libs/libbfd.so: undefined reference to `tekhex_vec'

../bfd/.libs/libbfd.so: undefined reference to `bfd_i386_arch'

../bfd/.libs/libbfd.so: undefined reference to `trad_core_vec'

../bfd/.libs/libbfd.so: undefined reference to `bfd_elf32_big_generic_vec'

collect2: ld returned 1 exit status

make[3]: *** [size] Error 1

make[3]: Leaving directory `/mnt/lfs/binutils-build/binutils-2.15.94.0.2.2/binutils'

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/mnt/lfs/binutils-build/binutils-2.15.94.0.2.2/binutils'

make[1]: *** [all-recursive-am] Error 2

make[1]: Leaving directory `/mnt/lfs/binutils-build/binutils-2.15.94.0.2.2/binutils'

make: *** [all-binutils] Error 2

It looks like I have failed in a previous linking instruction.

It anyone knows what this is and if it can be fixed, I would sure appreciate the help. However, if the opinion is I should forget this attempt and maybe try again, if anyone knows where I went wrong it would help on a future attempt to do this.

Thanks

Bob

Update...progress

What a ride! Just when I think I have had it, no way I am going to be able to actually finish thing, a little progress, and, VIOLA! All the preliminary packages have compiled and been installed, with make test on all of them, which all passed.

I have reached the point of actually chrooting into the new system to install the packages directly (Chapter 6.3). Well, one more little road block to solve, but it has me stumped a little. Here it is:

Code:

chroot "$LFS" /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

And I get this:

Code:

/tools/bin/bash: error while loading shared libraries: libtermcap.so.2: cannot open shared object file: No such file or directory

Well, the missing library is there:

Code:

root:/mnt/lfs# locate libtermcap.so.2

/lib/libtermcap.so.2.0.8

/lib/libtermcap.so.2

I'll keep working at it, but it would sure help if anyone can tell me what is going on. I can taste success, won't give up now!

Any help appreciated.

Bob