"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. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "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
