Make install failure in -current (several places)
Olaf Seibert
> > > With BUILD=1 and UPDATE=1, a make install from (the equivalent of)
> > > /usr/src gets me:
and it builds the whatis database before it has installed all manpages
(it still hasn't built the compiler at that time, and who knows what
else)...
So basically, the instructions on
http://www.netbsd.org/developers/releng/build-release.html (which I'm
following) are wrong. It seems one needs to do an explicit make build
before make install and/or make release, otherwise things go very
wrong... which is bad because the make install tends to touch all
libraries and therefore re-link everything (somebody has already filed a
pr on that).
I'll try to summarise a complete list of everything that I find, when
this is done (my VAX isn't that fast and it's been building for 2 and a
half days already).
-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhi...@polder.ubc. -- If one tells the truth,
\X/ .kun.nl -- one is sure, sooner or later, to be found out. (Oscar Wilde)
Olaf Seibert
> Ick - that looks way over-complicated at first glance. Perhaps these
I added some stuff on my own, in particular to use some of the newly
built toolchain in the process. This is because the 1.4.1 make is too
old (complaints about some unknown modifier), and cc1 (warnings about
NULL format strings in calls to err()). With the VAX snapshot I'm using
to build that's less of an issue, but I use the same script for alpha
and vax.
> Simon.
Simon Burge
> On Wed 01 Mar 2000 at 12:46:11 +0100, Olaf Seibert wrote:
> > Also, in one of these directories (usr.sbin/ypserv), I didn't get
> > obj.vax symlinks, but I did have obj.alpha symlinks. In both cases I had
> > done a make obj before, but in the alpha case I had done a separate make
> > build before a make install.
>
> ypserv is not included in SUBDIR of usr.sbin/Makefile... and some other
> things that don't exist are.
A week or so ago the usr.sbin/Makefile got a bit trashed for a day or
so. If you've got rev 1.135 of that file you'll have lots of problems.
The wonders of the bleeding edge of -current :-)
Simon.
Olaf Seibert
> Also, in one of these directories (usr.sbin/ypserv), I didn't get
> obj.vax symlinks, but I did have obj.alpha symlinks. In both cases I had
> done a make obj before, but in the alpha case I had done a separate make
> build before a make install.
ypserv is not included in SUBDIR of usr.sbin/Makefile... and some other
things that don't exist are.
-Olaf.
Simon Burge
> On Wed 01 Mar 2000 at 22:17:38 +1100, Simon Burge wrote:
> > I think I missed the start of this thread - from which directory do
> > you run "make release" in? To build pmax releases and snapshots, I do
> > little more than:
>
> I did a Make -k install from /usr/src (well, /vol1/rhialto/sup/root/src,
> but ok) with the Make script as below. The build-release.html page
> suggests I can do a make install directly, but I see that that omits the
> building of internal libraries, header files and helper programs that
> are not to be installed, but are required for building.
Ick - that looks way over-complicated at first glance. Perhaps these
instructions predate a useful "release" target in the top-level
Makefile. I'll check this out closer tomorrow when I have more than a
80x24 terminal on a modem dialup...
Simon.
Simon Burge
> On Tue 29 Feb 2000 at 12:43:19 +0100, Olaf Seibert wrote:
> > > > With BUILD=1 and UPDATE=1, a make install from (the equivalent of)
> > > > /usr/src gets me:
>
> and it builds the whatis database before it has installed all manpages
> (it still hasn't built the compiler at that time, and who knows what
> else)...
>
> So basically, the instructions on
> http://www.netbsd.org/developers/releng/build-release.html (which I'm
> following) are wrong. It seems one needs to do an explicit make build
> before make install and/or make release, otherwise things go very
> wrong... which is bad because the make install tends to touch all
> libraries and therefore re-link everything (somebody has already filed a
> pr on that).
I think I missed the start of this thread - from which directory do
you run "make release" in? To build pmax releases and snapshots, I do
little more than:
setenv DESTDIR /somewhere/destdir
setenv RELEASEDIR /somewhere/releasedir
setenv UPDATE 1
rm -rf $DESTDIR $RELEASEDIR
mkdir $DESTDIR $RELEASEDIR
cd /usr/src
make cleandir
make release
copy $RELEASEDIR to the ftp site.
The "little more" usually involves releases note, testing, etc but what
is in $RELEASEDIR is usually right.
The UPDATE variable will reduce the number of things that get recompiled
and should improve build times no end. Because of UPDATE, you need
the separate "make cleandir" - hmm, maybe we should have two variables
controlling update vs. cleandir behaviour...
Simon.
Olaf Seibert
> you run "make release" in? To build pmax releases and snapshots, I do
> little more than:
I did a Make -k install from /usr/src (well, /vol1/rhialto/sup/root/src,
but ok) with the Make script as below. The build-release.html page
suggests I can do a make install directly, but I see that that omits the
building of internal libraries, header files and helper programs that
are not to be installed, but are required for building.
Examples are audio, amd, uucp, backgammon, ypserv (there are some more,
I left my list at home).
Also, in one of these directories (usr.sbin/ypserv), I didn't get
obj.vax symlinks, but I did have obj.alpha symlinks. In both cases I had
done a make obj before, but in the alpha case I had done a separate make
build before a make install.
For now, I am rerunning a make build (without removing the old results),
since the make install finished now, and never made or installed
$DESTDIR/usr/libexec/cc1 (and who knows what else).
# From http://www.netbsd.org/developers/releng/build-release.html
export MACHINE_ARCH=`uname -m`
# # The location of your source tree.
export BSDSRCDIR=/vol1/rhialto/sup/root/src
# # The location of the object files produced by the build.
export BSDSOBJIR=/vol1/rhialto/obj
# # For the initial build, which doesn't include those crypto
# # files which may not be exported from the US and Canada.
# EXPORTABLE_SYSTEM=1
# # These two aren't really necessary; they just make life
# # easier if/when you rebuild later.
export BUILD=1
export UPDATE=1
#
# # The following variables must be set in the environment;
# # /etc/mk.conf will not do!
#
# # Where the installed files go.
if [ "$DESTDIR" = "" ]
then
export DESTDIR=/vol1/rhialto/destdir.${MACHINE_ARCH}
fi
# # Where the release goes (in release(7) format, of course).
# RELEASEDIR=/usr/home/cjs/netbsd/release
export RELEASEDIR=/vol1/rhialto/release.${MACHINE_ARCH}
make=/usr/bin/make
if [ -x $DESTDIR/$make ]; then
make=$DESTDIR/$make
echo "Using make=$make"
fi
if [ -x $DESTDIR/usr/bin/cc ]; then
export CC=${DESTDIR}/usr/bin/cc
export CXX=${DESTDIR}/usr/bin/c++
echo "Using cc=$CC"
fi
# gcc will simply not use this if it's not there:
# (and it will strip a trailing slash for some weird
# reason - as you can see by running gcc -v -print-search-dirs c.c
export GCC_EXEC_PREFIX=${DESTDIR}/usr/libexec//
#export CFLAGS="$CFLAGS -B$GCC_EXEC_PREFIX"
#export CXXFLAGS="$CXXFLAGS -B$GCC_EXEC_PREFIX"
# Use newly built system libraries:
export LD_LIBRARY_PATH="${DESTDIR}/usr/lib:${LD_LIBRARY_PATH}"
# Use newly built system programs: ??
# export PATH="${DESTDIR}/bin:${DESTDIR}/sbin:${DESTDIR}/usr/bin:${DESTDIR}/usr/sbin:${PATH}"
exec $make -m $BSDSRCDIR/share/mk "$@"
> Simon.
Simon Burge
> > The UPDATE variable will reduce the number of things that get recompiled
> > and should improve build times no end. Because of UPDATE, you need
> > the separate "make cleandir" - hmm, maybe we should have two variables
> > controlling update vs. cleandir behaviour...
>
> I think I am already in the archives as saying that we should.
So far it seems we're in violent agreement on everything :-) I think
I've still got most of the messages you've sent about the build
processes, but can't remember any specifics. I dig back through my
archives.
> What I'd actually like is all the top-level stages of ``make build'' assigned
> their own PHONY targets, and that list exported via ``make print-build-steps'
'
> so that I can write a general system which "walks" through the various parts
> of a ``make build'' in order. I've already got such a system which I use all
> the time, but currently it has to know all about the src/Makefile that it is
> driving. (I loathe make -k, so nobody send me private mail about that please)
>
> With the above implementation, it is quite straightforward to support more
> PHONY targets like ``build'' ``inc-build'' and whatever else we find we use
> a lot.
This sounds reasonable. I'll assume you mean "make -n", not "make -k".
I tend to use that one all the time myself, so maybe we don't agree
about absolutely everything :)
Simon.
Todd Whitesel
> and should improve build times no end. Because of UPDATE, you need
> the separate "make cleandir" - hmm, maybe we should have two variables
> controlling update vs. cleandir behaviour...
I think I am already in the archives as saying that we should.
What I'd actually like is all the top-level stages of ``make build'' assigned
their own PHONY targets, and that list exported via ``make print-build-steps''
so that I can write a general system which "walks" through the various parts
of a ``make build'' in order. I've already got such a system which I use all
the time, but currently it has to know all about the src/Makefile that it is
driving. (I loathe make -k, so nobody send me private mail about that please)
With the above implementation, it is quite straightforward to support more
PHONY targets like ``build'' ``inc-build'' and whatever else we find we use
a lot.
Todd Whitesel
toddpw @ best.com
Laine Stump
>Not a VAX snapshot ;-) (nor Alpha).
Ah yes. Forgive my unintentional i386 bigotry. I'll try to be more
observant in the future ;-)
Olaf Seibert
> Even better yet, just install the latest binary snapshot, *then* start
> tracking -current. That's *much* easier than attempting to bootstrap from a
> significantly older version using only sources. And since a kind soul
> placed a new snapshot on the ftp site only 4 days ago, now is the perfect
> time to do it.
Not a VAX snapshot ;-) (nor Alpha).
And I'm trying to get a grip on the procedures involved, so it's not
really all too bad.
I must say that from 1.4.1 to -current (well a week ago now) on the
Alpha was pretty painless with Make build install. Not that I already
tried the resulting binaries, but it all looks ok ;-) There was some
feature skew with cc1 and make but not too bad. I suppose it helps that
the Alpha already is ELF ;-)
And on the VAX I use the snapshot from november and that didn't even the
aforementioned version skew so if I had just done the same as on the
Alpha it would have gone right the first time. But I thought to save a
step because the VAX is so much slower (it's been busy for 3 days now on
what the Alpha took only several hours).