LinuxQuestions.org - [SOLVED] LFS 7.1 Build: File-5.10 won't compile in step 6.12

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

- - LFS 7.1 Build: File-5.10 won't compile in step 6.12 (https://www.linuxquestions.org/questions/linux-from-scratch-13/lfs-7-1-build-file-5-10-wont-compile-in-step-6-12-a-4175422627/)

LFS 7.1 Build: File-5.10 won't compile in step 6.12

Hi guys. Newbie LFS builder here going thru the LFS 7.1 book. I have gone thru all steps prior to the subject one with no problems, but File-5.10 refuses to compile. It fails with the following error:

Quote:

CC ascmagic.lo
CC encoding.lo
CC compress.lo
CC is_tar.lo
CC readelf.lo
CC print.lo
CC fsmagic.lo
CC funcs.lo
CC apptype.lo
CC cdf.lo
CC cdf_time.lo
CC readcdf.lo
CC strlcpy.lo
CC strlcat.lo
CCLD libmagic.la
/tools/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../x86_64-unknown-linux-gnu/bin/ld: /usr/lib/libz.a(inflate.o): relocation R_X86_64_32S against `zcfree' can not be used when making a shared object; recompile with -fPIC
/usr/lib/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libmagic.la] Error 1
make[2]: Leaving directory `/sources/file-5.10/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/sources/file-5.10'
make: *** [all] Error 2

Any idea what I have done wrong and what I need to do now to fix it? Any help would be appreciated.

Quote:

Originally Posted by bbradley1946

Code:

CC readcdf.lo

 CC strlcpy.lo

 CC strlcat.lo

 CCLD libmagic.la

 /tools/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../x86_64-unknown-linux-gnu/bin/ld: /usr/lib/libz.a(inflate.o): relocation R_X86_64_32S against `zcfree' can not be used when making a shared object; recompile with -fPIC

 /usr/lib/libz.a: could not read symbols: Bad value

 collect2: ld returned 1 exit status

 make[2]: *** [libmagic.la] Error 1

 make[2]: Leaving directory `/sources/file-5.10/src'

I'm guessing something went wrong in chapter 6.10. The blue part points to /tools/lib, which I believe is wrong. A quote from that chapter:

Quote:

In Chapter 5, the chain was guided from the host's /{,usr/}lib directories to the new /tools/lib directory. Now, the chain will be guided from that same /tools/lib directory to the LFS /{,usr/}lib directories.

Did all the checks you did in chapter 6.10 have the desired results?

Thanx for responding, druuna. I checked my activity for 6.10, and all appears to be OK. The entire command sequence as executed is as follows:

Quote:

root on Slackware @ /sources/glibc-build
===> mv -v /tools/bin/{ld,ld-old}
`/tools/bin/ld' -> `/tools/bin/ld-old'

root on Slackware @ /sources/glibc-build
===> mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
`/tools/x86_64-unknown-linux-gnu/bin/ld' -> `/tools/x86_64-unknown-linux-gnu/bin/ld-old'

root on Slackware @ /sources/glibc-build
===> mv -v /tools/bin/{ld-new,ld}
`/tools/bin/ld-new' -> `/tools/bin/ld'

root on Slackware @ /sources/glibc-build
===> ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld
`/tools/x86_64-unknown-linux-gnu/bin/ld' -> `/tools/bin/ld'

root on Slackware @ /sources/glibc-build
===> gcc -dumpspecs | sed -e 's@/tools@@g' \
> -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \
> -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \
> `dirname $(gcc --print-libgcc-file-name)`/specs

root on Slackware @ /sources/glibc-build
===> echo 'main(){}' > dummy.c

root on Slackware @ /sources/glibc-build
===> cc dummy.c -v -Wl,--verbose &> dummy.log

root on Slackware @ /sources/glibc-build
===> readelf -l a.out | grep ': /lib'
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

root on Slackware @ /sources/glibc-build
===> grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log
/usr/lib/crt1.o succeeded
/usr/lib/crti.o succeeded
/usr/lib/crtn.o succeeded

root on Slackware @ /sources/glibc-build
===> grep -B1 '^ /usr/include' dummy.log
#include <...> search starts here:
/usr/include

root on Slackware @ /sources/glibc-build
===> grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'
SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib64")
SEARCH_DIR("/tools/x86_64-unknown-linux-gnu/lib")
SEARCH_DIR("/usr/lib")
SEARCH_DIR("/lib");

root on Slackware @ /sources/glibc-build
===> grep "/lib.*/libc.so.6 " dummy.log
attempt to open /lib64/libc.so.6 succeeded

root on Slackware @ /sources/glibc-build
===> grep found dummy.log
found ld-linux-x86-64.so.2 at /lib64/ld-linux-x86-64.so.2

root on Slackware @ /sources/glibc-build
===> rm -v dummy.c a.out dummy.log
removed `dummy.c'
removed `a.out'
removed `dummy.log'

Maybe you see something I missed. If not, any other ideas?

I don't see anything wrong with the above posted sequence....

Just noticed, have a look at this:

Quote:

/usr/lib/libz.a: could not read symbols: Bad value

zlib was build and installed in the previous chapter.

You don't mention having trouble with zlib, but maybe you need to double check that one as well (if you haven't done so already).

EDIT: If that doesn't solve anything, can you post the config.log files for both zlib and file?

Re the command sequence for 6.10, I would like to double-check something. In the step

Quote:

root on Slackware @ /sources/glibc-build
===> gcc -dumpspecs | sed -e 's@/tools@@g' \
> -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \
> -e '/\*cpp:/{n;s@$@ -isystem /usr/include@}' > \
> `dirname $(gcc --print-libgcc-file-name)`/specs

the output spec file in my system expands to

Quote:

/tools/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/specs

The file is being correctly modified to remove all '/tools' references, but is it in the right place to be picked up in subsequent compiles since it itself is located under /tools. If I rerun 'gcc -dumpspecs' again after running the step, it still displays the old specs including the '/tools' references.

Re the build for zlib, I checked the command sequence and it looks OK. It is shown below.

Quote:

root on Slackware @ /sources/zlib-1.2.7
===> ./configure --prefix=/usr
Checking for gcc...
Checking for shared library support...
Building shared library libz.so.1.2.7 with gcc.
Checking for off64_t... Yes.
Checking for fseeko... Yes.
Checking for strerror... Yes.
Checking for unistd.h... Yes.
Checking for stdarg.h... Yes.
Checking whether to use vs[n]printf() or s[n]printf()... using vs[n]printf().
Checking for vsnprintf() in stdio.h... Yes.
Checking for return value of vsnprintf()... Yes.
Checking for attribute(visibility) support... Yes.
Looking for a four-byte integer type... Found.

root on Slackware @ /sources/zlib-1.2.7
===> make
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -c -o example.o test/example.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o adler32.o adler32.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o crc32.o crc32.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o deflate.o deflate.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o infback.o infback.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o inffast.o inffast.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o inflate.o inflate.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o inftrees.o inftrees.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o trees.o trees.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o zutil.o zutil.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o compress.o compress.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o uncompr.o uncompr.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o gzclose.o gzclose.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o gzlib.o gzlib.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o gzread.o gzread.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -c -o gzwrite.o gzwrite.c
ar rc libz.a adler32.o crc32.o deflate.o infback.o inffast.o inflate.o inftrees.o trees.o zutil.o compress.o uncompr.o gzclose.o gzlib.o gzread.o gzwrite.o
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example example.o -L. libz.a
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -c -o minigzip.o test/minigzip.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip minigzip.o -L. libz.a
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/adler32.o adler32.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/crc32.o crc32.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/deflate.o deflate.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/infback.o infback.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/inffast.o inffast.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/inflate.o inflate.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/inftrees.o inftrees.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/trees.o trees.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/zutil.o zutil.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/compress.o compress.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/uncompr.o uncompr.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/gzclose.o gzclose.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/gzlib.o gzlib.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/gzread.o gzread.c
gcc -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -DPIC -c -o objs/gzwrite.o gzwrite.c
gcc -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o libz.so.1.2.7 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo -lc
rm -f libz.so libz.so.1
ln -s libz.so.1.2.7 libz.so
ln -s libz.so.1.2.7 libz.so.1
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o examplesh example.o -L. libz.so.1.2.7
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzipsh minigzip.o -L. libz.so.1.2.7
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -D_FILE_OFFSET_BITS=64 -c -o example64.o test/example.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o example64 example64.o -L. libz.a
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -I. -D_FILE_OFFSET_BITS=64 -c -o minigzip64.o test/minigzip.c
gcc -O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -o minigzip64 minigzip64.o -L. libz.a

root on Slackware @ /sources/zlib-1.2.7
===> make check
hello world
zlib version 1.2.7 = 0x1270, compile flags = 0xa9
uncompress(): hello, hello!
gzread(): hello, hello!
gzgets() after gzseek: hello!
inflate(): hello, hello!
large_inflate(): OK
after inflateSync(): hello, hello!
inflate with dictionary: hello, hello!
*** zlib test OK ***
hello world
zlib version 1.2.7 = 0x1270, compile flags = 0xa9
uncompress(): hello, hello!
gzread(): hello, hello!
gzgets() after gzseek: hello!
inflate(): hello, hello!
large_inflate(): OK
after inflateSync(): hello, hello!
inflate with dictionary: hello, hello!
*** zlib shared test OK ***
hello world
zlib version 1.2.7 = 0x1270, compile flags = 0xa9
uncompress(): hello, hello!
gzread(): hello, hello!
gzgets() after gzseek: hello!
inflate(): hello, hello!
large_inflate(): OK
after inflateSync(): hello, hello!
inflate with dictionary: hello, hello!
*** zlib 64-bit test OK ***

root on Slackware @ /sources/zlib-1.2.7
===> make install
cp libz.a /usr/lib
chmod 644 /usr/lib/libz.a
cp libz.so.1.2.7 /usr/lib
chmod 755 /usr/lib/libz.so.1.2.7
cp zlib.3 /usr/share/man/man3
chmod 644 /usr/share/man/man3/zlib.3
cp zlib.pc /usr/lib/pkgconfig
chmod 644 /usr/lib/pkgconfig/zlib.pc
cp zlib.h zconf.h /usr/include
chmod 644 /usr/include/zlib.h /usr/include/zconf.h

root on Slackware @ /sources/zlib-1.2.7
===> mv -v /usr/lib/libz.so.* /lib
`/usr/lib/libz.so.1' -> `/lib/libz.so.1'
`/usr/lib/libz.so.1.2.7' -> `/lib/libz.so.1.2.7'

root on Slackware @ /sources/zlib-1.2.7
===> ln -sfv ../../lib/libz.so.1.2.6 /usr/lib/libz.so
`/usr/lib/libz.so' -> `../../lib/libz.so.1.2.6'

However, maybe it is corrupted by the same problem affecting File, and will have to be rebuilt anyway.

I think I solved the problem. As a followup to running the step

Quote:

in 6.10, I did the following to make gcc find the updated specs file:

Quote:

root on Slackware @ /sources/file-5.10
===> export CFLAGS=-specs=`dirname $(gcc --print-libgcc-file-name)`/specs

After this I redid steps 6.11 and 6.12 for Zlib and File and they went clean.
If this sort of step is required in 6.10, perhaps it should be documented in the book.

Quote:

Originally Posted by bbradley1946 (Post 4757018)

I think I solved the problem. As a followup to running the step

in 6.10, I did the following to make gcc find the updated specs file:

After this I redid steps 6.11 and 6.12 for Zlib and File and they went clean.
If this sort of step is required in 6.10, perhaps it should be documented in the book.

I'm not sure you solved the underlying problem. No extra steps/actions are needed or wanted. In general: If you need to, something is wrong.

There is one thing I like to know before digging any deeper: Have you (partially) automated the build? I'm asking because the output you posted here looks nice and uniform, something a script would produce.

No automation here. The output was produced by simply scrolling back the terminal output and copying and pasting what I needed. The terminal history limit is set high.

I am building this in a Virtualbox VM using Slackware Current as the host. When I have to shut down I just save the machine state and restore it when I continue.

Quote:

Originally Posted by bbradley1946 (Post 4757480)

OK.

Can you post the actual config.log files created by zlib and file?

Quote:

Can you post the actual config.log files created by zlib and file?

Oops, I am afraid I can't. I had already continued compiling until I had completed gcc in 6.17, and like a good little housekeeper, I cleaned up after myself as per instructions in the book. All the compiles, including tests, completed as per expected results.
If you think it is worthwhile, I could unpack zlib and file again, run configure for both, and report the resulting logs, but since gcc has now been recompiled the environment has changed and results may not be useful.
Re gcc, after the recompile, I reran 'gcc -dumspecs ' and checked the output and there are no longer any occurrances of '/tools' in it, so I could probably clear the CFLAGS variable assuming carrying on is an option.
Where should I go from here?

Quote:

Originally Posted by bbradley1946 (Post 4757612)

If the complete set of tests in chapter 6.17 were completed successfully I would unset/undo the CFLAFS variable and possible other changes you made and then continue with 6.18.

I shall do that. Onward and upward :D