> Date: Wed, 11 Dec 2013 12:12:49 +0000
> From: Hazel Russman <hazeldeb...@googlemail.com>
> To: lfs-support@linuxfromscratch.org
> Subject: Re: [lfs-support] GCC build first pass: mpc build looks for
> libgmp.la in the wrong place
>
> On Mon, 09 Dec 2013 19:13:08 +0000
> lf...@cruziero.com (akhiezer) wrote:
>
.
.
>
> I have managed to read up on the INSTALL files and the info pages for
> the three libraries, but the only thing I found that seems at all
> relevant is that the "--with foo=" options are not intended to be used
> for libraries included in the gcc source tree but only for libraries
> that are pre-installed in unorthodox places (i.e. not in /usr/lib
> or /usr/local/lib).
Yes, that's ~always been my understanding.
>
> I assume that lfs uses "--with-mpfr-lib" and "--with-mpfr-include" to
> head off some problem that has been found to occur otherwise and I
> wonder if it is in any similar to my problem.
>
Per earlier post, lfs-6.{7,8} used '--with-gmp-{include,lib}' (and no 'mpfr'
or 'mpc' analogous flags), while lfs-7.{0 thru 4} have dropped the
'--with-gmp-...' and instead used '--with-mpfr-{include,lib}' (and no 'gmp'
or 'mpc' analogous flags) . Have not followed-up on initial quick check to
see why that switch happened.
There certainly has been posts from lfs folks to/on gcc/mpfr/&c mailing-lists
concerning these '--with-...' flags and build-fails.
> >
.
.
> I now have strace logs for both the configure and the build. They are
> big files; the one from the build is nearly one GB! I have been able to
> examine the smaller "configure" one and I can't see anything in it that
> looks sinister. There are regular triplets of open calls
> to /usr/lib64/{libmpc,mpfr,gmp} but they always follow calls to the
> host gcc, which is linked to those libraries. There are no accesses to
> any .la files.
>
> In the build strace log, however, grep found lines like these:
>
> 15899 stat("/usr/lib64/libmpfr.la", {st_mode=S_IFREG|0755,
> st_size=945, ...}) = 0 15899 stat("/usr/lib64/libmpfr.la",
> {st_mode=S_IFREG|0755, st_size=945, ...}) = 0 15899 faccessat(AT_FDCWD,
> "/usr/lib64/libmpfr.la", R_OK) = 0 15899 open("/usr/lib64/libmpfr.la",
> O_RDONLY) = 3 15899 read(0, "# libmpfr.la - a libtool library"..., 128)
> = 128 15899 open("/usr/lib64/libmpfr.la", O_RDONLY) = 3
> 15899 read(3, "# libmpfr.la - a libtool library"..., 945) = 945
> 15899 stat("/usr/lib64/libmpfr.la", {st_mode=S_IFREG|0755,
> st_size=945, ...}) = 0
> 5899 faccessat(AT_FDCWD, "/usr/lib64/libmpfr.la", R_OK) = 0
> 15899 open("/usr/lib64/libmpfr.la", O_RDONLY) = 3
> 15899 read(0, "# libmpfr.la - a libtool library"..., 128) = 128
> 15899 open("/usr/lib64/libmpfr.la", O_RDONLY) = 3
> 15899 read(3, "# libmpfr.la - a libtool library"..., 945) = 945
> 15952 execve("/bin/sed", ["/bin/sed", "-n", "-e",
> "s/^libdir=\\(.*\\)$/\\1/p", "/usr/lib64/libmpfr.la"], [/* 155 vars
> */]) = 0 15952 open("/usr/lib64/libmpfr.la", O_RDONLY) = 3
> 15952 read(3, "# libmpfr.la - a libtool library"..., 4096) = 945
>
> And similarly for libgmp.la. Makes you wonder, doesn't it.
>
Hmmm. That last sed looks promising. It's called
( grep -ir[l] 's/^libdir=' ./gcc-4.8.1/ ) from:
--
./gcc-4.8.1/gmp/ltmain.sh
./gcc-4.8.1/ltmain.sh
./gcc-4.8.1/mpfr/ltmain.sh
./gcc-4.8.1/libjava/libltdl/ltmain.sh
./gcc-4.8.1/libjava/classpath/ltmain.sh
./gcc-4.8.1/libgo/config/ltmain.sh
./gcc-4.8.1/mpc/ltmain.sh
--
; and similarly for that 'dependency_libs=' line per your earlier post.
A uniq-sort, across all of the above ltmain.sh files, of the sed lines gives:
==
eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $func_resolve_sysroot_result`
eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $lib`
==
That '$func_resolve_sysroot_result' jumps out: the problem you're seeing is
kindof a 'what do i think my sysroot is' matter.
Where to proceed from here: I'd say checking out the 'func_resolve_sysroot ()'
function-definitions in the respective ltmain.sh files (I'd expect it ok here
to just omit the lib{java,go} ones) - and noting that they're likely
quite-similar function-definitions across the different files (check via diff,
thus possibly saving duplication of work - usual stuff). Also, what would be
best way to get the values of $deplib , $func_resolve_sysroot_result , $lib ,
and $libdir , from the various points in the ltmain.sh scripts, in an
efficient way, and such that the output is easy to trace through with grep &c.
But for now, here, will need to turn to a bunch of other stuff.
> By the way, does this list accept attachments? A lot of list managers
> strip them automatically.
Pretty sure it does, tho' never used it.
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
