Re: [lfs-support] Ethernet Card Not Found
Alan Feuerbacher wrote: > On 11/25/2013 8:40 PM, Bruce Dubbs wrote: >> Alan Feuerbacher wrote: >>> On 11/25/2013 11:50 AM, Bruce Dubbs wrote: Dan McGhee wrote: >>> >> r8169 71677 0 >> mii13527 1 r8169 Looking at the help in the kernel for CONFIG_R8169: Selects: FW_LOADER [=y] && CRC32 [=y] && MII [=y] >>> >>> How does one access this "help"? >> >> Use a / and type in a term. > > Can you explain this more fully? While in menuconfig, type /. You can figure it out from there. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Ethernet Card Not Found
On 11/25/2013 8:40 PM, Bruce Dubbs wrote: > Alan Feuerbacher wrote: >> On 11/25/2013 11:50 AM, Bruce Dubbs wrote: >>> Dan McGhee wrote: >> > r8169 71677 0 > mii13527 1 r8169 >>> >>> Looking at the help in the kernel for CONFIG_R8169: >>> >>> Selects: FW_LOADER [=y] && CRC32 [=y] && MII [=y] >> >> How does one access this "help"? > > Use a / and type in a term. Can you explain this more fully? Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] GCC build first pass: mpc build looks for libgmp.la in the wrong place
> Date: Wed, 11 Dec 2013 12:12:49 +
> From: Hazel Russman
> 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 +
> 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 informati
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 +
lf...@cruziero.com (akhiezer) wrote:
> 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 root901 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 $
> ))
Yes, I have all these. Size, permissions and md5sums all match.
> > > * 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.
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).
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.
> > > 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.
>
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, "# libmpf
