Re: [lfs-support] More control and package management using package users
I have completed an update to the "More Control Helpers" archive, complete with a revised build script, more features in the wrapper scripts and a few more handy scripts. Find it at this page... https://www.javacrypt.com/lfs/ On Mon, Sep 23, 2013 at 12:05 PM, Rob Taylor wrote: > I have been working through LFS 7.2, 7.3 and 7.4 testing and revising > scripts for this package management system. > > I have added a number of scripts and in some cases almost entirely > rewritten the existing scripts. While I have tested these scripts no one > else has so, my version of this package should be considered Alpha or Beta > at best. > > You can play with the revised project and see my notes here: > https://www.javacrypt.com/lfs/ > > I don't have a lot of time for development or support so use at your own > risk and use the lists here or Google as a resource if my replies seem > rather slow. > > Enjoy, > Robert Taylor > -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Automounting
On Mon, 2013-12-09 at 19:52 +, David Brodie wrote: > plus you need a polkit rules > file for udisks2, which is written in Javascript format for the latest > version of Polkit - this is a very simple example: My *deity*! It's bad enough that some config files are written in XML, but JavaScript for config files, really? Sometimes it makes me grateful for the length of time it takes the enterprise distros I use at work to get the latest and "greatest" versions of packages, if this is what I have to look forward to! Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
> > It looks like the the issue is specific to the x86 architecture. > I would ignore it. > > >-- Bruce > Will do. Thank you both. -- Ron Hartikka harti...@gmail.com -- 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: Sun, 8 Dec 2013 21:29:05 +
> 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
>
- apols for the delay in resuming.
> > * 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*
.
.
> 14:37 /usr/lib64/libgmpxx.so.4 -> libgmpxx.so.4.2.5*
>
> > $ md5sum /usr/lib64/lib{gmp,mpc,mpfr}*
> 347b12931c9b76ffa9b31b46a4cac672 /usr/lib64/libgmp.a
.
.
> 47382b481e1838836cfed7ccfd64f4ac /usr/lib64/libmpfr.so.4.1.0
>
Those all look sane; and can see the elflibs stuff in there too.
((
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
$
))
> 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.
>
Not quite 100% sure that it's been established. Just wanted to
double-check that nothing on host-os is different - e.g. bad-install or
changed via lfs-build leakage into host-os - from what would be expected.
>
.
.
> > * 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?
>
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.
Also would suggest redirecting all output from configure and from make, to
logfiles: fwiw I usually have nothing outputting to screen, and just
'tail -f logfiles' or similar.
Beyond a certain point, if it's really looking like a pathological case (some
might say it is already), then it may be worth looking/asking at
gcc/mpfr/gmp/mpc mailing lists, as they'll have a much more ready-made
knowledge of the various pathways through the code that can be hit. (Also as
noted earlier, it's not at all uncommon for folks to hit problems similar to
what you're seeing.)
rgds,
akh
--
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
William Harrington wrote: > > On Dec 9, 2013, at 6:44 AM, Ron Hartikka wrote: > >> I should have said I came across that thread and other threads >> elsewhere about this error. > > > As far as looking through the gcc-testresults mailing list: > > http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&ul=%2Fml%2Fgcc-testresults%2F%25&q=AddressSanitizer_HugeMallocTest > > Maybe you'll find your platform there. It looks like the the issue is specific to the x86 architecture. I would ignore it. -- 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] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
Thanks William, I understand you are saying I should be good to go. What is your platform? *Native configuration is i686-pc-linux-gnu* also *The host is:* *Ubuntu 13.10 32 bitPentium(R) Dual-Core CPU T4200 @ 2.00GHz × 22GiB memory* As far as looking through the gcc-testresults mailing list: > > http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&ul=%2Fml%2Fgcc-testresults%2F%25&q=AddressSanitizer_HugeMallocTest > Maybe you'll find your platform there. yes I guess I do. Like this, right? http://gcc.gnu.org/cgi-bin/search.cgi?q=AddressSanitizer_HugeMallocTest+i686-pc-linux-gnu+&cmd=Search%21&form=extended&m=all&ps=10&fmt=long&wm=wrd&sp=1&sy=1&wf=2221&type=&GroupBySite=no&ul=%2Fml%2Fgcc-testresults%2F%25 I'd like to learn is how to tell for myself from these results - or just one of them - that I'm OK to continue. Any advice on that? Thanks again, Ron -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
On Dec 9, 2013, at 6:44 AM, Ron Hartikka wrote: > I should have said I came across that thread and other threads > elsewhere about this error. As far as looking through the gcc-testresults mailing list: http://gcc.gnu.org/cgi-bin/search.cgi?wm=wrd&form=extended&m=all&s=D&ul=%2Fml%2Fgcc-testresults%2F%25&q=AddressSanitizer_HugeMallocTest Maybe you'll find your platform there. Sincerely, William Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
On Dec 9, 2013, at 6:44 AM, Ron Hartikka wrote: > But I didn't find a fix. > Nor could *I* glean an indication that it's safe for me to ignore. A huge number of failures indicates a problem. The specific error regarding AddressSanitizer_HugeMallocTest as a Failure would be platform specific. You can always refer to the GCC mailing lists as there are always current and past testsuite results. I haven't seen it fail with Sparc64, x86, x86_64, PPC, or PPC64. Current tests don't see it failing in vmware. What is your platform? Sincerely, WIlliam Harrington -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.4 / 6.17. GCC-4.8.1 ... FAIL: g++.dg/asan/asan_test.C
Hi William, Thank you. I should have said I came across that thread and other threads elsewhere about this error. But I didn't find a fix. Nor could *I* glean an indication that it's safe for me to ignore. Probably my failing. What did I miss? Thanks again, Ron On Sun, Dec 8, 2013 at 10:58 PM, William Harrington wrote: > > On Dec 8, 2013, at 8:55 PM, Ron Hartikka wrote: > > > Running target unix > > FAIL: g++.dg/asan/asan_test.C -O2 AddressSanitizer_HugeMallocTest > > Ident((char*)malloc(size))[-1] = 0 output pattern test, should match > > is located 1 bytes to the left of 2726297600-byte > > Hello Ron, > > This was reported back in August. > > http://thread.gmane.org/gmane.linux.lfs.devel/14295/focus=14318 > > Sincerely, > > William Harrington > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/lfs/faq.html > Unsubscribe: See the above information page > -- Ron Hartikka harti...@gmail.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
