On 3/1/12 4:41 AM, Pierre Labastie wrote:
> ---
> diff -ur iteration-1/usr/lib/libgmpxx.la iteration-2/usr/lib/libgmpxx.la
> --- iteration-1/usr/lib/libgmpxx.la 2012-02-29 15:54:39.0 +0100
> +++ iteration-2/usr/lib/libgmpxx.la 2012-02-29 17:59:46.0 +0
?"
Of course in our case, it builds, but a further test is:
"does it build as before?"
I haven't really tried to ensure the full compatibility with
before, but just performed ICA on the new build
method. Actually, since chapter 6 is not modified in
that method, I would expect that
On Wed, 22 Feb 2012 10:02:24 +0100, Pierre Labastie
wrote:
> Should be corrected in current upstream patch list. Do not know
> if you LFS devs think it is a big issue (having math.h needlessly
> included when ncurses C++ bindings are used). I suggest
> waiting for the next release of ncurses.
Y
Le 21/02/2012 21:51, Andrew Benton a écrit :
> On Tue, 21 Feb 2012 09:47:00 +0100
> Pierre Labastie wrote:
>
>> Hi,
>>
>> I have done a test of LFS-7.1-rc1. ICA went OK, except the
>> already reported problem with ld.so.cache (ldconfig still missing
>> s
On Tue, 21 Feb 2012 09:47:00 +0100
Pierre Labastie wrote:
> Hi,
>
> I have done a test of LFS-7.1-rc1. ICA went OK, except the
> already reported problem with ld.so.cache (ldconfig still missing
> somewhere), which is not a big issue. In case somebody else
> does ICA, there
On Tue, 21 Feb 2012 09:47:00 +0100
Pierre Labastie wrote:
> Hi,
>
> I have done a test of LFS-7.1-rc1. ICA went OK, except the
> already reported problem with ld.so.cache (ldconfig still missing
> somewhere), which is not a big issue. In case somebody else
> does ICA, there
Hi,
I have done a test of LFS-7.1-rc1. ICA went OK, except the
already reported problem with ld.so.cache (ldconfig still missing
somewhere), which is not a big issue. In case somebody else
does ICA, there is this difference in etip.h between ICA
iterations 1 and 2
Matt Burgess wrote:
> On Sun, 2012-01-29 at 15:58 -0600, Bruce Dubbs wrote:
>> Pierre Labastie wrote:
>>
>>> I have not tried to add /tools to a LIBRARY_PATH, because I am
>>> (maybe wrongly) worried about linking to a libraries which are
>>> then removed.
>> I think that is a needless worry. gcc
On Sun, 2012-01-29 at 15:58 -0600, Bruce Dubbs wrote:
> Pierre Labastie wrote:
>
> > I have not tried to add /tools to a LIBRARY_PATH, because I am
> > (maybe wrongly) worried about linking to a libraries which are
> > then removed.
>
> I think that is a needless worry. gcc uses LIBRARY_PATH so
script}
# Suppress the mod of "test-installation.pl" because now
# the library path points to /usr/lib
if [[ ${script} =~ glibc ]]; then
--
For now, I am busy testing ICA. Looks like it works and some
useful information may be extracted.
Regards
Pierre
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Pierre Labastie wrote:
> I have not tried to add /tools to a LIBRARY_PATH, because I am
> (maybe wrongly) worried about linking to a libraries which are
> then removed.
I think that is a needless worry. gcc uses LIBRARY_PATH so it can get
the linkages, but when running, the LD_LIBRARY_PATH vari
Le 28/01/2012 00:30, Bruce Dubbs a écrit :
> Pierre Labastie wrote:
>> Well, the reason why grub does not find liblzma is much simpler
>> anyway: grub is built before xz!
>
> It should find xz from Chapter 5. The liblzma.so.5.0.3 is in /tools and
> it does have the lzma_code reference.
>
> There a
On Sat, 28 Jan 2012 13:28:19 +0100
Pierre Labastie wrote:
> Hi,
>
> Maybe another thing to worry about:
> --
> --- iteration-1/usr/lib/libgmpxx.la
> +++ iteration-2/usr/lib/libgmpxx.la
> @@ -17,7 +17,7 @@
> inherited_linker_flags=''
>
> # Librarie
Hi,
Maybe another thing to worry about:
--
--- iteration-1/usr/lib/libgmpxx.la
+++ iteration-2/usr/lib/libgmpxx.la
@@ -17,7 +17,7 @@
inherited_linker_flags=''
# Libraries that this one depends upon.
-dependency_libs=' /usr/lib/libgmp.la'
+dependency
On Thu, 2012-01-26 at 19:15 -0500, Thomas Pegg wrote:
> I noticed the patch too but haven't had time to thoroughly review it
> yet. But I would say before it does get applied a new stable release of
> jhalfs as there have been a few fixes since the last stable so we have
> known good working ve
ls to a
LIBRARY_PATH environment variable. We could also just append
#define HAVE_LIBLZMA 1" >>confdefs.h
after configure in GRUB. We could also move xz to be before GRUB.
> Not a big deal, unless you want to create compressed boot images
> (the only possible compression is xz). But sh
Le 28/01/2012 00:01, Matt Burgess a écrit :
>
> OK, so running ldconfig just after pass2 should fix things up then, do
> you think?
>
Oh, I should not have used pass 1, 2: I meant the ICA passes.
Let us call them 'build'.
Running ldconfig at the end of build 1 (Section 6
running ldconfig just after pass2 should fix things up then, do
you think?
> Well, the reason why grub does not find liblzma is much simpler
> anyway: grub is built before xz!
Ah, good catch, and exactly the kind of thing ICA was developed to find.
Once this latest build of mine is done, I&#x
Le 27/01/2012 19:46, Bruce Dubbs a écrit :
>
> Pierre Labastie wrote:
>> Hi,
>>
>> I think I spotted something by doing ICA (not all investigated yet).
>> ld.so.cache differs at the end of pass 1 and at the end of pass 2.
>> It can be printed with ldcon
Pierre Labastie wrote:
> Hi,
>
> I think I spotted something by doing ICA (not all investigated yet).
> ld.so.cache differs at the end of pass 1 and at the end of pass 2.
> It can be printed with ldconfig -p, and then diffed, which gives:
> Now, one differing binary file is g
Hi,
I think I spotted something by doing ICA (not all investigated yet).
ld.so.cache differs at the end of pass 1 and at the end of pass 2.
It can be printed with ldconfig -p, and then diffed, which gives:
--- ld.so.cache-1 2012-01-27 19:19:13.0 +0100
+++ ld.so.cache-2 2012
On 1/26/2012 12:32 PM, Matthew Burgess wrote:
> On Thu, 26 Jan 2012 18:27:04 +0100, Pierre Labastie
> wrote:
>> Hi,
>>
>> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
>> lately.
> I use jhalfs all the time, but I've never done an
Matthew Burgess wrote:
> On Thu, 26 Jan 2012 18:27:04 +0100, Pierre Labastie
> wrote:
>> Hi,
>>
>> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
>> lately.
>
> I use jhalfs all the time, but I've never done an ICA build with it.
Le 26/01/2012 19:10, Ken Moffat a ecrit :
> On Thu, Jan 26, 2012 at 06:27:04PM +0100, Pierre Labastie wrote:
>> Hi,
>>
>> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
>> lately.
> I gave up on my own version of ICA ('farce') years a
On Thu, Jan 26, 2012 at 06:27:04PM +0100, Pierre Labastie wrote:
> Hi,
>
> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
> lately.
I gave up on my own version of ICA ('farce') years ago - there were
too many unexplainable differences on x86_64, which
On Thu, 26 Jan 2012 18:27:04 +0100, Pierre Labastie
wrote:
> Hi,
>
> I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
> lately.
I use jhalfs all the time, but I've never done an ICA build with it.
> ICA is broken because of the part in glibc&#
Hi,
I wonder if anybody still uses jhalfs, and if he(she) has tried ICA
lately.
ICA is broken because of the part in glibc's instructions, which
instructs 'test-installation.pl' to look for /usr/lib rather than
/tools/lib. On the second (and following) pass, the line 'DL=.
- Original Message -
From: "Gilles Espinasse"
To: "LFS Developers Mailinglist"
Sent: Monday, October 27, 2008 11:55 PM
Subject: Re: ICA/Farce
>
> - Original Message -
> From: "Ken Moffat"
> To: "LFS Developers Mailingl
- Original Message -
From: "Ken Moffat" <[EMAIL PROTECTED]>
To: "LFS Developers Mailinglist"
Sent: Monday, October 27, 2008 11:06 PM
Subject: Re: ICA/Farce
> On Mon, Oct 27, 2008 at 06:36:07PM +0100, Gilles Espinasse wrote:
> >
On Mon, Oct 27, 2008 at 10:15:31AM -0700, Dan Nicholson wrote:
> In farce, Ken had some
> functions that would skip these stamps, but I don't recall how he
> implemented that.
>
For gzipped files, just cmp -s -i 8 (the comment says bytes 4,5,6,7
are the timestamp, hopefully everything ahead of i
On Mon, Oct 27, 2008 at 06:36:07PM +0100, Gilles Espinasse wrote:
> Selon Ken Moffat <[EMAIL PROTECTED]>:
>
> ...
> >
> > Archaic saw unresolved differences for x86 with gcc-4.1.2.
> > Actually, looking at his results (they're at ~/archaic) they look
> > pretty good - blkid.tab.old and locale-arc
Selon Ken Moffat <[EMAIL PROTECTED]>:
...
>
> Archaic saw unresolved differences for x86 with gcc-4.1.2.
> Actually, looking at his results (they're at ~/archaic) they look
> pretty good - blkid.tab.old and locale-archive should probably now
> be expected to differ, and they were the only differe
c-2.3.3_notimestamp.patch?revision=1.1.2.1&view=markup&pathrev=IPCOP_v1_4_0
>
> http://ipcop.cvs.sourceforge.net/viewvc/ipcop/ipcop/src/patches/perl-5.8.5-notimestamp.patch?view=log&pathrev=IPCOP_v1_4_0
Right. I was doing the same when I was doing ICA regularly. Something like
se
On Mon, Oct 27, 2008 at 06:51:38AM -0700, Dan Nicholson wrote:
> On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer <[EMAIL PROTECTED]> wrote:
> >
> > I've never looked at jhalfs but I understand it implements my ICA
> > algorithms. My own scripts have been getting
Selon Dan Nicholson <[EMAIL PROTECTED]>:
...
>
> The actual implementation mostly involves preparing to diff/cmp, and
> is probably better explained by the comments in gsbuild. Look at the
> bottom of the functions file for do_ica_prep() and do_ica_work().
>
>
http://cvs.diy-linux.org/index.cgi/gs
On Mon, Oct 27, 2008 at 2:59 AM, TheOldFellow <[EMAIL PROTECTED]> wrote:
>
> What I meant to say was that I, for one, would be grateful for any
> additional documentation of the subject.
It's pretty straightforward, although I might butcher some of the terminology.
The main goal is to see if the
On Sun, Oct 26, 2008 at 2:00 PM, Greg Schafer <[EMAIL PROTECTED]> wrote:
>
> I've never looked at jhalfs but I understand it implements my ICA
> algorithms. My own scripts have been getting exceptionally clean
> results lately now that the randomness in GCC builds has appa
lfs is based on my own practices in DIY? Which in turn was
> > based on the old lfscmd from about 8 years ago? :-)
> >
> > But getting back on topic, I should really write up some proper docs on
> > ICA some day, instead of relying on the random mailing list spatteri
t's *VERY* convenient. I should know..
>
> (Me wonders if Bruce realizes the whole "build straight from the doc"
> concept in jhalfs is based on my own practices in DIY? Which in turn was
> based on the old lfscmd from about 8 years ago? :-)
>
> But getting back
do a sanity
> check on the development LFS. A positive ICA run would do us very well
> to prove that the old build method is at least still working, even
> though it is dated.
>
Well, since Greg has said that the 4.3 gcc builds have lost the
randomness he was seeing, maybe farce will again b
Greg Schafer wrote:
> DJ Lucas wrote:
>
>
>> Hey guys. Is there any recent documentation on the expectations of
>> farce or ICA?
>>
>
> Docs? What docs :-)
>
>
>> Doing only 2 passes of chapter6
>> with both comparison methods checke
Greg Schafer wrote:
> (Me wonders if Bruce realizes the whole "build straight from the doc"
> concept in jhalfs is based on my own practices in DIY? Which in turn was
> based on the old lfscmd from about 8 years ago? :-)
>
OT, but Wow, good memory! Timothy B. right? (I'd have butchered his
la
"
concept in jhalfs is based on my own practices in DIY? Which in turn was
based on the old lfscmd from about 8 years ago? :-)
But getting back on topic, I should really write up some proper docs on
ICA some day, instead of relying on the random mailing list spatterings
over the years
Jeremy Huntwork wrote:
> Bruce Dubbs wrote:
>> Umm, no. jhalfs parses the xml of the book and creates a Makefile that
>> builds
>> by the LFS book. Actually, it is quite convenient.
>
> ICA is in fact implemented as an optional feature of jhalfs. Which means
>
Bruce Dubbs wrote:
> Umm, no. jhalfs parses the xml of the book and creates a Makefile that
> builds
> by the LFS book. Actually, it is quite convenient.
ICA is in fact implemented as an optional feature of jhalfs. Which means
that when it's done building LFS by the book,
Bruce Dubbs wrote these words on 10/26/08 16:32 CST:
> Greg Schafer wrote:
>> I've never looked at jhalfs but I understand it implements my ICA
>> algorithms. My own scripts have been getting exceptionally clean
>> results lately now that the randomness in GCC builds ha
Greg Schafer wrote:
> DJ Lucas wrote:
>
>> Hey guys. Is there any recent documentation on the expectations of
>> farce or ICA?
>
> Docs? What docs :-)
>
>> Doing only 2 passes of chapter6
>> with both comparison methods checked. What are the advantages
DJ Lucas wrote:
> Hey guys. Is there any recent documentation on the expectations of
> farce or ICA?
Docs? What docs :-)
> Doing only 2 passes of chapter6
> with both comparison methods checked. What are the advantages of 3 or
> more passes?
Huh? ICA by definition is 3
On Sat, Oct 25, 2008 at 05:36:02PM -0500, DJ Lucas wrote:
> Hey guys. Is there any recent documentation on the expectations of
> farce or ICA? I'm out of time for the weekend, so figured now was a
> good time to fire off and let it fly. Doing only 2 passes of chapter6
> wit
Hey guys. Is there any recent documentation on the expectations of
farce or ICA? I'm out of time for the weekend, so figured now was a
good time to fire off and let it fly. Doing only 2 passes of chapter6
with both comparison methods checked. What are the advantages of 3 or
more p
be stripped
> >> out after the build. I'm assuming that the original difference is just
> >> debugging symbols like would normally be the case. I'll try to narrow
> >> that down further, but this may be a false positive ICA regression.
> >
> > I too
t; debugging symbols like would normally be the case. I'll try to narrow
>> that down further, but this may be a false positive ICA regression.
>
> I took a look at the diff of the `objdump -s' output from the
> unstripped cc1-dummy in each iteration. All the diff
On 3/20/07, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> Attached are two patches to add the glibc branch update patch in Ch. 5
> and force /usr/include to be used as the preferred system include
> directory after the toolchain re-adjustment.
No comments, so I'm applying these.
--
Dan
--
http://
On 3/20/07, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> Attached are two patches to add the glibc branch update patch in Ch. 5
> and force /usr/include to be used as the preferred system include
> directory after the toolchain re-adjustment.
I should mention that I changed the specs adjustment to
further, but this may be a false positive ICA regression.
I took a look at the diff of the `objdump -s' output from the
unstripped cc1-dummy in each iteration. All the differences were in
the .debug sections, so I think I can say that the difference in cc1
and cc1plus can be ignored a
;-v' to the sanity check output, you'll see
> > that it's still looking in /tools/include.
>
> Regardless of whether it fixes the ICA regression or not, this tweak
> should be considered for LFS because it fixes an outright bug in the build
> method.
>
> > Now I th
On Wednesday 14 March 2007 16:43, Dan Nicholson wrote:
> Manuel brought up a recent regression shown by ICA in cc1 and cc1plus.
Dan, thanks for looking into this. It seems pretty clear that we need both
fixes here, i.e. i) Apply the Glibc patch in chapter 5 and ii) Point GCC to
the head
;-v' to the sanity check output, you'll see
> > that it's still looking in /tools/include.
>
> Regardless of whether it fixes the ICA regression or not, this tweak
> should be considered for LFS because it fixes an outright bug in the build
> method.
Yeah, my thinking was a
Dan Nicholson wrote:
> Manuel brought up a recent regression shown by ICA in cc1 and cc1plus.
> Then I remembered one other thing Greg recently tweaked for more purity.
>
> http://www.diy-linux.org/pipermail/diy-linux-dev/2006-December/000967.html
>
> One of the things that
Manuel brought up a recent regression shown by ICA in cc1 and cc1plus.
http://linuxfromscratch.org/pipermail/lfs-dev/2007-February/059037.html
I did some investigation on this. I reproduced it running jhalfs, but
it didn't show up in my own scripts. I've got a few DIY tweaks in
t
On Sun, Jan 28, 2007 at 06:33:48PM +, Matthew Burgess wrote:
> On Tuesday 09 January 2007 19:00, Ken Moffat wrote:
> >
> > All headers in /usr/include are blown away by
> > 'make INSTALL_HDR_PATH=/usr headers_install' which has "unfortunate"
> > results on glibc (thinks I'm building for i686-p
On Tuesday 09 January 2007 19:00, Ken Moffat wrote:
> After a long absence on other architectures, I'm trying to get back
> into LFS itself. I've got 2006-12-09 working nicely on two boxes
> (modulo unrelated kernel issues), so now I'm trying to run an
> in-place install so that I can see if farc
7;t that important ;-) OTOH, after
> all the effort people went to last year, we should probably sed it
> out, something like
>
> sed -i '/^.*Q.rm -rf.*INSTALL_HDR_PATH.*$/d' Makefile
>
> looks as if it will do the job (it definitely takes the line out,
> but I haven&
sed -i '/^.*Q.rm -rf.*INSTALL_HDR_PATH.*$/d' Makefile
looks as if it will do the job (it definitely takes the line out,
but I haven't tested it). I would appreciate help with explaining
_why_ the book should include this, when it only benefits people
running ICA, and potentially a
Greg Schafer wrote:
> Those binutils headers are utterly useless. Nothing needs them.
Woops. To clarify, I meant to add "... at this early stage of the build.".
They can, of course, be useful in a completed system.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mail
M.Canales.es wrote:
> Are the headers files already sanitized inside the kernel tree or are they
> generated on-the-fly by "make headers-install" command ?
On the fly.
> If the last, the tools used to generate the headers files (the ones in /tools
> for the first build, but the ones in /{bin,u
El Miércoles, 6 de Diciembre de 2006 12:10, Greg Schafer escribió:
> IMHO there is little point in reinstalling the kernel headers during
> subsequent ICA iterations. I've never done it. After all, they are not
> binary, they are just ascii text.
Are the headers files already sa
M.Canales.es wrote:
> Doing yesterday a SVN-20061201 build to test current ICA/farce support in
> jhalfs I found that the first iterative build of Glibc fails at the configure
> stage with that:
> As can be seen, when finished the system build both /usr/include/limits.h
> a
Hi,
Doing yesterday a SVN-20061201 build to test current ICA/farce support in
jhalfs I found that the first iterative build of Glibc fails at the configure
stage with that:
=== ./configure output fragment
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor
On 4/10/06, Dan Nicholson <[EMAIL PROTECTED]> wrote:
>
> I'll make another run later. I'm doing a run with all the testsuites.
> In automake right now. I'll be crossing my fingers that this won't
> be a problem.
The issue with pruning too much of the files
M.Canales.es wrote:
analisys
Mmm...sounds itchy. Have you tried using a cream?
Andy
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
El Lunes, 10 de Abril de 2006 21:22, Dan Nicholson escribió:
> I'll make another run later. I'm doing a run with all the testsuites.
> In automake right now. I'll be crossing my fingers that this won't
> be a problem.
I will start a new build now also.
iteration-1 now run until the end, but w
On 4/10/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 10 de Abril de 2006 21:12, Dan Nicholson escribió:
>
> > Yeah, that fixed it. I should report that one back to the author. :-)
> > Are you getting differences in the headers?
>
> Not full test yet. I'm fixing the bugs as they bombs t
El Lunes, 10 de Abril de 2006 21:12, Dan Nicholson escribió:
> Yeah, that fixed it. I should report that one back to the author. :-)
> Are you getting differences in the headers?
Not full test yet. I'm fixing the bugs as they bombs the Makefile run ;-)
--
Manuel Canales Esparcia
Usuario de LF
On 4/10/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> >
> > I think that do_ica_files is skipping the full /usr/include/sys tree, and
> > maybe others files that match $PRUNEPATH pattners.
>
> Look like I have that fixed for jhalfs changing the /tmp/prunelist creation to
> this:
>
> for F in $1 ; d
On 4/10/06, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Lunes, 10 de Abril de 2006 15:33, Dan Nicholson escribió:
> > The ICA run finished up on the merged alphabetical/udev_update branch.
> > Results were as clean as always. Results can be found in the farce
> &g
El Lunes, 10 de Abril de 2006 20:39, M.Canales.es escribió:
> Please Dan, can you corfirm if the next file, for example, is into your
> copied trees for iteration analisys?
>
> ../usr/include/sys/procfs.h
>
> I think that do_ica_files is skipping the full /usr/include/sys tree, and
> maybe others
El Lunes, 10 de Abril de 2006 15:33, Dan Nicholson escribió:
> The ICA run finished up on the merged alphabetical/udev_update branch.
> Results were as clean as always. Results can be found in the farce
> and ica directories here:
Please Dan, can you corfirm if the next file, for ex
On Mon, Apr 10, 2006 at 06:33:39AM -0700, Dan Nicholson wrote:
> The ICA run finished up on the merged alphabetical/udev_update branch.
> Results were as clean as always. Results can be found in the farce
> and ica directories here:
Thanks for you hard work, Dan. This is very
The ICA run finished up on the merged alphabetical/udev_update branch.
Results were as clean as always. Results can be found in the farce
and ica directories here:
http://anduin.linuxfromscratch.org/~dnicholson/lfs-alpha-20060408-reports/
Test suites were not run since Manuel built the same
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
> > I haven't been running the testsuites, but I'm doing that now to make
> > sure that their dependencies are met.
>
> Good man! As has already been seen with perl and db, and I think a
> locale for co
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
> I guess clfs doesn't have this problem because it is using a newer
> snapshot of glibc. Does that seem reasonable ?
Greg once posted a reference to an upstream bug report. But I don't
know whether it is fixed or not. One way to find out is b
On Fri, 27 Jan 2006, Ken Moffat wrote:
On Fri, 27 Jan 2006, Tushar Teredesai wrote:
Maybe one of the package does this. Try this to verify that it is
indeed a problem with ldconfig.
Compile readline as follows:
./configure --prefix=/tmp/readline
make
make install
make install
ls -l /tmp/read
Jeremy Huntwork wrote:
Matthew Burgess wrote:
1) Have the two toolchain bugs (1675 and 1677 - note that 1675's title
isn't entirely accurate!) fixed in LFS trunk. I'd need to re-read the
discussions on those two to figure out quite what's wrong and how to fix
them, or someone else could just
On Fri, 27 Jan 2006, Tushar Teredesai wrote:
Maybe one of the package does this. Try this to verify that it is
indeed a problem with ldconfig.
Compile readline as follows:
./configure --prefix=/tmp/readline
make
make install
make install
ls -l /tmp/readline/lib
ldconfig -n /tmp/readline/lib
ls
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> My script makes no explicit calls to ldconfig.
>
>
Maybe one of the package does this. Try this to verify that it is
indeed a problem with ldconfig.
Compile readline as follows:
./configure --prefix=/tmp/readline
make
make install
make install
On Fri, 27 Jan 2006, Tushar Teredesai wrote:
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
On the non-alphabetic book, with utf8, I never managed to track down
why updating readline in place was leaving the symlinks pointing to
.old. FWIW clfs (ppc) was ok for that, so it must have been
On 1/27/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
> On the non-alphabetic book, with utf8, I never managed to track down
> why updating readline in place was leaving the symlinks pointing to
> .old. FWIW clfs (ppc) was ok for that, so it must have been a problem
> specific to the non-alphabeti
Long ago, On Tue, 24 Jan 2006, Dan Nicholson wrote:
Hi again,
Here's some results from my ICA/Farce run of yesterday. They show
that the system will rebuild itself with the exception of a couple
things that probably won't be fixed by me. (stdc++ .la and gch
differences) These exi
Matthew Burgess wrote:
> 1) Have the two toolchain bugs (1675 and 1677 - note that 1675's title
> isn't entirely accurate!) fixed in LFS trunk. I'd need to re-read the
> discussions on those two to figure out quite what's wrong and how to fix
> them, or someone else could just post patches and I'
On 1/25/06, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
>
> > Unfortunately, the *startfile_prefix_spec doesn't work (at least for
> > me) on gcc-4.0.2.
>
> How did you test it? I found during my initial research that this spec
> doesn't work when placed into an external file
Gu
On 1/25/06, Matthew Burgess
>
> What I'd like to do now is:
>
> 1) Have the two toolchain bugs (1675 and 1677 - note that 1675's title
> isn't entirely accurate!) fixed in LFS trunk. I'd need to re-read the
> discussions on those two to figure out quite what's wrong and how to fix
> them, or someo
Dan Nicholson wrote:
> Unfortunately, the *startfile_prefix_spec doesn't work (at least for
> me) on gcc-4.0.2.
How did you test it? I found during my initial research that this spec
doesn't work when placed into an external file and called with eg:
-specs=/tmp/specs. However, it did work when th
that thread is true. I did some analyis shortly
afterwards. See this post for some long-winded results.
http://linuxfromscratch.org/pipermail/lfs-dev/2006-January/055149.html
Having done the ICA, I can say that there is enough redundancy that
the stripped binaries are not different when t
Matthew Burgess wrote:
> 1) Have the two toolchain bugs (1675 and 1677 - note that 1675's title
> isn't entirely accurate!) fixed in LFS trunk. I'd need to re-read the
> discussions on those two to figure out quite what's wrong and how to fix
> them, or someone else could just post patches and
Dan Nicholson wrote:
Hi again,
Here's some results from my ICA/Farce run of yesterday. They show
that the system will rebuild itself with the exception of a couple
things that probably won't be fixed by me. (stdc++ .la and gch
differences) These exist whether I use the LFS or DIY
On Wed, Jan 25, 2006 at 07:24:13AM -0800, Dan Nicholson wrote:
> > Also, as Greg once mentioned, I'm a little interested in putting
> > ICA/farce support usage into jhalfs. That too, might make the work a bit
> > easier. If you feel like helping with that as well...
On 1/24/06, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
> Well, if you could spell out your steps exactly when doing an ICA (or
> point me to the thread if you've said before and I missed it) that might
> help - more might offer to start running the comparisons.
Fortunat
Dan Nicholson wrote:
> Also, I might be a little worn out on ICA to do this, but we've only
> determined the true dependencies for about half the packages in Ch. 6.
> I was thinking that I might reverse the order to see what happens
> with the packages at the end of the alphab
st notes on this. The order was pretty
much in place before I started playing with it. I only discovered a
couple significant changes. I never really figured out which packages
depend on things from /tools, but aren't linked to them. Hopefully
Chris has better info than I do.
Also, I might
1 - 100 of 163 matches
Mail list logo
