On Sun, Oct 25, 2015 at 07:01:26PM -0400, Michael Havens wrote:
> I followed the instruction yet the compile still will not complete.
>
> compile log: http://pastebin.com/Bsri0v4n
>
> I looked through the compile log and the only errors I could find not
> associated with code was:
>
> checking for suffix of object files... configure: error: in
> `/mnt/lfs/sources/gcc-build/x86_64-lfs-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[1]: *** [configure-target-libgcc] Error 1
> make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
> make: *** [all] Error 2
>
> which led me to look into the configure log.
>
> config log: http://pastebin.com/s8C5Gv5f
>
Welcome to gcc ;-) This is one of the (few) packages which runs
'configure' in multiple directories *from make* (binutils and gcc
are similar, if my memory is correct).
What you have to do is work out in which directory configure was last
run, i.e. identify the *newest* config.log file and then search for
'cannot compute suffix of object files'. Use less or vim to search,
e.g.
/cannot\ compute\ suffix
will probably take you to the right part of the file, then look back
at the lines before that - you should see that a code fragment was
created, probably with a message related to testing the suffix of
object files, and then you should see what happened when configure
tried to run that fragment. i.e. A "real" descriptive error.
And then after that the "translation" to the 'cannot compile'
message.
I had that message once, years ago, when I passed invalid CFLAGS (my
script failed to correctly detect it was not running on a ppc64, and
used a machine-specific optimization). Your error will be different,
and at this point I will guess that pass-1 binutils was not
correctly installed, i.e. lfs version of one of the programs was not
found. Alternatively, your gcc script might have lost the variable.
But all should be clear when you read the actual error message.
> This reveals many errors not associated with code:
>
> configure:6002: gcc -o conftest -g -O2 -I$$r/$(HOST_SUBDIR)/gmp -I$$s/gmp
> -I$$r/$(HOST_SUBDIR)/mpfr/src -I$$s/mpfr/src -I$$s/mpc/src -lisl
> conftest.c -lisl >&5
> conftest.c:10:21: fatal error: isl/val.h: No such file or directory
> compilation terminated.
> configure:6002: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define LT_OBJDIR ".libs/"
> | /* end confdefs.h. */
> | #include <isl/val.h>
> | int
> | main ()
> | {
> | ;
> | ;
> | return 0;
> | }
That hunk, perhaps with some lines before it to specify what it is
testing for, is normal. Configure scripts are ideally
system-agnostic - the build might not even be on linux. In
addition, many configure scripts use a lot of gnu boilerplate, e.g.
things like checking for Fortran. So, many configure tests are
expected to fail, and to produce 'error' reports in config.log.
Oh, and your previous use of dash is normally expected to break the
glibc build, so yes, you needed to fix it, but it wasn't likely to
be the cause of this build failure.
Take it slowly, at this point the main things you need to do are to
learn (the cp / tar business), and then to remember what you learn.
Eventually, you will be able to diagnose most of your own build
problems, but it needs practise.
ĸen
--
Il Porcupino Nil Sodomy Est! (if you will excuse my latatian)
aka "The hedgehog song"
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
