hi,
On Sat, Aug 18, 2001 at 12:49:58AM -0500, pac@xxxxxxxxxxxxxx wrote:
> > what problem was that exactly? if I remember correctly,
> > the "solution" above was just a change to the diagnostic
> > reported by the xfsdump configure script... suggesting
> > a "make install-dev" in xfsprogs so that xfsdump is then
> > built against current XFS headers.
>
> I finally got it, after several make install-dev, ldconfig's, and
> make install's..
There's documentation in the cmd/*/doc/{INSTALL,PORTING}
files about building the user tools, but it sounds like
you've figured it all out now, so its a bit late for that
suggestion perhaps.
> Of course i'm using a 2.4.4 version which may be
> part of the problem.
The 2.4.x kernel version has no influence on the userspace
build.
> Any chance the libs can be search locally
> instead of systemwide?
That introduces some subtle inter-package build dependency
issues if we continue to keep xfsdump as a separate package
- they could be solved by folding the xfsdump code into
xfsprogs, but that introduces its own, different set of
issues.
So, the status quo is unlikely to change. The current
build scheme is the best of a set of imperfect options -
there is no silver bullet here.
> Otherwise you have to toggle between
> user and root make's, or am i missing something?
That is correct if you're installing to "/" (or anywhere
else requiring root permission to write to, obviously).
This is no different to how the ext2 "dump" package gets
built though, as an example.
It is possible to build everything as an ordinary user
using a chroot'ed build environment, but that can be a
bit of a pain to setup.
cheers.
--
Nathan
|