make: gcc: Command not found

spiky0011 · 06-06-2012, 04:13 PM

The only 2 things as you know are the gcc version and glibc, These could well be the problem. So if you do decide to rebuild try using the svn version of lfs.

anakletor · 06-06-2012, 04:16 PM

Ok, I might consider rebuilding with svn version next time. Thanks for your help!

crow43 · 08-13-2012, 11:30 AM

Hi

I'm having the same problem. Please post a solution, or whatever you found to work, if you find it.

Best regards,
Crow

spiky0011 · 08-13-2012, 11:41 AM

Hi Crow

Can you post what problems you are having.

Also what host are you using, which book you are following, and the output of version-check

crow43 · 08-14-2012, 05:29 AM

Certainly,

My problem is the same as anakletor described at the beginning of the thread; gcc is not working after I've chroot'ed to the LFS partition:
----------------------------------------------------------------
root:/# gcc
bash: /tools/bin/gcc: No such file or directory
----------------------------------------------------------------

As anakletor has described '$LFS/tools/bin/gcc' works fine when rooted in the host file system's root directory (before chroot'ing to $LFS that is).

I am building LFS 7.0 on an AMD Phenom II (quad core x86_64) machine and this is my second attempt. First attempt halted at the same problem and then I found the thread

http://www.linuxfromscratch.org/pipe...er/021058.html

This thread hinted me that I might have forgotten to clean up after installing the first pass of binutils. So I erased '$LFS/tools' and started over att chapter 4 taking great care to remove all extracted files and build output after having installed each package. But, as you can see, the problem remains so the cause must be something else.

I have now noticed that ldd reports some dependencies of '$LFS/tools/bin/gcc' that look suspicious to me:

----------------------------------------------------------------
$ ldd /mnt/lfs/tools/bin/gcc
linux-vdso.so.1 => (0x00007fff655ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9959dc6000)
/lib64/ld-linux-x86-64.so.2 (0x00007f995a187000)
----------------------------------------------------------------

gcc should be linked to /tools/lib(64) and not /lib if I'm not mistaken and the shared object linux-vdso.so.1 does not exist in my LFS partition. This leads me to beleive that something went wrong when replacing /lib(64) with /tools/lib(64) in gcc's header files and/or when configuring gcc (5.10. GCC-4.6.1 - Pass 2). I think I verified the /tools/lib substitution when I performed it but it is quite possible that I've overlooked or misunderstood something.

So, I guess it's back to chapter 5 for me.

If you have any thoughts or comments please let me know, and any input on how to verify that gcc's configuration and the /tools/lib references are correct before building gcc is most welcome.

Also, can anyone with a working installation run 'ldd $LFS/tools/bin/gcc' and present the output?

Thank you for reading. Best regards,
Crow

PS. I'll upgrade to the latest version before continuing DS.

Keith Hedger · 08-14-2012, 10:23 AM

Looks like you may have 32/64 bit problem lfs uses /lib /usr/lib for installed library's regardless of whether you are building 64 or 32 bit clfs sorts this problem ( sort of, it puts 64bit libs in /lib64 /usr/lib64 ), try

Code:

file /tools/bin/gcc

and see if you have a 32 or 64 bit gcc.

This "No such file or directory" error is the same for a non-existent file and the wrong elf type (32bit instead of 64bit), which isn't helpful!

crow43 · 08-14-2012, 04:05 PM

Hi Keith, thank you for you reply

gcc appears to be a 64-bit executable:

Code:

$ file /mnt/lfs/tools/bin/gcc
/mnt/lfs/tools/bin/gcc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.15, not stripped

I don't think that the instruction set is the problem. Isn't it obvious that '/mnt/lfs/tools/bin/gcc' should have been linked to /tools/lib and not /lib?

BR
Crow

Keith Hedger · 08-15-2012, 04:30 AM

Stupid question I know but are you running a 64bit kernel on the host system ( you didn't say ) as processor type is not really relevant, you can run 32bit code on a 64bit kernel ( if you have a 64bit machine and 32bit infrastructure ) but not the other way around.

It definitely seems like the file is there and executable ( from your posted ls ) but can't be run for some reason, have you mounted the drive with the noexec flag set? It's very odd!

Keith Hedger · 08-15-2012, 04:44 AM

Just unpacked my tar'd up copy of tools and tried running gcc and got the exact same error "No such file or directory" so I put back the symlinks to the host system like so

Code:

sudo ln -sv /media/SkyNet/lfs/tools /tools
sudo ln -sv /media/SkyNet/lfs/cross-tools/ /cross-tools

and hey presto it works! so try this out ( you may not have the cross-tools folder I am using clfs not lfs )
Obviously change the path from /media/SkyNet/lfs/ to where ever your lfs system is mounted.

crow43 · 08-16-2012, 09:45 AM

'noexec' flag is not set, if it had been I don't believe that gcc or anything else in my LFS partition would have executed.

The symlinks you suggested are for the host filesystem, making '/tools' link to '/media/SkyNet/lfs/tools', and I have the corresponding symlink on my system:

Code:

$ ls -l / | grep tools
lrwxrwxrwx   1 root root    14 2012-02-15 14:37 tools -> /mnt/lfs/tools

Besides, once i chroot into /mnt/lfs then that link is no longer relevant, right?

What output do you get when you run

Code:

$ ldd /media/SkyNet/lfs/tools/bin/gcc

on your machine?

BR
Crow

Keith Hedger · 08-16-2012, 10:21 AM

From the host:

Code:

ldd /media/SkyNet/lfs/tools/bin/gcc
	linux-vdso.so.1 =>  (0x00007fffa4fff000)
	libc.so.6 => /tools/lib/libc.so.6 (0x00007ffa65d16000)
	/tools/lib/ld-linux-x86-64.so.2 (0x00007ffa6609d000)

you are right about the link - I must be brain dead at the moment.
Hmmm it seems your tools/bin/gcc is not linked to the same place as mine, mine is linked to /tools/lib* yours is /lib*, thats gotta be the problem.

crow43 · 08-17-2012, 07:15 AM

Indeed! Thanks for the input. Now I have to figure out why mine got linked to /lib.

I'll try the LFS support mail list next. I think that I will also try rebuilding gcc pass 2. I imagine that a good sanity check afterwards would be to run

Code:

$ ldd /tools/bin/gcc

from the host filesystem and verify that LFS' gcc is linked to /tools/lib and not /lib.

I'll come back when/if I find something interesting.

BR
Crow

crow43 · 01-26-2013, 12:41 PM

'SOLVED'
I have it figured out now: My mistake was to set the 'CC', 'AR' and 'RANLIB' variables separately before running 'configure', as opposed to setting them on the same line as calling 'configure'. I had no idea that the implications are different. As a result gcc was misconfigured for me. I guess that it might work to set them separately if you use 'export', but that's just a guess at the moment. Be safe and do what book says

(obviously).

There are two sanity checks that one can run in order to ensure that gcc is correctly linked after pass 2: When logged on as user "lfs" issue

Code:

$ readelf -l /tools/bin/gcc | grep interpreter

or

Code:

$ ldd /tools/bin/gcc

and ensure that the output says something like "/tools/lib*" and not just "/lib*".

/ Crow

aashil16 · 10-30-2014, 12:45 AM

I did the same mistake as crow43 which he mentioned in the last post. Do I have to start over again ? Instead I tried compiling gcc again and make things work. I succeeded in GCC Pass-1 but in Pass-2 I get an error "gcc: command not found" Is there a solution to this ? I don't wan't to start over again. @spiky0011

astrogeek · 10-30-2014, 12:51 AM

Quote:

Originally Posted by aashil16

I did the same mistake as crow43 which he mentioned in the last post. Do I have to start over again ? Instead I tried compiling gcc again and make things work. I succeeded in GCC Pass-1 but in Pass-2 I get an error "gcc: command not found" Is there a solution to this ? I don't wan't to start over again. @spiky0011

You have re-opened a thread begun in June 2012. It would be much easier to get help if you start your own thread.

Also, it is not very helpful to say "I did the same mistake as he did in the last post...", that does not provide any useful information for someone to be able to understand your problem.

Please start a new thread, provide as much useful information as you can, including what software you are compiling, what version and on what verison of Linux, as well as the error messages that you are getting.