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 |>|to you? |> |> 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 happened. 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. Ciao, --steffen | |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)