"Crist J. Clark" wrote:
> On Mon, Apr 01, 2002 at 03:07:46PM -0800, Terry Lambert wrote:
> > "Crist J. Clark" wrote:
> > > This whole argument ignores what the real problem is. The really
> > > correct way to handle this is to use the kldxref(8) built in the
> > > 'buildworld' phase. (It's bad form to be using any executables from
> > > the base system if we have a full object tree.) Actually using the one
> > > in /usr/obj/usr/src/usr.sbin/kldxref seems pretty ugly. The better
> > > thing to do is to have a version in /usr/obj/usr/src/<arch>/usr/sbin
> > > by making it a crosstool. The failure should not be ignored in this
> > > case.
> > 
> > Uh, that doesn't work incredibly well when the machine you
> > are on is an x86, and the machine that the buildworld targets
> > is, say, the Alpha.
> > 
> > This came up in the first place because it's a cross-envrionment
> > issue that needs resolving.  The "workaround" exists because the
> > workaround cops out on the cross-environment part of the process
> > and spits out the warnming, instead.
> An 'installworld' doesn't even come close to working in a cross
> environment for a whole variety of reasons, so I don't see the
> relevance.

It used to.  If it no longer works, it should be fixed.  I partially do this
for cross-architecture builds quite often where the target system is NFS
mounted somewhere.

kldxref however, does not have any cross capability, and is just a hint
mechanism even then.  It is not essential to run it.

> The situation this question comes up is typically 5-CURRENT builds on
> 4-STABLE systems, not in cross-archetecture builds.

That is a different set of problems.  cross-version builds have always been
very trouble-prone.  same-version cross builds are far less of a problem.

"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to