Date: Fri, 19 Sep 1997 16:26:42 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: gurney_j@resnet.uoregon.edu Cc: tlambert@primenet.com, dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: Yet Another bug in src/Makefile Message-ID: <199709191626.JAA10533@usr07.primenet.com> In-Reply-To: <19970918222829.18729@hydrogen.nike.efn.org> from "John-Mark Gurney" at Sep 18, 97 10:28:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > This is false. The build for libkvm references outside the source tree
> > (specifically, an absolute reference via -I). This was why I hacked
> > the symbolic links for multiple kernel tree builds (earlier posting).
>
> are you sure... my tree reads:
> LIB= kvm
> CFLAGS+=-DLIBC_SCCS -I${.CURDIR}/../../sys
>
> last I checked, this isn't out of the src tree...
Consider:
# rm /sys
# ln -s /sys /usr/src/sys
# mv /usr/src /usr/src-release
# mkdir /usr/src
# cd /usr/src-release
# sh
# for i in *
> do
> ln -s /usr/src-release/$i /usr/src/$i
> done
# exit
# cd /usr/src
# rm sys
# ln -s /b/src-current/sys sys
Now build libkvm.
Note that "-I${.CURDIR}/../../sys" refers to the directory:
/usr/src-release/sys
And not the correct directory:
/b/src-current/sys
...in other words, the libkvm is always built relative to the location
of the libkvm source files, rather than the location of the build source
files.
Changing "-I${.CURDIR}/../../sys" to "-I/sys" fixes this problem, but
in a sort of not very bright way. It resolves the local build issues,
but not the architecture variant issues.
Before you jump in here, note that I do not *want* multiple copies
of the libkvm sources; I want to apply the same libkvm sources to
build from seperate sets of header files. The only reason I need
to do this is because of the idiotic historical precedent of using
/dev/kmem as if it were a valid interface mechanism (it's not).
You have dealt with the "cross build world in a completely seperate
source tree" issue. This is not an issue I'm interested in having
dealt with: I'm not interested in maintaining multiple completely
seperate source trees with mostly identical code. The only good
reason for encouraging *that* arrangement would be if I were a disk
manufacturer.
My cross build issues are typically faced in an NFS mounted source
tree on another architecture, in any case, since the GNU tools are
very poorly acquanted with the idea of cross-build environments.
Witness the use of internal cpp instead of external cpp for
preprocessing, and witness the hard-coded strings like "-Di386",
"-Acpu(i386)", and "-Amachine(i386)" in the external cpp. Also the
lack of a unified "cc" front-end that accepts seperate targets on
the basis of processor rather than processor and architecture (ie:
the old NCR "-target" option vs. the GCC "-b <processor><os>").
Witness also the compiled in "-D__FreeBSD__=3" and "-Asystem(FreeBSD)";
the first makes it impossible to cross build a version 3 FreeBSD on a
version 2 FreeBSD system, mostly because of if_de.c's used of __FreeBSD__
version testing. Both make it difficult to build Net/OpenBSD on a
FreeBSD box, without an entire duplication of GNU tools for the
"different" target -- which differs only in these values.
Furthermore, the version identification crap being compiled in means
that for cross-support of older FreeBSD systems, I either have to
hack up the default Makefiles to undefine the intrinsics and redefine
them to the proper values for the target, or I must run the most
recent version on my buuld machine. This means I can use my fastest
machine for a stable platform, or I can use it for -current, but I
can't use it to build -current if I use it for a stable platform.
> > There are other builds which also reference out of the build tree;
> > anything which references <sys/*> or <machine/*>, in particular,
> > references /usr/include. A reference to <machine/*> can't be
>
> can you show me these mythical references to /usr/include?? I reciently
> committed a bunch of changes to fix improper use of -I/sys...
This does nothing for "#include <machine/endian.h>", for example, since
there is not a "machine" subdirectory of "/sys". Or of the source
tree dependent and symbolic link ignorant version, "${.CURDIR}/../../sys".
Try the following:
# cd /usr/include/sys
# grep "#include <machine/" *
If it comes back with nothing, then you have made your point. If it
comes back with something, I have made mine.
> > resolved without /usr/include/ since it refers to the postinstalled
> > headers from /usr/src/sys/i386/include/ into /usr/include/machine/.
> > The <net*/*>, <arpa/*>, <*fs/*>, <rpc*/*>, and <vm/*> references are
> > all in this boat, as well as others from package/base installation
> > (<tcl/*>, etc.), if installed.
>
> ok.. then why does my build tree
> /usr/obj/a/home/johng/FreeBSD-checkout/current/src/tmp/usr/include,
> include ALL of the things you listed above??
Because you foolishly waste time rebuilding the entire world, instead
of just the pieces impacted by the kernel changes you are currently
working on?
The fact that you have a temporary copy of an include directory is
an indicator that not all is right with the world.
You may have resolved the cross-build issues locally, but you have
not resolved the local modification build issues at the same time.
Part of this is resolvable with:
# cd /usr/include
# rm -rf machine
# ln -s /sys/i386/include machine
# rm -rf sys
# ln -s /sys/sys sys
...which presumes that you put the symbolic links in /usr/src back
to /usr/src/release before building non-kernel pieces.
But this can't resolve the /usr/include/vm stuff, for example, because
/sys/vm is unsuitable for linking, containing, as it does, C sources
as well as header files.
Most of the net code is the same. The rpc headers are generated, and
provide other, colorful versioning issues that need to be dealt with.
The FS headers are another issue, since they are used in the mount code,
and included from an installed location instead of a source location.
They, too, are unsuitable for linking.
Etc..
Even the "ln -s /sys/i386/include machine" link is not very satisfactory
because of the architectural dependence it engenders. In order to have
a working cross environment, you have to toggle the "i386" piece on a
case-by-case-basis.
At best, I can have an enviroment toggling function which resets a large
number of links, and does not properly address issues of kernel changes
to much of the network code, and exposes the vm C sources in an
undesirable way.
> > > of course there is good argument that the installed to area should
> > > be clean to prevent old files from contaminating a setup... but
> > > if we start to clean out /usr/include, we should also do /{bin,sbin}
> > > /usr/{bin,share,sbin,lib,libexec} and any others that get installed...
> >
> > The argument is that the installed area should never be used for
> > system build, since you may be building a cross-environment.
>
> umm... this isn't the case Terry... when was the last time you built
> world on a -current machine w/o your local patches??
I don't build world. That's one of my points, isn't it? If I am hacking
the proc struct, I don't *need* to rebuild the world. Nor should I be
required to do so in order to hack the proc struct. I should only be
required to rebuild those things (and *ONLY* those things) which are
affected by changes to the proc struct.
Waiting (at best case) several hours to see if changes are correct
is a *HUGE* bottleneck, and not one I'm willing to accept!
> > You either need to build the machine link as part of the build, or you
> > need variant symlinks (whole other kettle of fish) to deal with the
> > architecture variant headers for cross-builds.
>
> see above... it's already happened...
As I said above. You have dealt with the "cross build world in a
completely seperate source tree" issue. This is not a very globally
useful issue; at least it is not very useful for me.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709191626.JAA10533>