Date: Tue, 02 Apr 2002 22:15:31 -0800 From: Peter Wemm <peter@wemm.org> To: cjclark@alum.mit.edu Cc: Terry Lambert <tlambert2@mindspring.com>, freebsd-current@FreeBSD.ORG, Emiel Kollof <coolvibe@hackerheaven.org> Subject: Re: kldxref problem Message-ID: <20020403061531.B07353808@overcee.wemm.org> In-Reply-To: <20020402215950.H52193@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Crist J. Clark" wrote:
> 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 on
e
> > > > > 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 thi
s
> > 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.
It has worked several times, because I remember it turned up a gcc bug
in the cross compiled gcc binaries. Specifically, if you did a
'make buildworld TARGET_ARCH=alpha', the compiler would generate invalid
code unless you also used -O0. But it did work. I also recall somebody
fixed it again relatively recently.
> 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.
Using buildkernel/installkernel is your biggest mistake. It is no secret
what I think of those two targets.
> > 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?
The patch is better than nothing, but do not include this part:
> 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
It should not be a kill-the-build event if the optional tool fails.
Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
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?20020403061531.B07353808>