On Fri, Apr 18, 2014 at 10:37:48PM +0300, mar...@byteanywhere.com wrote:
> Hi,
>
> I am getting the following error trying to build LFS 5.7
>
For anybody confused by '5.7', that is section 5.7 not the LFS
version ;-) With glibc-2.19 you are either using LFS-7.5 or a
recent version of the development book.
> x86_64-unknown-linux-gnu-gcc -D_RPC_THREAD_SAFE_ -D_GNU_SOURCE
> -DIS_IN_build -include
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/config.h
> rpc_main.c \
When I see a version of crosstool in the directory name, together
with your heading about cross-compiling, I think that I don't know
what you are doing! The LFS book is written for people building in
/mnt/lfs, with a symlink from /tools to /mnt/lfs/tools.
There is no requirement that /mnt/lfs needs to be a separate
filesystem, but you do need to be able to access it as /mnt/lfs -
from time to tiem I do test builds using a directory which I have
bound to /mnt/lfs. Perhaps you are doing the same, but referencing
crosstool implies you may well be doing something very different.
In particular, you probably have not followed section 4.3 - we tell
people to log in as the lfs user. Or perhaps the lfs user does have
write access in /home/marian - some potential to overwrite your own
files.
> -o
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
> -MMD -MP -MF
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o.dt
> -MT
> /home/marian/kits/crosstool-0.43/build/x86_64-unknown-linux-gnu/glibc-build/sunrpc/cross-rpc_main.o
> -c
> rpc_main.c:37:19: fatal error: errno.h: No such file or directory
> #include <errno.h>
> ^
> compilation terminated.
If you are indeed following the book, I think that perhaps you
didn't install the kernel headers. There are _variants_ of errno.h
in those. But I think this is probably a crosstool issue : glibc
itself provides errno.h, so at this point in the process I guess it
comes from the host system. Or alternatively, it should be coming
from the glibc you are building - in that case, either your disk is
full or the extracted source appears to be incomplete.
It would definitely help if you can explain what you are trying to
do.
>
> I configured :
>
> ../glibc-2.19/configure --prefix=/tools --host=$TARGET
> --build=$(../glibc-2.19/scripts/config.guess) --disable-profile
> --enable-kernel=3.7.10 --with-headers=/tools/include
> libc_cv_forced_unwind=yes libc_cv_ctors_header=yes libc_cv_c_cleanup=yes
> --without-selinux
>
> I am running on linux 3.7.10. I am not sure how to get this working.
> I build gcc using:
>
> make all-gcc
> make all-target-libgcc
> make install-gcc
> make install-target-libgcc
Yes, you are doing something different from the book - we are able
to build pass-1 gcc using just make and make install.
>
> because otherwise if i use make, i also get error saying that the
> compiler can not create executables.
>
> Thanks,
> Marian
>
We don't support real cross-compilation, if that is what you are
trying to do. If your host system is x86_64-unknown-linux-gnu then
you should be able to build LFS for x86_64.
But one of the things you need to learn, even if you are not
following the book, is how to debug the "C compiler cannot create
executables" message. It's actually quite easy - in both gcc and
binutils, "configure" is run in several directories. As it runs,
it creates output in "config.log" in that directory, then moves on
to the next directory and does the same thing - until it fails.
So, to debug the gcc build problem (and your solution suggests that
you are really cross-compiling), you need to find the newest
config.log (or log configure's stdout and stderr and work out which
directory it was in by reading the log). Then open up that
config.log in e.g. vim ('view' for safety, I suppose) or else in
'less'. Search for the message:
/C\ compiler\ cannot
('/' to search in vim or less, '\ ' to escape the spaces so that
they are treated as part of the text to search for.)
When you find that error message, look at the lines above it
(probably a few screens worth, say 50 to 100 lines). You should see
a message about what is being tested, a program fragment getting
created, and then it is fed to the compiler to see if it will
compile. Throughout any config.log you will see many error messages,
typically because your system does not support a particular feature,
or does not have a specific file. That is normal, but here you have
a real error.
Sometimes, a missing header might trigger it - that seems unlikely
for this particular error, particularly since you compiled pass 1
binutils just before gcc. Perhaps there was a typo in $LFS_TGT when
you built binutils. Usually, either gcc or ld is objecting to
something in the compile, or occasionally there is a problem with
ld. Either way, you will see the error message in config.log, a few
lines above "C compiler cannot create executables".
In many cases, the problem is fairly obvious when you see the exact
error message - my own favourite was accidentally passing some
ppc-specific option in CFLAGS when I was on i686 or x86_64
(I had broken the architecture test in my script).
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
