Hi!
libdiskfs #includes pager.h (libpager). If pager is not contained in
HURDLIBS, then the system-wide file from /include will be used and not
the one from the currently-being-built Hurd tree. That won't be an issue
if both of them adhere to the same API, which they didn't for me, as I
was buil
At Tue, 7 Feb 2006 10:17:53 -0500,
Thomas Schwinge <[EMAIL PROTECTED]> wrote:
>
> Hi!
>
> libdiskfs #includes pager.h (libpager). If pager is not contained in
> HURDLIBS, then the system-wide file from /include will be used and not
> the one from the currently-being-built Hurd tree. That won't
I admit I'm not sure of all the context here, but is there some
proposal that /usr will not resolve in GNU? That seems impractical
to me. Virtually everything ever written uses /usr, one way or
another.
There aren't many things that need /usr, most things will figure out
such informa
find / -P -name FOO
What does -P do? I don't see it in the documentation of find
on my machine.
>From (find)Symbolic Links:
`-P'
`find' does not dereference symbolic links at all. This is the
default behaviour. This option must be specified before any of the
file n
What do you think?
I think your patch is correct.
Could you elaborate on the two solutions and how the differ (are
better) than just adding the proper libraries to HURDLIBS? You have
to take care both the header and library implement the same API/ABI.
And the safest way to do that is simply t
there is no harm in keeping it around for now,
Glad to hear it. That wasn't clear to me.
and when the time comes,
I don't think the time will ever come.
Although I can believe that our own packages could be compiled to avoid
/usr without an impossible amount of difficulty, this does
