On Sun, 08 Dec 2013 13:48:41 +0000
[email protected] (akhiezer) wrote:
> Hmmm. Three slightly-indirect observations (hopefully not too
> off-topic ;) ): --
> * 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*
-rwxr-xr-x 1 root root 968 Feb 8 2011 /usr/lib64/libmpc.la*
-rw-r--r-- 1 root root 204782 Feb 8 2011 /usr/lib64/libmpc.a
-rwxr-xr-x 1 root root 316456 Mar 21 2011 /usr/lib64/libmpfr.so.1.2.2*
-rwxr-xr-x 1 root root 277456 Mar 21 2011 /usr/lib64/libgmp.so.3.4.4*
-rwxr-xr-x 1 root root 366296 Mar 23 2012 /usr/lib64/libmpfr.so.4.1.0*
-rwxr-xr-x 1 root root 945 Mar 23 2012 /usr/lib64/libmpfr.la*
-rw-r--r-- 1 root root 952254 Mar 23 2012 /usr/lib64/libmpfr.a
-rwxr-xr-x 1 root root 15320 May 27
2012 /usr/lib64/libgmpxx.so.4.2.5*
-rwxr-xr-x 1 root root 974 May 27 2012 /usr/lib64/libgmpxx.la*
-rw-r--r-- 1 root root 39084 May 27 2012 /usr/lib64/libgmpxx.a
-rwxr-xr-x 1 root root 442512 May 27 2012 /usr/lib64/libgmp.so.10.0.5*
-rwxr-xr-x 1 root root 910 May 27 2012 /usr/lib64/libgmp.la*
-rw-r--r-- 1 root root 1181218 May 27 2012 /usr/lib64/libgmp.a
lrwxrwxrwx 1 root root 15 Jun 14 19:57 /usr/lib64/libgmp.so.3 ->
libgmp.so.3.4.4*
lrwxrwxrwx 1 root root 16 Jun 14 20:02 /usr/lib64/libmpfr.so.1 ->
libmpfr.so.1.2.2*
lrwxrwxrwx 1 root root 15 Jul 4 16:41 /usr/lib64/libmpc.so.2 ->
libmpc.so.2.0.0* lrwxrwxrwx 1 root root 15 Jul 4
16:41 /usr/lib64/libmpc.so -> libmpc.so.2.0.0*
lrwxrwxrwx 1 root root 16 Jul 4 16:42 /usr/lib64/libmpfr.so.4 ->
libmpfr.so.4.1.0*
lrwxrwxrwx 1 root root 16 Jul 4 16:42 /usr/lib64/libmpfr.so ->
libmpfr.so.4.1.0* lrwxrwxrwx 1 root root 16 Dec 7
14:37 /usr/lib64/libgmp.so.10 -> libgmp.so.10.0.5*
lrwxrwxrwx 1 root root 17 Dec 7 14:37 /usr/lib64/libgmpxx.so ->
libgmpxx.so.4.2.5*
lrwxrwxrwx 1 root root 16 Dec 7 14:37 /usr/lib64/libgmp.so ->
libgmp.so.10.0.5* lrwxrwxrwx 1 root root 17 Dec 7
14:37 /usr/lib64/libgmpxx.so.4 -> libgmpxx.so.4.2.5*
> $ md5sum /usr/lib64/lib{gmp,mpc,mpfr}*
347b12931c9b76ffa9b31b46a4cac672 /usr/lib64/libgmp.a
d4e5b91559c283fa3a012f1ecd16b8f1 /usr/lib64/libgmp.la
a454dfd560eed2455ef30843a5d84137 /usr/lib64/libgmp.so
a454dfd560eed2455ef30843a5d84137 /usr/lib64/libgmp.so.10
a454dfd560eed2455ef30843a5d84137 /usr/lib64/libgmp.so.10.0.5
5461c04b85d79fce42a9ed6699d574f9 /usr/lib64/libgmp.so.3
5461c04b85d79fce42a9ed6699d574f9 /usr/lib64/libgmp.so.3.4.4
204af80681ab2a2e02441a8a079dcb54 /usr/lib64/libgmpxx.a
16e898ca7e2f94e1a421fc1cf793d93f /usr/lib64/libgmpxx.la
aca1f74508a18adc07a8c703c7334ffe /usr/lib64/libgmpxx.so
aca1f74508a18adc07a8c703c7334ffe /usr/lib64/libgmpxx.so.4
aca1f74508a18adc07a8c703c7334ffe /usr/lib64/libgmpxx.so.4.2.5
a742a55a35e5240e7d2f4c17145c55da /usr/lib64/libmpc.a
c0ee38b7d4d9bebdf17412f42563503b /usr/lib64/libmpc.la
f90954055b6767101e2afb5a6024b88d /usr/lib64/libmpc.so
f90954055b6767101e2afb5a6024b88d /usr/lib64/libmpc.so.2
f90954055b6767101e2afb5a6024b88d /usr/lib64/libmpc.so.2.0.0
cf22aca60c6962195e37895f2e7ab461 /usr/lib64/libmpfr.a
7da0b0d3d66604280a4d6f72535faaad /usr/lib64/libmpfr.la
47382b481e1838836cfed7ccfd64f4ac /usr/lib64/libmpfr.so
eabf6e0b4fc484d7a637da77fdc4be3e /usr/lib64/libmpfr.so.1
eabf6e0b4fc484d7a637da77fdc4be3e /usr/lib64/libmpfr.so.1.2.2
47382b481e1838836cfed7ccfd64f4ac /usr/lib64/libmpfr.so.4
47382b481e1838836cfed7ccfd64f4ac /usr/lib64/libmpfr.so.4.1.0
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.
> * did you try a build with the (somewhere-)suggested fallback of
> 'make -j 1 ...' ?
I have now. It doesn't make any difference.
> * 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?
> p.s. Re the wider picture here: when putting together the kind of
> host-os system that you describe, it can be useful to use the
> dependencies info from lfs/blfs (with a judicious number of grains of
> salt), plus an (again, judicious) admixture of the command-lists on
> the lfs/blfs pages and in the 'SlackBuild' files (e.g.
> 'http://ftp.gwdg.de/pub/linux/slackware/slackware-14.1/source/ap/ghostscript/'
> ). Not assuming you've not already done or considered similar; just
> mention it in case not and in case of use.
>
>
>
>
> --
--
If any members of GCHQ are reading this, shame on you! I fought for
your right to belong to a trade union and now you are taking away my
right to privacy?
H Russman
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
