On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
>
> I was wrong in retracting, my LFS-svn results definitely show this for
> all builds after the first. I can't yet see why the symlink is moving
> (and I've spent twenty minutes looking at readline's shlib/Makefile and
> support/shlib-install).
On Tue, 17 Jan 2006, Dan Nicholson wrote:
Seems to me like this whole issue with the .old libraries for readline
should just be eliminated. It's the only package that does this. DIY
has
sed -i.bak '/MV.*old/d' Makefile
Well, when it works, it looks good (update in place, decide you don't
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jan 2006, Ken Moffat wrote:
>
> > On Mon, 16 Jan 2006, Tushar Teredesai wrote:
> >
> >> On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> >>> libhistory.so.5 (symlink, points to .old after in-place rebuild)
> >>> libreadline.so.5
On Mon, 16 Jan 2006, Ken Moffat wrote:
On Mon, 16 Jan 2006, Tushar Teredesai wrote:
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
libhistory.so.5 (symlink, points to .old after in-place rebuild)
libreadline.so.5 (ditto)
Shouldn't the link point to the .so.5 library? I don't remember
On Mon, 16 Jan 2006, Tushar Teredesai wrote:
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
libhistory.so.5 (symlink, points to .old after in-place rebuild)
libreadline.so.5 (ditto)
Shouldn't the link point to the .so.5 library? I don't remember seeing
that problem even when I used to
On 1/16/06, Ken Moffat <[EMAIL PROTECTED]> wrote:
> libhistory.so.5 (symlink, points to .old after in-place rebuild)
> libreadline.so.5 (ditto)
Shouldn't the link point to the .so.5 library? I don't remember seeing
that problem even when I used to upgrade in-place (I have been using
the fakero
Hopefully, these are my last ICA results before looking at a toolchain
which doesn't initially link to /tools. The book is from 20060110 with
mktemp back where it used to be, a sed for gccbug, and Greg's change to
bison. Built three times, without locales or testsuites, all except the
first
