[please avoid top-posting on this mailing list(*)] On Mon, Jul 8, 2024 at 2:33 PM Nathan Royce <nroycea+kernel@xxxxxxxxx> wrote: > Well goodness me, seems I spoke too soon. > I found the that zlib was required (looking for "zlib.h"), so I built > that first and that too wasn't all that cross-compile friendly. > I saw "CHOST" is used, and was surprised that it didn't seem to need > anything to link against from the target sysroot, so that turned out > better than I thought it would. > > I then used `configure` prefixed with > the`CFLAGS="--sysroot=<pathToSysroot>"`, along with `HOST_CPU=<tuple>` > for `make`, and it worked out fine. The Git build system determines some aspects of the environment dynamically, so if you were cross-compiling for a different architecture, it is possible that this did not enable every feature of Git. For instance, if you look inside `config.mak.uname` and `Makefile`, you will find a number of invocations of $(shell ...) which pluck some host system information at build time rather than at configuration time. > Before moving it to my device, I just nspawned/chrooted into it and > `git --help` worked. So looks good and easy steps. Of course, it'll > depend on whether or not a git function using zlib also passes (hoping > zlib actually built fine without needing any outside linkage). A successful `git --help` is one small victory. Running the full test suite on the cross-compiled project will give a more complete picture of whether or not the effort was successful. > I'd still suggest and prefer that git (and zlib) follows what others > have settled on doing to be cross-compile-friendly. I can't speak for the zlib project, but for this to happen in Git, someone with an interest in seeing such an outcome will need to submit patches. [*] https://lore.kernel.org/all/YQK0JuI1w1zsEHeC@xxxxxxxxx/
