Simon McVittie <s...@debian.org> wrote:
|On Thu, 01 Mar 2018 at 19:49:13 +0100, Steffen Nurpmeso wrote:
|> Simon McVittie <s...@debian.org> wrote:
|>|Why is the kernel version on the machine where s-nail was compiled useful
|> This is indeed correct, and i have changed $OSENV to go for
|> uname(1) -sm instead of -srm.
|Continuing that thought, why are the architecture and kernel of the
|machine where s-nail was compiled interesting to you? If you cross-compile
|s-nail on a Linux x86_64 machine, using a cross-compiler that produces
|FreeBSD ARM binaries, I don't think "Linux x86_64" is a particularly
|interesting fact about those binaries - particularly if you're debugging
|something that only happens on the FreeBSD ARM machine!
|Even if cross-compiling doesn't work for this particular package,
|`uname -m` doesn't always return the same thing on compatible machines:
|on at least 32-bit x86 and 32-bit ARM it can have several different
|values (that are merely facts about the machine where it was compiled,
|and aren't really anything to do with the machine on which it's running
|and maybe demonstrating bugs that you want to solve).
I think it is pretty common to include a build target in a binary.
If you cross-compile you can set OS or OSENV, or place an uname(1)
first in path. Ok, i think the uname utility will be made
hookable like all the others except echo(1) and printf(1). Ok.
But despite that and the possibly correct observation that placing
just about any environmental info in any non-system-dependent
object you can close the issue that is my rant, but will not get
away from the fact that you cannot expect exactly identical binary
outcome on two different build hosts, unless the actual build
environment is the same to the detail. What if the cross-compiler
that has been used had a known code generation bug, noone will
know unless the reporter knows that cross-compilation has
In the OSS world you can be very lucky if bugs become reported at
all, it seems to me most people try and on failure they just turn
away to get the job done. Rare exceptions are only super crucial
things like SSH and maybe bash or so, the top 100 maybe, all
others live in the darkness. But especially non-GUI applications.
Really. Think about it. Even the number one console MUA mutt(1)
had a terrible S/MIME bug (local certificates were deleted!), but
it took _many months_ unless that was reported. That is, for my
stuff, i want all the information i can have with the very first
bug report message, because i am lucky for any report at all!
And i will not give that up because Debian reproducibility
introduces restraints which are nice for some fancy automated
report mast..bation. You know, OSS in the normal world has no
lobby, the others have even more such.
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)