> Date: Tue, 22 Oct 2013 12:23:54 +0100
> From: Hazel Russman <[email protected]>
> To: lfs support <[email protected]>
> Subject: [lfs-support] GCC build first pass: mpc build looks for libgmp.la
> in the wrong place
>
> I am trying to build a 64-bit lfs-7.4 system using a host system based
> on Slackware-14. Currently I am having a problem with the first pass of
> building gcc. During the internal build of libmpc, a search is made for
> /usr/lib64/libgmp.la. It is not found, so the build crashes.
>
Have read through the thread thus far. Don't know if you're still wanting to
get to the bottom of this (no probs if not), but if so here goes.
Sanity-checks:
---
* your host-os (Slackware 14.0) is 64-bit (what does 'uname -a' show)?
* _prior_ to your creation of the symlink that you note below, did
'/usr/lib64/libgmp.la' exist in the host-os? (I know that the sed below
says/implies that it doesn't/didn't exist; but that of course is not
nec foolproof evidence: better if you can cross-check via e.g. manually
checking the host-os filesys.)
* you mention in a later post, that it is a customised version of the host-os.
At the time of getting the compile-fail below, did you have any of mpfr, mpc,
gmp installed in the host-os? What do you get from:
$ ls -latrF /var/log/{packages,{removed_,}scripts}/{gmp,libmpc,mpfr}*
* did you ever have any of mpfr, mpc, gmp installed in the host-os, and then
uninstalled/moved/changed them at all; if so, by what methods?
* At the time of the build below, what was LD_LIBRARY_PATH ?
---
Part of the reason for asking some of the above, is that in a normal 64-bit
recent-ish Slackware full-install, you would have '/usr/lib64/libgmp.la'
present
and all-OK.
> libtool: link: ar rc .libs/libmpc.a abs.o acos.o acosh.oo add_ui.o
> arg.o asin.o asinh.o atan.o atanh.o clear.o cmcos.o cosh.o div_2si.o
> div_2ui.o div.o div_fr.o div_ui.o _sub.o get_prec2.o get_prec.o
> get_version.o get_x.o imag.tr.o log.o log10.o mem.o mul_2si.o mul_2ui.o
> mul.o mul_fr_ui.o neg.o norm.o out_str.o pow.o pow_fr.o pow_ld.o
> pow_ow_z.o proj.o real.o urandom.o set.o set_prec.o set_str.oo sin_cos.o
> sinh.o sqr.o sqrt.o strtoc.o sub.o sub_fr.o snh.o uceil_log2.o ui_div.o
> ui_ui_sub.o
> libtool: link: ranlib .libs/libmpc.a
> /bin/sed: can't read /usr/lib64/libgmp.la: No such file or directory
> libtool: link: `/usr/lib64/libgmp.la' is not a valid libtool archive
> make[4]: *** [libmpc.la] Error 1
> make[4]: Leaving directory `/mnt/lfs/sources/gcc-build/mpc/src
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/mnt/lfs/sources/gcc-build/mpc
> make[2]: *** [all] Error 2
> make[2]: Leaving directory `/mnt/lfs/sources/gcc-build/mpc
> make[1]: *** [all-mpc] Error 2
> make[1]: Leaving directory `/mnt/lfs/sources/gcc-build'
> make: *** [all] Error 2
>
> I have tried two experimental builds. In the first, I used two
> additional configuration parameters in the hope that they would tell the
> compiler the correct place to look for information on gmp:
> --with_gmp_include=$(pwd)/gmp and --with_gmp_lib=$(pwd)/gmp/.libs. But
> this did not have any effect on the error.
Just to check: did you use underscores there - i.e. in the above
--with_gmp_include=$(pwd)/gmp and --with_gmp_lib=$(pwd)/gmp/.libs
; or did you use hyphens/dashes thus:
--with-gmp-include=$(pwd)/gmp --with-gmp-lib=$(pwd)/gmp/.libs
?
lfs-6.7 and lfs-6.8 both use './configure ...' options:
--with-gmp-include=$(pwd)/gmp --with-gmp-lib=$(pwd)/gmp/.libs
; and they don't use any mpfr/mpc stuff.
And lfs-7.0 thru lfs-7.4 uses (I've replaced the gcc version numbers with the
literal string '${GCC_VERNUM}'):
--with-mpfr-include=$(pwd)/../gcc-${GCC_VERNUM}/mpfr/src \
--with-mpfr-lib=$(pwd)/mpfr/src/.libs
; and they don't use any gmp/mpc stuff.
Had a brief look at trac to see why the switchover at 6.8 -> 7.0 , and why
wanting/needing to specify those options to './configure ...' explicitly; but
nothing obvious in the time spent.
>
> For the second try, I simply put a symbolic link into /usr/lib64
> pointing to /mnt/lfs/sources/gcc-build/gmp/.libs/libgmp.la. Then the
> build was successful.
>
> I have not installed this build because it was not done "by the book"
> and I am afraid of polluting my tool chain. Can someone please tell me:
> 1) If it is safe to install it?
> 2) Why the error occurred, given that the configuration options and
> global edits set out in the book should prevent this kind of
> back-reference to the host system?
Not sure. May be able to try to reproduce the error tomorrow, in a 7.4 build
using 14.1 as host-os.
> 3) What would be the proper way to correct an error like this? My way
> feels rather kludgy.
>
>
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
