> Date: Wed, 11 Dec 2013 14:27:17 +0000
> From: lf...@cruziero.com (akhiezer)
> To: LFS Support List <lfs-support@linuxfromscratch.org>
> Subject: Re: [lfs-support] GCC build first pass: mpc build looks for
> libgmp.la in the wrong place
>
.
.
> > 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.
>
Could you put the following stuff that's shown between the two '----'
delimiter lines, at the top of each of the four files
'./gcc-4.8.1/{,{gmp,mpfr,mpc}/}ltmain.sh' - after their respective opening
chunks of comments and just before the 'PROGRAM=libtool' and 'PACKAGE=libtool'
lines (that exact positioning is of course not strictly essential):
----
export PS4=" _zoiks_(${0})__ ${PS4}";
set -v;
set -x;
set -o functrace;
shopt -s extdebug;
echo "PS4:${PS4}";
----
(Sorry that's not sent as a patch - could've checked out the attachments
thing in practice; any larger changeset &/or files-to-be-modified, then
would've.)
And then run the configure and make sections again, but capturing everything
to file and not outputting anything to screen, with e.g.:
{ configure-command-line ; } 1>cfg.stoe 2>&1
{ make-command-line ; } 1>mkbld.stoe 2>&1
That part about not outputting anything to screen is not essential: but it
helps ensure/verify that we're not missing anything being captured into the
logfiles.
I should note that I've not yet done a test-run of the cfg/build with the
above in place; so there may be a glitch or so. This is mentioned in case you
want to avoid possibly wasting your time. However, have tested the stuff
with some basic scripts, and it should produce output that can be of use in
tracing through what's happening in those ltmain.sh parts of the code. The
PS4 stuff should show the chain of calling scripts; so some lines might get
long, and so 'less -S' might help - usual stuff. The 'zoiks' is just a tag
for checking/grepping. Am hoping to get onto a test cfg/build by end of
weekend at the latest.
Also, as a control-check: can you force failure of the cfg/build, by
(temporarily) moving aside the host-os /usr/lib64/libgmp.la file: does the
cfg/build still fail at the same place, with the sed message complaining
'no such file' re /usr/lib64/libgmp.la ?
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
