> Date: Thu, 12 Dec 2013 11:41:03 +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
>
> > 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 ?
>
- meant to add, that I wouldn't bother too much about running strace for
this stage, unless you want to. But do keep those strace logs that you've
obtained thus far.
>
>
> rgds,
>
> akh
>
>
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
