I’m trying to revise my odin code (of which there is very little since i’m so new to it) to use os2 rather than os.
This means that i now use ^File from os2 instead of os.Handle.
I have several fmt.printfln(…) statements to replace.
Now, i can replace them by using fmt.aprintfln(…), then transmuting the resulting string to byte, and using os2.write(…) to get to the ^File. This would be like using sprintf(…) followed by fwrite(…) with a FILE* in c. But in c, you’d normally just use fprintf(…) and skip the string step.
So . . . i’m wondering if i’m missing a formatted write proc in fmt or elsewhere that is like c’s fprintf and uses ^File from os2.
I’m running odin version dev-2026-02 from macports (on macos).
Homebrew does not work for my version of macos, which is why i use macports. And the macports odin does work, but it’s at least month’s version (dev-2026-02), which is presumably why the new fmt was invisible to me. (I only looked in the filesystem, not on the net where i might have found the reference margal pointed out if i had been a little more resourceful.)
The pre-built binaries that margal pointed out are a logical thing to try, but there’s some dynamic library issue (some expected symbol not found) with them.
I appreciate everybody’s help!
And i’ll either have to wait for macports to catch up or see if i can build my own.
One quick little followup here, in case somebody from the internet stumbles on this post because they are in a similar situation of wanting to compile odin because the macports version is out of date.
The deal is that it really is simple to compile odin, at least on macos using macports.
All you have to do is get a source tarball, such as from or around the link Margal posted, and unpack it.
Then make sure you have a suitable llvm installed from macports; we used llvm-21
Then cd to the directory Odin-dev-2026-03 (or whatever is right for the version you want)
Then invoke the building script via
LLVM_CONFIG=/opt/local/bin/llvm-config-mp-21 ./build_odin.sh
Now, in fact, when we did this, it failed with exit status 134, but it didn’t really fail. It just failed because it tries to run odin as a checking step, and that didn’t work.
But the reason it didn’t work was just some rpath dylib issue.
You can actually get the compiled executable odin to run by manually specifying the LD_LIBRARY_PATH.
For us, we can try out the executable via:
LD_LIBRARY_PATH=/opt/local/libexec/llvm-21/lib ./odin version
which works and prints the right version.
Now, if and when macports updates from dev-2026-02 to dev-2026-03, they will iron out the rpath dylib issue so that no envronment will need manual tweaking. But anybody, on macports, who needs a version prior to the macports release, can do something like this if they are willing to put up with the mild aggravation of manually specifying the LD_LIBRARY_PATH (or setting up a wrapper, or similar).