Date: Tue, 2 Apr 2002 21:59:50 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: Peter Wemm <peter@wemm.org> Cc: Terry Lambert <tlambert2@mindspring.com>, freebsd-current@FreeBSD.ORG, Emiel Kollof <coolvibe@hackerheaven.org> Subject: Re: kldxref problem Message-ID: <20020402215950.H52193@blossom.cjclark.org> In-Reply-To: <20020403004513.BE53D3808@overcee.wemm.org>; from peter@wemm.org on Tue, Apr 02, 2002 at 04:45:13PM -0800 References: <20020401163441.A99214@blossom.cjclark.org> <20020403004513.BE53D3808@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 02, 2002 at 04:45:13PM -0800, Peter Wemm wrote:
> "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.
If it ever worked, without actually digging into the history, I would
guess that it was because it only used existing binaries in the host
environment to run the install. However, now a (somewhat half-baked)
effort is made to use newly built tools to do the install, rather than
the ones already on the host.
But that's somewhat of a digression. 'installkernel' will work in the
cross-platform case. It doesn't try to use build tools, but the tools
in the system.
> kldxref however, does not have any cross capability, and is just a hint
> mechanism even then. It is not essential to run it.
I don't think it is essential either, but it does break module
auto-loading until someone does run it. And this whole thread started
because people don't think the error message is asthetically pleasing.
But to hopefully put an end to some of the idle chatter here, here are
patches to build a working kldxref(8) on 4-STABLE and 5-CURRENT in the
the cross-tool phase. The 'installkernel' of a 5-CURRENT build on
4-STABLE system should not error on kldxref(8).
Yes, it is a kludge. Comments?
Index: src/Makefile.inc1
===================================================================
RCS file: /export/freebsd/ncvs/src/Makefile.inc1,v
retrieving revision 1.246
diff -u -r1.246 Makefile.inc1
--- src/Makefile.inc1 26 Mar 2002 16:05:09 -0000 1.246
+++ src/Makefile.inc1 3 Apr 2002 05:54:54 -0000
@@ -457,7 +457,9 @@
#
installkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
- ${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} install
+ ${CROSSENV} \
+ PATH=${PATH}:${STRICTTMPPATH} \
+ ${MAKE} KERNEL=${INSTKERNNAME} install
reinstallkernel:
cd ${KRNLOBJDIR}/${INSTALLKERNEL}; \
${CROSSENV} ${MAKE} KERNEL=${INSTKERNNAME} reinstall
@@ -619,7 +621,8 @@
cross-tools:
.for _tool in ${_btxld} ${_elf2exe} \
- gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint}
+ gnu/usr.bin/binutils usr.bin/objformat gnu/usr.bin/cc ${_xlint} \
+ usr.sbin/kldxref
cd ${.CURDIR}/${_tool}; \
${MAKE} obj; \
${MAKE} depend; \
Index: src/sys/modules/Makefile
===================================================================
RCS file: /export/freebsd/ncvs/src/sys/modules/Makefile,v
retrieving revision 1.236
diff -u -r1.236 Makefile
--- src/sys/modules/Makefile 21 Mar 2002 09:15:38 -0000 1.236
+++ src/sys/modules/Makefile 3 Apr 2002 01:57:18 -0000
@@ -184,7 +184,7 @@
.if !defined(NO_XREF)
.MAKEFLAGS:= ${.MAKEFLAGS} -DNO_XREF
afterinstall:
- -kldxref ${DESTDIR}${KMODDIR}
+ kldxref ${DESTDIR}${KMODDIR}
.endif
.include <bsd.subdir.mk>
Index: src/usr.sbin/kldxref/Makefile
===================================================================
RCS file: /export/freebsd/ncvs/src/usr.sbin/kldxref/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- src/usr.sbin/kldxref/Makefile 10 Dec 2001 21:13:35 -0000 1.4
+++ src/usr.sbin/kldxref/Makefile 3 Apr 2002 05:05:09 -0000
@@ -5,4 +5,11 @@
WARNS?= 2
MAN= kldxref.8
+.if defined(BOOTSTRAPPING)
+CFLAGS+= -I${.CURDIR}/../../sys -I.
+machine:
+ ln -sf ${.CURDIR}/../../sys/${MACHINE_ARCH}/include machine
+beforedepend: machine
+.endif
+
.include <bsd.prog.mk>
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020402215950.H52193>