<Ericson2314>
oh i guess that was something from yesterday
<Ericson2314>
is someone working on freebsd cross?
<qyliss>
I can summarise and save you all the logs reading
<Ericson2314>
or just native impure?
<qyliss>
I was working on native impure
<qyliss>
(although I'd be interesting in expanding to native pure once we get it working a bit more)
<qyliss>
I merged the native impure PR the other day, and also fixed Nix so that it can actually build
<Ericson2314>
qyliss: oh nice!
<qyliss>
but the problem I have encountered is going to cause us problems for FreeBSD in all forms
<Ericson2314>
oh it was red but manual merge
<qyliss>
yeah
<qyliss>
I wish GitHub would recognise a Merges: trailer or something
<qyliss>
specifically, Nixpkgs produces the triple x86_64-unknown-freebsd
<qyliss>
but the canonical one is e.g. x86_64-unknown-freebsd12.2
<qyliss>
because the ABI changes between versions
<Ericson2314>
qyliss: oh we had a hack in in there for darwin or something else like that
<qyliss>
oh really?
<qyliss>
I couldn't figure out how we could possibly make this work without either making builtins.currentSystem include the ABI version, or readFile-ing /etc/os-release
<qyliss>
(tbh I feel that builtins.currentSystem should include the ABI version on FreeBSD, although maybe there's a good reason for it not to I haven't thought of)
<Ericson2314>
eh i don't see why it shouldn't
<Ericson2314>
I am looking for the version hack
<qyliss>
me neither, but Nix deliberately removes anything that looks like an ABI version so I figured there must be some motivation
<qyliss>
how does ABI versioning work on Darwin? Is it backwards-compatible?
<Ericson2314>
i don't really know
<qyliss>
the only real problem I have with the ABI version in currentSystem idea is that I'd need to get it past Eelco
<qyliss>
whereas in Nixpkgs I suspect we can do whatever we want for FreeBSD and nobody will care
<qyliss>
is it just a pragmatic choice, because Mac minis don't grow on trees as you say?
<Ericson2314>
i guess so
<Ericson2314>
or just having a number made other things more difficult
<Ericson2314>
as darwin predates all the lib platform stuff
<qyliss>
I guess the alternative would be that we just try to force ahead with an unusual ABI-less FreeBSD triple
<qyliss>
because I guess the only reason this is really such a big issue for me right now is that I'm using the system compiler rather than a Nix-built one
<Ericson2314>
well, I think it would be nice to do the "right thing"
<Ericson2314>
whatever that is
<Ericson2314>
for FreeBSD
<qyliss>
yeah
<Ericson2314>
Darwin is rather more encumbered and a pain to keep up with whatever Apple's latest whim is in any event
<qyliss>
my instinct here that is that the right thing is to use the same triple that FreeBSD itself uses
<qyliss>
it would be nice to hear from one of the FreeBSD experts in the channel on that point
<Ericson2314>
sounds good to me
<qyliss>
Ericson2314: I wonder why it strips the GNU ABI version though
<Ericson2314>
in any event, I think matching their tools to a fault will keep them happier
<qyliss>
consistency? pragmatism again?
<Ericson2314>
qyliss: in parse.nix?
<qyliss>
no, in the autoconf I linked
<qyliss>
it gives gnu0.3 as an example of something that should be stripped, in the comment
<Ericson2314>
oh checking
<Ericson2314>
ohhh
<Ericson2314>
I bet the thought with the configure.ac was "well, the exact OS version might be different at runtime"
<Ericson2314>
and I think there is a good argument for that
<qyliss>
ahh
<qyliss>
yes that's true
<Ericson2314>
I might continue to do that, but then have `builtin.currentSystem` to the right impurity at run time
<Ericson2314>
anywhere where the ABI is stable enough
<qyliss>
can you expand on what you mean by that?
<Ericson2314>
and I am pretty sure with FreeBSD it is stable enough for old binaries to continue to work, even if with macOS it might not be
<qyliss>
that didn't parse for me and i'm a bit tired-
<qyliss>
oh wait I understand I think
<qyliss>
you're saying that because rebuilding everything on upgrade is not SOP on FreeBSD, we should not include ABI version at configure time?
<Ericson2314>
build time: freebsd -> run time: freebsd14 or whatever
<qyliss>
yeah
<Ericson2314>
qyliss: not sure what SOP is, but yeah :)
<qyliss>
standard operating proceduce
<Ericson2314>
ah
<qyliss>
hmm, that's a trickier change in Nix but I could probably work it out
<qyliss>
we could expand that to Darwin too for correctness, and then strip it off again in Nixpkgs so as not to upset anything
<qyliss>
but at that point that's definitely me fantasizing about what I'll be able to get into Nix
<thefloweringash>
if I run `pkg info pkg`, I see an explicit abi in the package architecture: "Architecture : FreeBSD:12:amd64"
<_0mp>
yes, packages have to be upgraded on major updates, e.g., 12.2->13.0
<_0mp>
also, FreeBSD community does its best to guarantee that you can use the same packages when doing an upgrade within a major release, e.g., 12.2->12.3
<_0mp>
(we had a couple of problems though with that for some packages with kernel modules: we didn't have enough testing put in place to detect a change in ABI between 12.1->12.2)
<qyliss>
okay, thank you for the explanation
<qyliss>
I think it's all or nothing for us, since building for FreeBSD 12.2 with an x86_64-unknown-freebsd12 triple would be just as non-standard as building with x86_64-unknown-freebsd
<qyliss>
so that still sounds like using x86_64-unknown-freebsd12.2 would be the way to go
<_0mp>
I believe you should go for x86_64-unknown-freebsd12 and expect freebsd not to break its promises
bapt has joined #freebsd-nix
<bapt>
I heard some people here have question about the ABI ?
<_0mp>
\o/ thanks bapt, I'm happy that my call for help was heard :D
<bapt>
ABI is stable within a major branch: backward compatible
<bapt>
the only exception is kernel modules, which is the same issue as on linux so
<bapt>
regarding major version is is quite stable as well as long as you don't drop the COMPAT${N-X} option from the kernel
<bapt>
meaning a binary built on freebsd 10 runs perfectly on freebsd 13
<bapt>
and COMPAT${N-X} option are in by default
<bapt>
so my take is it should be x86_64-unknown-freebsd12
<qyliss>
okay, thank you
<_0mp>
:)))
<qyliss>
that causes us a bit of pain, because it means if we bootstrap from FreeBSD's binaries, things will think they're cross-compiling
<qyliss>
(because FreeBSD's compiler is x86_64-unknown-freebsd12.2
<qyliss>
)
<bapt>
ah ;)
<qyliss>
but if there's a good reason to go for 12 anyway, we can probably work with it
<qyliss>
Why does the FreeBSD compiler use 12.2 and not 12?
<qyliss>
Because of kernel modules?
<bapt>
history
<qyliss>
okay
<qyliss>
and you don't think it would be a problem for us to break with that history?
<bapt>
but the fact it is name 12.2 does not make a huge difference does it ?
<qyliss>
it does, because we if pass -target x86_64-unknown-freebsd12 things will think they're cross-compiling
<qyliss>
and then C++ breaks
<qyliss>
to work around that we will probably have to build a C++ compiler earlier in the bootstrap process, and just hack around that issue for building our own compiler itself
<bapt>
why does C++ breaks ?
<qyliss>
Unsure, but I'm guessing it's because it sees that the FreeBSD libc++ is for a different ABI version
<bapt>
this is weird
<bapt>
in the freebsd ports tree we have a mechanism to build with an external toolchain where the target is x86_64-unknown-freebsd12 and it works just fine
<bapt>
including with C++
<bapt>
I did that part (long ago) so if I see the errors I can probably give hints
<qyliss>
I don't have the time to try it out again right now but can post the errors later
<bapt>
sure
<bapt>
I ll try to stick here for a while ;)
<_0mp>
fantastic! thanks, bapt
<Mic92>
What is the current recommendations for CI for freebsd, when it comes to integration into nixpkgs?
<Mic92>
I don't think we have funding for machines for this right now, but maybe in future.
<bapt>
cirrus-ci works great
<bapt>
you can run on any image available on gcp with cirrus-ci