NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: toolchain/58089: MKREPRO isn't really reproductible



    Date:        Fri, 29 Mar 2024 13:23:29 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20240329132330.E0F6F84D35%mail.netbsd.org@localhost>

  | I have no idea what BUILD=yes does, and it doesn't seem to be
  | documented in share/mk/bsd.README

It is there in the version I have installed (which came from a 9.99.97
build, almost 2 years ago, so isn't necessarily up to date)

BUILD           If defined, 'make install' checks that the targets in the
                source directories are up-to-date and remakes them if they
                are out of date, instead of blindly trying to install
                out of date or non-existent targets.

I assume that the point of that is (or perhaps once was) so that it is
possible to stick BUILD=yes (or BUILD=anything) in mk.conf and then simply
do "make install" in any random source directory.

I cannot imagine that that is relevant at all to users of build.sh
which never (as best I can tell anyway) blindly does "make install"
without actually building first (or not that I have ever seen happen,
and I never set BUILD to anything).

While I'm here, I cannot fathom why anyone trying to make a reproducible
build would ever set MAKECONF to anything other than MAKECONF=/dev/null
I do all builds that way, random settings in mk.conf (any random mk.conf)
are rarely conducive to productive builds.   Any build variations I need
go on the command line, not there.   A reproducible build should have none.

  | (but it is _listed_ there and in
  | BUILDING.mdoc), but -V MKDEBUG=yes is probably the difference.

Something related to DEBUG probably is, but it most likely is not exactly
that.   Manuel's build did not include that option, and yet the difference
he showed had some debug related info in the netbsd kernel he built, which
was not there in the downloaded version (not a lot apparently, as the kernel
he ended up with was a whole 96 bytes bigger (file size, the loadable segments
were the same size) than the one he downloaded.

Manuel, check your mk.conf (or build without using it as above) and see
if there's anything there - also check that you had no .o files in the
kernel obj directory from some earlier build, which may have had MKDEBUG
set.

kre




Home | Main Index | Thread Index | Old Index