Rick Hull (Jan 21 2026 at 03:53): Rick Hull (Jan 21 2026 at 03:53):@Luke Boswell is it possible that build.zig is misconfigured for a native build? this is a very shaky area for me, but I tried a native build, and there were some glibc symbols going into a musl build, which:
roc test/host.roc
ld.lld: error: undefined symbol: __vfprintf_chk
>>> referenced by secp256k1.c
>>> .zig-cache/o/68a5a1526d4b3cedd8deaf08a3d7878c/secp256k1.o:(fprintf(_IO_FILE*, char const* pass_object_size1, ...)) in archive test/../platform/targets/x64musl/libhost.a
-- LINKER FAILED ---------------------------------
The linker failed while building for target x64musl
Error: LinkFailed
error: Recipe `test-integration` failed on line 269 with exit code 1
it may just be my build.zig, not sure yet
Rick Hull (Jan 21 2026 at 03:55):Codex says:
You’ve got it — the “native” build is faster, but in this project “native” needs to mean “native Roc target,” not “host libc.” On Linux, Roc’s native target is x64musl, while Zig’s default native target is typically glibc. So the current zig build native produces a glibc-flavored libhost.a and then copies it into the x64musl slot, which looks “right” but is actually wrong.
How the two builds differ today:
- zig build (what build-all uses) builds each Roc target explicitly via roc_target.toZigTarget(), so x64musl is truly musl.
- zig build native uses the host target, which is glibc on most Linux distros, and then copies to the Roc target directory. That mismatch is the subtle bug.
Your expectation is totally reasonable; the “native build” just isn’t configured to match the Roc target definition.
If you want, I can fix native in build.zig to use detectNativeRocTarget(...) → toZigTarget() instead of standardTargetOptions(). That keeps the fast build but produces the correct musl target on Linux.
Rick Hull (Jan 21 2026 at 03:57):this might be an artifact of my inclusion of libsecp256k1; anyhow it's resolved
Luke Boswell (Jan 21 2026 at 06:15):Rick Hull said:
this might be an artifact of my inclusion of
libsecp256k1; anyhow it's resolved
At first glance I would guess it was related to this.
What was the issue in the end?
Rick Hull (Jan 21 2026 at 13:56):diff --git a/build.zig b/build.zig
index bccf6f4..c5462eb 100644
--- a/build.zig
+++ b/build.zig
@@ -99,13 +99,14 @@ pub fn build(b: *std.Build) void {
const native_target = b.standardTargetOptions(.{});
- // Detect native RocTarget and copy to proper targets folder
+ // Detect native RocTarget based on host, then build using that Roc target.
const native_roc_target = detectNativeRocTarget(native_target.result) orelse {
std.debug.print("Unsupported native platform\n", .{});
return;
};
- const native_lib = buildHostLib(b, native_target, optimize, builtins_module, secp256k1_dep);
+ const native_roc_zig_target = b.resolveTargetQuery(native_roc_target.toZigTarget());
+ const native_lib = buildHostLib(b, native_roc_zig_target, optimize, builtins_module, secp256k1_dep);
b.installArtifact(native_lib);
const copy_native = b.addUpdateSourceFiles();
I am about to publish my nostr-platform repo on github. I think it's feature complete for building the rest of nostr in Roc. But I think I need to rename it. There is nothing in the platform specific to nostr -- it's roc-platform-template-zig, using Zig's sha256, plus libsecp256k1. Any suggestions for repo name?
Rick Hull (Jan 21 2026 at 13:58):I have 3 functions from libsecp: create public key, sign a msg/hash, verify a signature. These are all strictly related to "Schnorr Signatures", which are used in Bitcoin (primarily) and later adopted by Nostr Protocol
Rick Hull (Jan 21 2026 at 14:03):libsecp256k1 does WAY MORE than Schnorr, and Schnorr is a small optional module. So i am going to to avoid the big mouthful and likely base on schnorr. roc-platform-schnorr or schnorr-platform
Anton (Jan 21 2026 at 14:14):schnorr-platform sounds good
Rick Hull (Jan 21 2026 at 16:01):for day to day development, is there any reason to build all targets vs just the native target? i assume this is for release rather than dev
Anton (Jan 21 2026 at 16:06):Yes, the new basic-cli script allows you to choose: https://github.com/roc-lang/basic-cli/blob/03e94adde676e495d7a80c89b5b54de7ed17af61/build.sh#L87
Rick Hull (Jan 21 2026 at 16:08):is there any good reason to build all for edit-build-test cycles?
Anton (Jan 21 2026 at 16:14):Not that I can think of
Rick Hull (Jan 22 2026 at 18:38):For "hello world" to work with the new compiler, a new user needs a "new compiler" platform. this will be basic-cli by default, when it's ready. but is roc-platform-template-zig the next best alternative? for a new user wanting hello world?
Luke Boswell (Jan 22 2026 at 20:16):Yes for now the template or possibly something like roc-ray which both have releases.
Luke Boswell (Jan 22 2026 at 20:17):The basic-cli branch works well enough but you do need to build the platform from source so not as friendly.
Luke Boswell (Jan 22 2026 at 20:24):@Rick Hull what OS are you running? I could make probably make a an alpha release with just the binary for your system. I could probably add http too if you are wanting to experiment with it.
Rick Hull (Jan 22 2026 at 20:49):this isn't for me, really, but I'm running Arch Linux. so, step 1 of "hello world" is first, get a working platform with Stdout. and a binary seems good for that.
Rick Hull (Jan 22 2026 at 23:12):referencing some other platform discussion in other channels... what is the future of roc-platform-template-zig ? I can imagine that basic-cli might be a better starting point for my schnorr-platform (not really, just hypothetically). leaving aside Rust vs Zig (I much prefer Zig, in my naivete)
Rick Hull (Jan 22 2026 at 23:13):perhaps it becomes basic-cli-zig? or halfway there?
Luke Boswell (Jan 22 2026 at 23:13):The future plan is to not change it... it's done
Rick Hull (Jan 22 2026 at 23:13):ah, nice. I can agree with that
Luke Boswell (Jan 22 2026 at 23:14):Unless the roc <-> host boundary changes... I don't plan to change anything. It's a minimal platform template that shows just enough functionality for people to see how to build a platform. I aim to have the identical platform API for all the templates, Rust, Swift, C, Go, Zig, etc...
Rick Hull (Jan 22 2026 at 23:15):if there were a hypothetical basic-cli-zig would you recommend someone wrapping an importantly-host-only library start with roc-platform-template-zig or basic-cli-zig ?
Rick Hull (Jan 22 2026 at 23:15):or is there a better question lurking in here?
Luke Boswell (Jan 22 2026 at 23:15):I don't really understand the question. What is a hypothetical basic-cli-zig... is that the basic-cli API but with a zig host?
Rick Hull (Jan 22 2026 at 23:16):yes, let me rephrase. use basic-cli as a starting point, or roc-platform-template-rust ?
Luke Boswell (Jan 22 2026 at 23:17):What are you wanting to achieve? keep in mind the crypto primitive should be implemented in Roc's builtins so you could use any platform
Rick Hull (Jan 22 2026 at 23:17):I recognize that this might be a poorly conceived question. feel free to answer any related question ;)
Luke Boswell (Jan 22 2026 at 23:18):I thought your schnorr-platform was a learning experiment to learn more about roc, not necessarily something you plan to publish releases for and support long term
Luke Boswell (Jan 22 2026 at 23:19):Can you share a link to your platform? I wonder if you might want to implement it as a package instead?
Luke Boswell (Jan 22 2026 at 23:20):If we assume the crypto primitives are in the builtins (we can simulate that by putting that in a forked platform for now) -- you would explore options to build a higher level abstraction on top of that
Rick Hull (Jan 22 2026 at 23:20):this is getting too specific to me. my question is more general, about future stuff and new developers coming here with questions. forget crypto. pick a good example of something that belongs in the host. maybe a fresh new arena allocator. I've got this thing, and I want to expose it to Roc via a platform. the platform templates are a great resource and a minimal way to get started. basic-cli is very comprehensive and provides many modules that might never get used by any given application. I guess to answer my question, I would start with the smallest thing that could possibly work.
Luke Boswell (Jan 22 2026 at 23:21):Ahk ... so generally I would suggest forking something like basic-cli if you needed all the functionality and wanted the same API (just adding a little more).
Rick Hull (Jan 22 2026 at 23:22):I might tell someone: start with roc-platform-template-rust, which gives you basic I/O and memory mgmt. add your host feature, and then start developing roc against your platform. if you find that you need more platform features, you can base your host feature on basic-cli instead.
Luke Boswell (Jan 22 2026 at 23:22):If you are wanting to build a new platform I would say start with a template so you can see just the parts you need more easily
Rick Hull (Jan 22 2026 at 23:23):also, good question about learning vs supporting for the long term. that schnorr-platform is so tiny, porque no los dos? I plan to implement nostr in roc (already done it in ruby)
Rick Hull (Jan 22 2026 at 23:24):If you have any interest in implementing Schnorr achieving a Schnorr impl in Roc, I have a line-by-line impl in Ruby that matches the spec nearly 1-1. But this type of impl gives up some timing guarantees, etc. I don't mean that you, Luke, undertake this. but there are reasons not to.
Luke Boswell (Jan 22 2026 at 23:26):Is schnorr implemented in this? https://ziglang.org/documentation/master/std/#std.crypto
Rick Hull (Jan 22 2026 at 23:26):I can take a peek :spectacles:
Rick Hull (Jan 22 2026 at 23:27):huzzah! https://ziglang.org/documentation/master/std/#std.crypto.pcurves.secp256k1.Secp256k1
schnorr is an optional module, almost certainly implemented
Rick Hull (Jan 22 2026 at 23:27):if it is not a port or wrapper around libsecp256k1 it may be less desirable nonetheless
Rick Hull (Jan 22 2026 at 23:28):(this is my sophomoric understanding, not a crypto developer, IANAL etc etc)
Luke Boswell (Jan 22 2026 at 23:28):If you design an idiomatic Roc module that wraps that zig functionality... you could propose the crypto primitive be added to Roc's builtins in a new ideas thread.
Luke Boswell (Jan 22 2026 at 23:29):If we have a solid design proposal -- I am reasonably confident I could implement it in no time
Luke Boswell (Jan 22 2026 at 23:29):@Brendan Hansknecht do you have any thoughts on adding secp256k1 as a primitive?
Rick Hull (Jan 22 2026 at 23:31):If you design an idiomatic Roc module that wraps that zig functionality... you could propose the crypto primitive be added to Roc's builtins in a new ideas thread.
I'm gonna call this a.... S T R E T C H G O A L
Luke Boswell (Jan 22 2026 at 23:44):Rick Hull said:
If you design an idiomatic Roc module that wraps that zig functionality... you could propose the crypto primitive be added to Roc's builtins in a new ideas thread.
I'm gonna call this a.... S T R E T C H G O A L
If you are interesting in working on this... here was the version we almost landed for SHA256 https://github.com/MatthewJohnHeath/rocSHA/blob/1f30fe05e1f617605f8c17c92c2d1ac5290cc667/crates/compiler/builtins/roc/Crypto.roc
Luke Boswell (Jan 22 2026 at 23:45):That will need some translation to use type modules and associated methods etc... but it should give you some ideas
Rick Hull (Jan 23 2026 at 00:11):honestly, my next step is to develop nostr in Roc on top of schnorr-platform; I was just getting comfortable with "old-roc" when I realized there was a "new-roc", and I hardly know either.
Rick Hull (Jan 23 2026 at 01:00):Using this topic as a scratchpad, maybe better than creating new topics. Are build.sh and bundle.sh expected to be standards carried forwards? Or would something like justfile or Makefile be better?
Luke Boswell (Jan 23 2026 at 01:01):The plan is to replace them with build.roc and bundle.roc
Rick Hull (Jan 23 2026 at 01:01):ok, good to know!
Rick Hull (Jan 23 2026 at 01:01):i haven't looked at these in detail but now on my radar
Luke Boswell (Jan 23 2026 at 01:02):Those scripts don't exist yet, we have them in the old compiler version of basic-cli for an example
Rick Hull (Jan 23 2026 at 01:02):is there a canonical build.roc?
Luke Boswell (Jan 23 2026 at 01:02):No -- the plan is to use basic-cli for scripting, but we don't have a release for that yet
Rick Hull (Jan 23 2026 at 01:03):I'm happy to assist with whatever I can with that, but I need to get much more comfortable with basic-cli ergos
Brendan Hansknecht (Jan 24 2026 at 00:04):Luke Boswell said:
Brendan Hansknecht do you have any thoughts on adding secp256k1 as a primitive?
Nope... not really.
Last updated: Feb 20 2026 at 12:27 UTC