p54 'make -C ld clean' -> no ld directory
chris at beaker67.com
Thu Nov 3 20:25:31 PST 2005
Micheal E Cooper wrote:
> As an addition and in good faith, the only FAQ entry that looks like my
> problem is:
> ld: cannot find -lc
> You get a message early in chapter 5 (LFS-4.1) or at the first pass of
> gcc (LFS CVS) which ends like this:
> -static -o gengenrtl \ gengenrtl.o ../libiberty/libiberty.a
> ld: cannot find -lc
> collect2: ld returned 1 exit status
> Your host system is probably Mandrake 9 or higher. By default, its
> base system does not have a static C library (/usr/lib/libc.a) which
> is required for the static compilation of packages.
> You need to install the glibc-static-devel RPM, which is on the third
> CD. You can verify the succesfull installation by verifying that
> /usr/lib/libc.a exists. If you're using LFS 4.1, check that everything
> in $LFS/static/bin is built static by using file $LFS/static/bin/*. If
> a package is not statically linked, reinstall it with the instructions
> from chapter 5.
> However, it is not the same error message, and I am getting errors when I
> try to install binutils itself. Also, I am using FC4, not Mandrake.
> Do FC4 and Mandrake have the same problem?
No, the Mandrake problem is a completely unrelated issue with a much
older version of lfs (and I believe that entry should be removed from
>>If I end up violated etiquette, please tell me and I will change my
>>Now onto my problem:
>>After I went through the bin-utils "configure - make - make install"
>>sequence, I tried to execute the commands on page 54:
>>make -C ld clean
>>But an error tells me that there is no such directory as ld.
>>The only thing that I can think would have caused a problem is that, the
>>first time I tried to compile and install bin-utils, I did it using the
>>time function, with the syntax on LFS page 53. It gave me a time to use
>>for my SBU, but nothing was written to /tools. When I then did the
>>commands separately, in the order they are written in the book, some
>>things were installed in /tools. However, I still get the "no ld
>>directory" error when I try to do 'make -C ld clean'.
Using the "time" function won't change anything, assuming you typed
>>Since I did everything in exactly the order in the book as user lfs, I was
>>still in my binutils-build directory, when I did the 'make -C ld clean.'
>>Thinking that maybe I was in the wrong place, I checked /tools to see if
>>there was an ld dir, but there wasn't.
Since the book never tells you to leave the binutils-build dir (until,
of course, you've completely finished the installation) the "ld" dir is
supposed to be in binutils-build.
>>I have followed the book directions exactly, not customizing anything. I
>>am using LFS 6.1, the stable version. My host system is FC4 default
>>install. I am using packages copied from the latest LFS Live CD, and I
>>confirmed that they are the same versions as the ones in the LFS book I am
>>using, so I don't think packages are the problem. The only thing that
>>might be relevant is the fact that the copied-over files belong to
>>mcooper, not user lfs. Since the perm are 644, I did not think that was
>>part of the problem.
As far as permissions/ownership for the package tarballs, the only thing
that matters is that they are readable by the lfs user (and since you
managed to successfully unpack the binutils tarball you obviously can
read it, so permissions are not an issue in this case).
>>Also, I looked at the errata on the LFS site and checked the FAQs, but I
>>did not see anything that looked like it might be relevant.
>>Unsubscribe: See the above information page
Did you pay attention to the make output and make sure there were no
errors? This kind of problem is likely due to missing some important
package (last time I saw someone with this error it was due to missing
bison and flex on the host system) so that it won't compile any of the
binutils programs. Please paste the contents of config.log.
More information about the lfs-support