alex_giusi_tiri has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 244 seconds]
worldofpeace has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
alex_giusi_tiri has joined #nixos-aarch64
orivej has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
jackdk_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
ekleog has quit [Quit: back soon]
jackdk_ has quit [Remote host closed the connection]
ekleog has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 258 seconds]
<exarkun1>
The project has an aarch64 builder available to it, right? And it can also do native builds for armv7l? Is that right? If so, I wonder what goes into a configuration like that.
<sphalerite>
exarkun1: it can, but with major caveats
<samueldr>
so, at a glance, anything "Cortex-*" is probably fine with AArch32; while anything third-party-designed I can't find a good list of "yes" or "no"
<exarkun1>
seems like at the very least it's getting the wrong image.
<gchristensen>
nixos-in
<gchristensen>
nixos-in-place fetching an i686 image to an arm host is interesting to start with
alex_giusi_tiri has quit [Ping timeout: 246 seconds]
<sphalerite>
"it's not amd64, it must be x86!"
<sphalerite>
firefox-bin used to do that too
<exarkun1>
shoulda picked a bigger instance type. up to building a cross-compiling gcc...
alex_giusi_tiri has joined #nixos-aarch64
<gchristensen>
ouch
<sphalerite>
exarkun1: huh, the cross gcc should be in the cache
<sphalerite>
exarkun1: but yeah, looks like it's not. Maybe this is a recent change
<sphalerite>
or hydra hasn't caught up yes
THFKA4 has quit [Quit: WeeChat 2.3]
THFKA4 has joined #nixos-aarch64
THFKA4 has quit [Changing host]
THFKA4 has joined #nixos-aarch64
<exarkun1>
Hello, world!
<gchristensen>
hello!
<exarkun1>
So it seems AWS EC2 a.* instances can run armv7l-hf-multiplatform binaries.
<exarkun1>
Thus ... a native armv7l toolchain can be used to build armv7l binaries on that platform?
<exarkun1>
So maybe asking for native builds and indicating with extra-platforms that the system is capable of such native builds will work
<gchristensen>
I think the complication is the kernel can't restrict a system to armv7l like an x8664 machine can restrict to x86
<samueldr>
>> Caveat: many packages close to the roots of various dependency trees (e.g. openssl) will attempt to autodetect the build platform based on uname (which still returns aarch64) and fail as a result.
<exarkun1>
gchristensen: So you might accidentally get some aarch64 in there without noticing (until later)?
<gchristensen>
yeah I think so?
<gchristensen>
sphalerite, samueldr know better
<exarkun1>
and what samueldr said
<samueldr>
exarkun1: you'd have to *somehow* boot it all as AArch32 or you could use qemu kvm
<sphalerite>
exarkun1: no, not really without noticing. Builds will fail :)
<samueldr>
there's *some* cost to kvm aarch32, but it's really not bad, close to native perfs, main issue is limited amount of ram (by default) and limited amount of cores supported
<samueldr>
limited amount of ram is that the kernel needs to be built with LPAE (iirc) for aarch32, which is a feature I'm not sure all cortex-a* 32 bit flavours support; and if it's not supported it won't boot (so we can't just add it to our defaults)
<samueldr>
(limited being around 2.3GB)
<exarkun1>
samueldr: I think there must be several aspects of this whole process of which I am entirely ignorant.