Sheldon Hearn wrote:
> On (2003/09/02 09:43), Ian Freislich wrote:
>
> > > I posted one approach to this today... touch a file right before you
> > > start installworld, then consider anything not newer than that file a
> > > candidate for disposal. There is currently something weird going on in
>
On (2003/09/02 09:43), Ian Freislich wrote:
> > I posted one approach to this today... touch a file right before you
> > start installworld, then consider anything not newer than that file a
> > candidate for disposal. There is currently something weird going on in
> > /usr/lib though... a lot of
Doug Barton wrote:
> On Mon, 1 Sep 2003, M. Warner Losh wrote:
>
> > My tool is initially just a 'delete these files' tool, but now that I
> > think about it, it wouldn't be hard to say also 'create these
> > symlinks'. The hard part here is generating the 'obsolete' lists.
>
> I posted one appr
On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
> On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > > I might be missing an obvious, but I just don't see a reason
> > > > why we should use relative linking here: we should just link
> > > > to where we really insta
On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
>
> Now it looks like this:
>
> install -C -o root -g wheel -m 444 libalias.a /foo/usr/lib
> install -s -o root -g wheel -m 444 libalias.so.4 /foo/lib
> ln -fs libalias.so.4 /foo/lib/libalias.so
> ln -fs /lib/libalias.so.4 /fo
"M. Warner Losh" wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : I posted one approach to this today... touch a file right before you
> : start installworld, then consider anything not newer than that file a
> : candidate for disposal. There is cur
In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: On Mon, 1 Sep 2003, M. Warner Losh wrote:
: > In message: <[EMAIL PROTECTED]>
: > Doug Barton <[EMAIL PROTECTED]> writes:
: > : On Mon, 1 Sep 2003, M. Warner Losh wrote:
: > : > My tool is initially ju
On Mon, 1 Sep 2003, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Doug Barton <[EMAIL PROTECTED]> writes:
> : On Mon, 1 Sep 2003, M. Warner Losh wrote:
> :
> : > My tool is initially just a 'delete these files' tool, but now that I
> : > think about it, it wouldn't be hard
On Mon, Sep 01, 2003 at 09:31:29AM -0700, David O'Brien wrote:
> On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
> > On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
> > > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > > > > I might be missing an
On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
> On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
> > On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > > > I might be missing an obvious, but I just don't see a reason
> > > > > why we should use rel
In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: On Mon, 1 Sep 2003, Ruslan Ermilov wrote:
:
: > > I posted one approach to this today... touch a file right before you
: > > start installworld, then consider anything not newer than that file a
: > > candidate f
In message: <[EMAIL PROTECTED]>
Doug Barton <[EMAIL PROTECTED]> writes:
: On Mon, 1 Sep 2003, M. Warner Losh wrote:
:
: > My tool is initially just a 'delete these files' tool, but now that I
: > think about it, it wouldn't be hard to say also 'create these
: > symlinks'. The hard par
On Mon, 1 Sep 2003, Ruslan Ermilov wrote:
> > I posted one approach to this today... touch a file right before you
> > start installworld, then consider anything not newer than that file a
> > candidate for disposal. There is currently something weird going on in
> > /usr/lib though... a lot of th
On Mon, Sep 01, 2003 at 01:58:52AM -0700, Doug Barton wrote:
> On Mon, 1 Sep 2003, M. Warner Losh wrote:
>
> > My tool is initially just a 'delete these files' tool, but now that I
> > think about it, it wouldn't be hard to say also 'create these
> > symlinks'. The hard part here is generating th
On Mon, 1 Sep 2003, M. Warner Losh wrote:
> My tool is initially just a 'delete these files' tool, but now that I
> think about it, it wouldn't be hard to say also 'create these
> symlinks'. The hard part here is generating the 'obsolete' lists.
I posted one approach to this today... touch a fil
On Mon, Sep 01, 2003 at 01:22:49AM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> : On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
> : > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
In message: <[EMAIL PROTECTED]>
Ruslan Ermilov <[EMAIL PROTECTED]> writes:
: On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
: > On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
: > > I think that Gordon took a safe path with creating compatibility
On Mon, Sep 01, 2003 at 08:58:19AM +0200, Christoph P. Kukulies wrote:
> On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
> > I think that Gordon took a safe path with creating compatibility symlinks.
> > Besides, creating compatibility symlinks has a nicety of removing your
> > stal
On Mon, Sep 01, 2003 at 09:44:24AM +0300, Ruslan Ermilov wrote:
> I think that Gordon took a safe path with creating compatibility symlinks.
> Besides, creating compatibility symlinks has a nicety of removing your
> stale symlinks in /usr/lib.
I always asked myself whether there is a tool or some
On Sun, Aug 31, 2003 at 10:10:49PM -0700, David O'Brien wrote:
> On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > > I might be missing an obvious, but I just don't see a reason
> > > > why we should use relative linking here: we should just link
> > > > to where we really insta
On Sun, Aug 31, 2003 at 05:52:24PM +0300, Ruslan Ermilov wrote:
> > > I might be missing an obvious, but I just don't see a reason
> > > why we should use relative linking here: we should just link
> > > to where we really install. With the attached patch, I get:
...
> +.if ${LIBDIR} != ${SHLIBDIR
I found the problem with my system here:
I had a libc.so.5 in /usr/lib of Jan 16. Concurrently
the newly installed libc.so.5 lives in /lib.
After removing /usr/lib/libc.so.5 the binary (httpd)
worked.
On Sat, Aug 30, 2003 at 01:54:27PM +0200, Alexander Leidinger wrote:
> On Fri, 29 Aug 2003 09
On Sun, 31 Aug 2003 17:52:24 +0300
Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
> Doh, you're of course right! An updated patch is attached.
I successfully tested an installworld, nm doesn't fail anymore in my
environment and cdrdao compiles just fine.
Bye,
Alexander.
--
It is easier
On Sat, 30 Aug 2003 21:56:53 +0300
Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
> > I think a workaround would be to use absolute symlinks (at least as an
> > option).
> >
> I might be missing an obvious, but I just don't see a reason
> why we should use relative linking here: we should just link
>
On Sun, Aug 31, 2003 at 02:07:42PM +0200, Alexander Leidinger wrote:
> On Sat, 30 Aug 2003 21:56:53 +0300
> Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
>
> > > I think a workaround would be to use absolute symlinks (at least as an
> > > option).
> > >
> > I might be missing an obvious, but I just d
On Sat, Aug 30, 2003 at 01:54:27PM +0200, Alexander Leidinger wrote:
[...]
> I think the problem is, that some tools have a problem finding it...:
> ---snip---
> (3) [EMAIL PROTECTED] % nm -D /usr/lib/libc.so | grep fpcl
> nm: /usr/lib/libc.so: No such file or directory
>
> (4) [EMAIL PROTECTED] %
On Fri, 29 Aug 2003 09:19:07 -0700
Steve Kargl <[EMAIL PROTECTED]> wrote:
> Are you linking in libc?
>
> troutmask:kargl[207] nm -D /usr/lib/libc.so | grep fpcl
> 000b0040 T __fpclassifyd
> 000afff0 T __fpclassifyf
> 000b00a0 T __fpclassifyl
I think the problem is, that some tools have a problem
27 matches
Mail list logo
