> Date: Sun, 8 Dec 2013 21:29:05 +0000
> From: Hazel Russman <[email protected]>
> To: [email protected]
> Subject: Re: [lfs-support] GCC build first pass: mpc build looks for
> libgmp.la in the wrong place
>
- apols for the delay in resuming.
> > * can you post the output, please, of each of:
> > $ ls -latrF /usr/lib64/lib{gmp,mpc,mpfr}*
> -rwxr-xr-x 1 root root 77656 Feb 8 2011 /usr/lib64/libmpc.so.2.0.0*
.
.
> 14:37 /usr/lib64/libgmpxx.so.4 -> libgmpxx.so.4.2.5*
>
> > $ md5sum /usr/lib64/lib{gmp,mpc,mpfr}*
> 347b12931c9b76ffa9b31b46a4cac672 /usr/lib64/libgmp.a
.
.
> 47382b481e1838836cfed7ccfd64f4ac /usr/lib64/libmpfr.so.4.1.0
>
Those all look sane; and can see the elflibs stuff in there too.
((
Should also have double-checked the following related info. Does your host-os
look the same as these - no need to post if yes to all:
$ ls -latrF /usr/lib64/libmp.*
-rwxr-xr-x 1 root root 275184 May 27 2012 /usr/lib64/libmp.so.3.1.25*
-rwxr-xr-x 1 root root 901 May 27 2012 /usr/lib64/libmp.la*
-rw-r--r-- 1 root root 618446 May 27 2012 /usr/lib64/libmp.a
lrwxrwxrwx 1 root root 15 Dec 9 17:58 /usr/lib64/libmp.so.3 ->
libmp.so.3.1.25*
lrwxrwxrwx 1 root root 15 Dec 9 17:58 /usr/lib64/libmp.so ->
libmp.so.3.1.25*
$ ls -latrF /usr/include/{mpc,mpfr,mpf2mpfr,mp,gmpxx,gmp}.h
-rw-r--r-- 1 root root 13049 Feb 8 2011 /usr/include/mpc.h
-rw-r--r-- 1 root root 50838 Mar 23 2012 /usr/include/mpfr.h
-rw-r--r-- 1 root root 6290 Mar 23 2012 /usr/include/mpf2mpfr.h
-rw-r--r-- 1 root root 5413 May 27 2012 /usr/include/mp.h
-rw-r--r-- 1 root root 114646 May 27 2012 /usr/include/gmpxx.h
-rw-r--r-- 1 root root 86111 May 27 2012 /usr/include/gmp.h
$ md5sum /usr/lib64/libmp.* /usr/include/{mpc,mpfr,mpf2mpfr,mp,gmpxx,gmp}.h
7fac348869436cc35ed9ddf25a2b1e3c /usr/lib64/libmp.a
3c2bbb2d48ca14717d313fb8d62f54d3 /usr/lib64/libmp.la
095038ab03440e514ef9564b7cede7ad /usr/lib64/libmp.so
095038ab03440e514ef9564b7cede7ad /usr/lib64/libmp.so.3
095038ab03440e514ef9564b7cede7ad /usr/lib64/libmp.so.3.1.25
84e1d1d15421a250f9100b3c76875766 /usr/include/mpc.h
b309b3d8d801a057dd15cabb96b4d4bc /usr/include/mpfr.h
1c600ac5038c3e43fa8ef3dc1f63b5ec /usr/include/mpf2mpfr.h
e8938b5b91f54ea66fb485ea0c418c11 /usr/include/mp.h
6b0181c9464c1ab403ff0c15645f2265 /usr/include/gmpxx.h
9fc1beb1af1545348605f0094206c86d /usr/include/gmp.h
$
))
> These are the "current" ones, i.e. after proper installation of gmp on
> the host system. But I think we've already established that that
> doesn't affect the bad dependency paths.
>
Not quite 100% sure that it's been established. Just wanted to
double-check that nothing on host-os is different - e.g. bad-install or
changed via lfs-build leakage into host-os - from what would be expected.
>
.
.
> > * when building from a really customised host-os, one needs to be
> > prepared to 'get forensic' if necessary: else it's best to build from
> > a (small-c) conservative base. You might, if not already, want to at
> > least skim-read the main docs in the gcc/mpc/mpfr/gmp source-trees,
> > not least to see if anything 'jumps out' at you wrt how you've got
> > your host-os setup.
> I shall try to do that over the next few days but I wonder how much of
> it I will actually understand. Perhaps I ought to start by reading up
> on libtool to find how it actually makes the .la files and where
> the info in them comes from.
>
> > You might also want to use the likes of strace to
> > see if/where/how the host-os /usr/lib64 stuff is being accessed.
> > --
>
> You mean run strace on the make? Or the configure?
>
I'd do both. Use '-o ...' flag to log to file; and '-f' flag; and leave all
others at defaults, at least initially - can refine/adj later if nec to use
the likes of -v/-x[x]/-t[t[t]]/-r/-ff/-e trace=file/-s strsize/-c/&c.
Also would suggest redirecting all output from configure and from make, to
logfiles: fwiw I usually have nothing outputting to screen, and just
'tail -f logfiles' or similar.
Beyond a certain point, if it's really looking like a pathological case (some
might say it is already), then it may be worth looking/asking at
gcc/mpfr/gmp/mpc mailing lists, as they'll have a much more ready-made
knowledge of the various pathways through the code that can be hit. (Also as
noted earlier, it's not at all uncommon for folks to hit problems similar to
what you're seeing.)
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
