[SOLVED] LFS 7.1 Build: File-5.10 won't compile in step 6.12
Linux From ScratchThis Forum is for the discussion of LFS.
LFS is a project that provides you with the steps necessary to build your own custom Linux system.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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?
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 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 ***
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.
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.
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.
OK.
Can you post the actual config.log files created by zlib and file?
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?
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?
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.