Glibc .fini_array support error

Pytus · 11-08-2007, 08:48 AM

Hey there, I'm just starting out on my own LFS project, and although I've been able to solve many problems myself, I've failed to solve this one particular problem.

The command I give is:

Code:

root@lfs-dev-desktop:/mnt/lfs/glibc-build# 
../glibc-2.5.1/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

The output however is:

Code:

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
configure: running configure fragment for add-on nptl
checking sysdep dirs... sysdeps/i386/elf
nptl/sysdeps/unix/sysv/linux/i386/i686
nptl/sysdeps/unix/sysv/linux/i386 sysdeps/unix/sysv/linux/i386
nptl/sysdeps/unix/sysv/linux
nptl/sysdeps/pthread sysdeps/pthread
sysdeps/unix/sysv/linux sysdeps/gnu
sysdeps/unix/common
sysdeps/unix/mman
sysdeps/unix/inet
sysdeps/unix/sysv/i386 nptl/
sysdeps/unix/sysv
sysdeps/unix/sysv
sysdeps/unix/i386 nptl/
sysdeps/unix
sysdeps/unix
sysdeps/posix
sysdeps/i386/i686/fpu nptl/sysdeps/i386/i686
sysdeps/i386/i686 sysdeps/i386/i486 nptl/
sysdeps/i386/i486 sysdeps/i386/fpu nptl/
sysdeps/i386 sysdeps/i386
sysdeps/wordsize-32
sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64
sysdeps/ieee754/flt-32
sysdeps/ieee754
sysdeps/generic/elf
sysdeps/generic
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for gcc... gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether /tools/bin/as is GNU as... yes
checking whether /tools/bin/ld is GNU ld... yes
checking for /tools/bin/as... /tools/bin/as
checking version of /tools/bin/as... 2.17, ok
checking for /tools/bin/ld... /tools/bin/ld
checking version of /tools/bin/ld... 2.17, ok
checking for pwd... /bin/pwd
checking for gcc... gcc -B/tools/bin/
checking version of gcc -B/tools/bin/... 4.1.3, ok
checking for gnumake... no
checking for gmake... no
checking for make... make
checking version of make... 3.81, ok
checking for gnumsgfmt... no
checking for gmsgfmt... no
checking for msgfmt... no
checking for makeinfo... no
checking for sed... sed
checking version of sed... 4.1.5, ok
checking for autoconf... no
configure: WARNING:
*** These auxiliary programs are missing or incompatible versions: msgfmt makeinfo autoconf
*** some features will be disabled.
*** Check the INSTALL file for required versions.
checking whether ranlib is necessary... no
checking LD_LIBRARY_PATH variable... ok
checking whether GCC supports -static-libgcc... -static-libgcc
checking for bash... /bin/bash
checking for gawk... no
checking for mawk... mawk
checking for perl... /usr/bin/perl
checking for install-info... /usr/sbin/install-info
checking for bison... no
checking for signed size_t type... no
checking for libc-friendly stddef.h... yes
checking whether we need to use -P to assemble .S files... no
checking whether .text pseudo-op must be used... yes
checking for assembler global-symbol directive... .globl
checking for .set assembler directive... no
checking for assembler .type directive prefix... @
checking for .symver assembler directive... yes
checking for ld --version-script... no
*** WARNING: You should not compile GNU libc without versioning. Not using
*** versioning will introduce incompatibilities so that old binaries
*** will not run anymore.
*** For versioning you need recent binutils (binutils-2.8.1.0.23 or newer).
checking for .previous assembler directive... yes
checking for .protected and .hidden assembler directive... yes
checking whether __attribute__((visibility())) is supported... yes
checking for broken __attribute__((visibility()))... no
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support.

I find myself unable, to troubleshoot this issue this time, and I hope it's fixable if anyone has any suggestions, I'd be glad to give it a hurl.

Thanks in advance.

osor · 11-08-2007, 11:14 AM

Quote:

Originally Posted by Pytus

I find myself unable, to troubleshoot this issue this time, and I hope it's fixable if anyone has any suggestions, I'd be glad to give it a hurl.

Perhaps you could provide some information: What LFS version are you trying? What section are you at? What binutils have you installed?

Additionally, you might look at the config.log file generated by running your configure script.

Pytus · 11-08-2007, 11:31 AM

Quote:

Originally Posted by osor

Perhaps you could provide some information: What LFS version are you trying? What section are you at? What binutils have you installed?

Additionally, you might look at the config.log file generated by running your configure script.

Well I used all the packages that were on the latest BETA LiveCD, so it would be:

binutils-2.17

I've been using the PDF variant of LFS 6.3

osor · 11-08-2007, 12:06 PM

Quote:

Originally Posted by Pytus

I've been using the PDF variant of LFS 6.3

So I presume that this is then chapter 5 section 6. Was there any problem with building or installing binutils?

Again, would you post (perhaps to a pastebin) the config.log for that configure command?

Pytus · 11-08-2007, 02:39 PM

Quote:

Originally Posted by osor

So I presume that this is then chapter 5 section 6. Was there any problem with building or installing binutils?

Again, would you post (perhaps to a pastebin) the config.log for that configure command?

You are correct, let me correct myself here.

I'm running Ubuntu 7.10 on a VMware Fusion VM on a MacBook.
I'm using the PDF version of LFS version 6.3, I've been doing everything line by line, I unpacked my Kernel into the "/mnt/lfs/" directory.

After that (Chaper 5.6) I get that error, when compiling, I'm not an overly advanced user when it comes to Linux, but I'm unable to locate the config.log file, anywhere on my system, I've even asked my best friend (google) but didn't give me any conclusive answers either.

I've got build-essentials installed, that's the only thing I installed the Ubuntu installation is absolutely clean.

I've also installed all the packages that it told me, and I retrieved those packages right from the 6.3 LiveCD in the LFS-source folder, unpacked it into the $LFS (easier) folder, and ran the command.

osor · 11-08-2007, 04:55 PM

Quote:

Originally Posted by Pytus

I unpacked my Kernel into the "/mnt/lfs/" directory.

That doesn’t make sense. First, you shouldn’t need to unpack your kernel until you get to chapter 8 or so. Also, unpacking to $LFS itself seems like it might cause undue clutter (I guess if you delete the source and build trees right away, there shouldn’t be too much trouble). A more appropriate place might be a subdirectory of $LFS. E.g., “$LFS/src” or something. So something like this is usually what should happen for 5.6:

Code:

cd $LFS/src
tar xf /path/to/glibc-2.5.1.tar.bz2
cd glibc-2.5.1
mkdir -v ../glibc-build
cd ../glibc-build
../glibc-2.5.1/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
make
#make check
mkdir -v /tools/etc
touch /tools/etc/ld.so.conf
make install
cd ..
rm -r glibc-build glibc-2.5.1

The bold text is sort of like a header/footer you might generally apply to all packages in chapter 5. The non-bold text is actually verbatim from the book.

Quote:

Originally Posted by Pytus

I'm unable to locate the config.log file, anywhere on my system, I've even asked my best friend (google) but didn't give me any conclusive answers either.

I should have clarified: a config.log is generated by each configure script. It contains the checks actually performed by configure and why they passed or failed. It will appear in the directory from which you ran configure (not the directory in which configure resides). So in the example above, there should be a text file called “$LFS/src/glibc-build/config.log” which contains the relevant information. The file is probably rather large, which is why you might post to a pastebin instead of directly on the forum.

Pytus · 11-08-2007, 05:26 PM

Quote:

Originally Posted by osor

That doesn’t make sense. First, you shouldn’t need to unpack your kernel until you get to chapter 8 or so. Also, unpacking to $LFS itself seems like it might cause undue clutter (I guess if you delete the source and build trees right away, there shouldn’t be too much trouble). A more appropriate place might be a subdirectory of $LFS. E.g., “$LFS/src” or something. So something like this is usually what should happen for 5.6:

Code:

cd $LFS/src
tar xf /path/to/glibc-2.5.1.tar.bz2
cd glibc-2.5.1
mkdir -v ../glibc-build
cd ../glibc-build
../glibc-2.5.1/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
make
#make check
mkdir -v /tools/etc
touch /tools/etc/ld.so.conf
make install
cd ..
rm -r glibc-build glibc-2.5.1

The bold text is sort of like a header/footer you might generally apply to all packages in chapter 5. The non-bold text is actually verbatim from the book.
I should have clarified: a config.log is generated by each configure script. It contains the checks actually performed by configure and why they passed or failed. It will appear in the directory from which you ran configure (not the directory in which configure resides). So in the example above, there should be a text file called “$LFS/src/glibc-build/config.log” which contains the relevant information. The file is probably rather large, which is why you might post to a pastebin instead of directly on the forum.

I think I did quite a lot of things terribly wrong, and I feel like a total douceback, not to even speak about my dissapointment (not that I anticipated it to be a walk in the park).

I have (or so I thought) successfully compiled and did the 'make install' on both Binutils, and GCC as well as the API headers.

However, I think I've slowly lost my way trying to gain help, let me explain
as far as I understand when I compiled a program, it should be found in my $LFS/tools folder.
However the folder remains empty, second, what I was saying about the kernel.

I unpacked the 'linux-2.6.22.2.tar.bz2' package directly in $LFS leaving a bit of a mess as you might reckon.
Than I did the:

Code:

make mrproper
make headers_check
etc.

All of this seemed to be progressing at a very easy, and smooth rate, as it turns out now, I've either missed some very critical points in the book, or my knowledge of linux is great disaster.

I've litterally copy-paste-ed every line of script/code, mentioned in the book.
I'm totally lost now, quite pissed on myself.

Anyhow, thanks for the enormous patience you're putting up with me.

osor · 11-09-2007, 05:27 PM

Quote:

Originally Posted by Pytus

as far as I understand when I compiled a program, it should be found in my $LFS/tools folder.
However the folder remains empty

You may have left out the symlink. Remember that $LFS (if you follow the book, it’s “/mnt/lfs”) is going to end up as your root partition for your target system. It will eventually (if you do everything correctly) end up having it’s own /bin, /usr, etc. When you reference these subdirectories (e.g., the “tools”) from the host environment, you would normally use “/mnt/lfs/tools”, and from the target environment, you would use “/tools” instead. But some automatic configuration (by the linker and compiler) will hardcode directory locations. So it is beneficial to refer to the same name. Thus, there is a symlink created on the host system with /tools pointing to /mnt/lfs/tools. With this, you can access the desired directory with the same name (/tools) in both the host and target environments. This is explained in the book.

Quote:

Originally Posted by Pytus

second, what I was saying about the kernel.

Forget about the kernel until chapter 8.

Quote:

Originally Posted by Pytus

I've litterally copy-paste-ed every line of script/code, mentioned in the book.

Well, that’s your problem then… you have to read the book. Read it in order. Read it carefully. If you read the book (carefully and in order) you would know about the symlink. You would know about unpacking sources. You would know about not doing anything with the kernel (beyond obtaining the tarball) until chapter 8.