Need help with SPECFILE=` gcc -- print-file specs`
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.
Well I guess I have a problem then because I have nothing after I reboot except an empty lfs directory. Maybe the cd is somehow overwriting it when it boots up ?
The cd does not overwrite anything (on possibly present hd's).
- What does df -h show after you boot from cd?
- And what does df -h show after you mounted the LFS partition you want to work on?
Quote:
I tried to delete the lfs directory but it shows up as soon as I reboot.
Which lfs directory are you talking about? If you cannot delete it it is probably on the cd and it cannot be deleted (ok, you could nuke the cd )
Quote:
So you are saying that I should have everything there whatever I put in there the /tools /sources and any untarred files ?
Yes, everything in $LFS should still be there after a reboot (and setting up some things, see the hint file for that).
again, I ask. Did you remount the partiton TO /mnt/lfs? The CD will not do that for you automatically. The 'empty dir' might just be that you never mounted the partition again and are only seeing the mount point. Run "mount /dev/<xxx> /mnt/lfs" (where <xxx> is your partition, eg. hda1). I'm pretty sure its just a careless mistake.
Hello,
We already went thru this once when I had the Out of memory problem
df-h and df -H is almost the same except the numbers are a little bit different
but here it is again
After I boot from the cd I get
After I mount the floppy and the LFS partition I get the same as abpve plus
what I have below
/dev/fd0 1.5M 30k 1.4M 3% /mnt/floppy
/dev/hda7 6.3g 29k 5.9g 1% /mnt/lfs
The lfs directory I am refering to is in /mnt
What I meant to say was that it can be deleted but as soon as I reboot it shows up in /mnt but when I check the rest of the directories in lfs there is nothing there
I did a ls -l in the /mnt directory and it shows that it was created today
sep 27 so it loads up with the cd but it's not part of the cd
Some sort of ram hard drive I am guessing
If you remove a directory (/mnt/lfs in this case) it should not automatically appear after a reboot. It could be that your version of the cd creates this at boot-up, but I haven't seen this behavior on the different LFS LifeCD versions I used.
But this is not a show stopper.......
You are not creating LFS in /mnt/lfs, but on the partition mounted on that point (lfs = /dev/hda7 in your case.).
The /mnt/lfs directory should be empty after you booted the cd. It should be (partially) filled after mounting /dev/hda7 on /mnt/lfs.
These are the first basic steps, roughly tailored to your situation:
- create a partition
You seem to have a /dev/hda7, this is done.
- create filesystem
mke2fs /dev/hda7
- create/activate swap
mkswap /dev/[yyy]
swapon -a
- mount partition:
export LFS=/mnt/lfs
mkdir -p $LFS
mount /dev/hda7 $LFS
If you reboot at this point and mount /dev/hda7 again (mount /dev/hda7 /mnt/lfs), the /mnt/lfs/tools directory and filled /mnt/lfs/sources directory should still be there.
If this is not the case: Please post all commands (with options and output) of the commands you issued to get up to and including chapter 4.2 (Creating the $LFS/tools Directory).
There's no point in continuing if your /mnt/lfs directory is empty after every boot and mounting of /dev/hda7. Even if you would decide to continue working until it is finished, chapter 9.3 (ends with a reboot) will give you a very nasty surprise............. It's obvious that this issue needs to be resolved first.
Thanks for the explanation
"You are not creating LFS in /mnt/lfs, but on the partition mounted on that point (lfs = /dev/hda7 in your case.).
The /mnt/lfs directory should be empty after you booted the cd. It should be (partially) filled after mounting /dev/hda7 on /mnt/lfs."
That was a big help
It would have been nice if it was mentioned in the book
Now I understand how it works .
I didn't know that all I had to do is to mount it after I reboot
I was starting from the begining all the time
So now I can move forward and see if gcc is placed where it should be
I will give it another run this weekend and see what happens
Hello,
Well I tried it again but I am still stuck at the SPECFILE
now the error is
bash: =/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/specs: No such file or directory
I am not sure what the .. is supposed to be in the error line
The which gcc now gives me /tools/bin/gcc and the gcc --print-file specs
gives me /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/specs
The echo $SPECFILE is still a blank line
Would it be easier if I just edit it manually now that it's not a read only file ?
I looked at the specs file and I only saw one place where I have to make the change
bash: =/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/specs: No such file or directory
I am not sure what the .. is supposed to be in the error line
If gcc --print-file specs comes back with the first (with the /../) then something probably went wrong during the gcc install (chap 5.5. GCC-3.4.1 - Pass 1). Although it is strange, I don't believe this is a show-stopper (I'm not sure about this!!).
What's more of a concern is the empty SPECFILE variable. Did you copy-paste the commands as suggested in the book? Most of the time the wrong quotes (back tics, actually) are used when typing it in manually.
Quote:
Would it be easier if I just edit it manually now that it's not a read only file ?
I looked at the specs file and I only saw one place where I have to make the change
Like it is stated in the book: It is recommended that the above command be copy-and-pasted in order to ensure accuracy. Alternatively, the specs file can be edited by hand. This is done by replacing every occurrence of “/lib/ld-linux.so.2” with “/tools/lib/ld-linux.so.2”
Be sure to visually inspect the specs file in order to verify the intended changes have been made.
You will find out soon enough if things are ok (the sanity check later on in chapter 5.9)
Hello,
I tried the sanity check but I have a problem with that one now
I am not sure if it's related to the (/../) in the specfile
After the cc dummy.c I got a warning something about ld-linux I believe
I am not sure because I did not write it down but now that I try it for the second time I get a different error I get a long path name with more /../ in it
and then at the end it says no input files
I may have to go back and redo gcc 3.4.1 and see if maybe I missed something
since I did not used the floppy and I typed it in
What is the best way to do that ?
Or would it be better to start from the begining ?
I am not sure how easy it would be to copy and paste the specfile commands
from the command line since I am not using X
I would have to use lynx to view the html file and then somehow copy and paste
to the command line.
Sounds too complicated for me
It's easier just to type it in and even easier just to edit the file if it's just one place
Someone already figured it out that using the wrong quotes will give "ambiguous redirect" error so that is not the problem
I think the problem is with the /../ I am not sure if it can determine
which directory that is so it puts out an error
Somehow I think I have to make that /../ go away
lllfjff
Hello,
I ran it again from scratch but I still have the same problem
In the specfile I still have
bash: =/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/specs: No such file or directory
In the sanity check after the cc dummy.c I get
/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-
pc-linux-gnu/bin/ld: no input files
collect2: ld returned 1 exit status
Is it possible to go forward if I made sure to modify the specs file ?
No you cannot continue if the sanity check doesn't give the appropriate result. As I said before, this is an important step and you need to fix this first before you can continue.
From the above I cannot figure out what it is that you did wrong, it could be a typo somewhere or a mis interpretation from what the book is telling you to do (or not to do). In general you don't have to deviate from what the book is telling you to do.
Looking at the path you mention (/mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/) I still believe that gcc wasn't installed correctly.
Did you follow the advice in the caution part at the bottom of chap 5.9 about what to do if the sanity check fails (check gcc vs cc, path setting etc)?
Hello,
Yes I checked with gcc with the same results and tha PATH has the /tools/bin first
I have seen that line /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/
mentioned somewhere in this forum and someone said it's correct but I am not sure.
I mean if you say that is the same as /mnt/lfs/tools/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
why doesn't it just say that ? Why the /../
What is /../ supposed to represent ?
The other question I have is what are the input files and where are they supposed to be located ? Does it have anything to do with ld ?
I tried to go further just to see what happens but I did not get very far
When I tried to run tcl I got an error something about c compiler is unable to make executable files.
I am not sure if that is related to the previous error or is this a new problem I will have even if I fix the previous ptoblems
Yes I checked with gcc with the same results and tha PATH has the /tools/bin first
I have seen that line /mnt/lfs/tools/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/
mentioned somewhere in this forum and someone said it's correct but I am not sure.
Again: It looks like it's incorrect and related to gcc.
Quote:
I mean if you say that is the same as /mnt/lfs/tools/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
why doesn't it just say that ? Why the /../
What is /../ supposed to represent ?
The other question I have is what are the input files and where are they supposed to be located ? Does it have anything to do with ld ?
This isn't of any concern (besides, which inputfile(s) are you talking about). Editing/'hacking' files isn't needed to install LFS, unless stated by the LFS team.
Quote:
I tried to go further just to see what happens but I did not get very far
When I tried to run tcl I got an error something about c compiler is unable to make executable files.
I told you that continuing wouldn't work unless you fix the problem at hand, now you have prove
Quote:
I am not sure if that is related to the previous error or is this a new problem I will have even if I fix the previous ptoblems
This is a result of the same error: A none working gcc (that's what it looks like.).
We seem to be going in circles although I still have a feeling that you did not follow the book or misunderstood one of the steps. Without knowing all that you previously did (or didn't) do and if any of those steps deviate from the book or showed errors it's becoming hard to help you with this issue.
Hello,
Obviusly something is wrong somewhere I am just trying to get some clues as to where and what to look for and what to do differently in order to make it work.
It's no use doing it over and over the same way hoping that I stumble on the
answer
If I get a sense of where the problem may be I can concentrate in that area only
For example now I know when gcc get's placed into /tools/bin so I don't need to run it all the way till the specfile. I can check for it much earlier
If it's not there it's no use building the rest of it.
I am going to work on /../ first to see where and when is that starts to happen than perhaps I may get an idea on how to fix it
" This isn't of any concern (besides, which inputfile(s) are you talking about). Editing/'hacking' files isn't needed to install LFS, unless stated by the LFS team."
I was talking about the sanity check after the cc dummy.c at the end of the error line I get "no Input files" I don't know what that means either that's why I was asking in case someone knows what that means
I am not planing on editing/hacking I am just trying to get a clue as to where the problem may be.
I am hoping that if I can fix the /../ maybe the other problem may go away
since without /../ maybe it can find the input files
Removing /../ is futile, the gcc driver uses relative paths to find all its components.
Firstly some things to check
1: Does the specs file exist?
For gcc 4.x it wont, create one by using gcc -dumpspecs > /path/to/specs
2: If it exists check that the values in it are correct specifically for the dynamic linker ld-linux.so.2 (for chapter 5 it should point to /tools/lib/ld-linux.so.2).
This gets hardcoded into all executables created by the toolchain, and is the purpose of the dummy check. Basically you are forcing all executables being created to use dynamic linker from the new glibc in /tools, and hence link in the new glibc libraries at runtime.
Also you will need to check the settings of the startfile_prefix_spec.
Chapter 5 this should be pointed at /tools/lib/
ie
startfile_prefix_spec:
/tools/lib/
This is so the new glibc's startfiles (crt[1in].o) are used compile time when linking.
Chapter 6 adjustment is the opposite ( ie: remove /tools/lib/ from the startfile_prefix_spec (DO NOT DELETE THE LINE, just the text), repoint the dynamic linker to /lib/ld-linux.so.2 ).
Double check the values and edit as required... issues as described I've only heard about when folks have performed the adjustment sed too many times, or failed to apply the specs patch.
If you are still having problems, send the output of
gcc -v -Wl,-verbose -o dummy dummy.c 2>&1 | tee dummy-output
Hello,
Thanks for trying to help me out
Do you know for a fact if the path with the /../ is correct ?
I don't necessarily want to remove it I just want to make sure that
the /../ is not the cause of the error
Is there a test or command that I can run to check weather in fact gcc can read anything with a /../
1 The specfile does exist because I was able to edit it manually since
the SPECFILE instruction did not work
As I mentioned I was not able to run the sanity check either without an
error
I believe you have a different version then mine
I have version 6.0
I don't see any mention of /tool/lib in the chapter 5 that is in version 6.0
I have not reached chapter 6 yet but I think I should still be able tu run
gcc -v -Wl,-verbose -o dummy dummy.c 2>&1 | tee dummy-output
Is there anything in particular I should be looking for ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.