I’m playing with zig 0.17 because I’m bloody impatient for incremental compilation and I’ve been descending dvui dependencies curious to see what is still blocking.
I have a “blocking” point with freetype. I hit respectively
error: multiple definitions of 'FT_Stream_Open'
and
error: undefined global symbol '__init_array_start'
error: undefined global symbol '__init_array_end'
with two different packaging of freetype. You can have a look in the “minimal” repro I put together for details.
Does anybody knows if it’s a known bug/limitation ? I found a few similar issues on the tracker but I’m not experienced enough with that stuff to make educated guesses about their respective relevance.
I’m assuming the issue is on zig’s incremental side since non-incremental works, but I could be wrong.
PS :
I’ve managed to have some success to build a dvui app with stb_truetype instead, and sdl3. It’s still a total mess in my temp/dvui-deps folder, but re-building a non trivial gui application in less time that it takes for the OS to pop a Window is soooo good. I’m thrilled
The second issue I expect to be fairly straightforward to fix, and I already have a reasonable guess as to why it’s happening.
The first issue is probably more complicated since I suspect it relates to a slightly tricky missing feature, but I’ll take a look—I can hopefully at least give you a workaround.
(If I’ve not said anything here within a couple of days, it probably means I’ve forgotten, in which case I’d appreciate if someone would ping me again!)
Thank you for trying this out! I really appreciate reports like this, because they let me know which features & bugfixes are important to get into the release to get incremental compilation working as well as possible for real use cases when the wider Zig community get their hands on these changes in 0.17.x.
Okay, I’ve finally had a moment to look into these!
The first issue is a known missing feature in the new linker. Luckily, it’s easily worked around with a patch to the freetype package you’re using. This patch is actually a good idea regardless—I’ve explained why in the PR I just sent to David’s repo. (While you’re waiting for the PR to be merged, feel free to depend on that branch from my fork if you want—I’ll avoid deleting it for a few weeks.)
Applying that patch gets you to the same __init_array_start/__init_array_end issue as you have with the Mach package. This one is a straightforward bug in the new linker, and I’ll PR a fix for it shortly (it’ll definitely be in 0.17.0). But in the meantime, it’s a very easy to work around if you’d like to. The easiest way is to create a C source file with the following content:
At least for me, those fixes/workarounds make your repro work, both with and without -Duse-mach—but let me know if you hit any more problems! I’ll leave another comment here once I’ve got the Zig compiler PR up with the fix for the second issue.
Incredible, thank you very much. Even more than I was expecting.
Very happy that DVUI’s users will be able to benefit instant re-compile when 0.17 is released. (at least with SDL/freetype, still working on the other branches of the dependency tree. Let’s see)
I continued my quest following DVUI’s dependencies. Next : raylib.
Took me a bit of effort to compile to 0.17 due to some unrelated build system shenanigans, but now it works and I end up with another -fincremental error :
compile exe core_input_actions Debug native 1 errors
error: unsupported object type
note: while parsing .zig-cache/o/ee2128f4c8fb51048b3fc9a054d3039d/libraylib.a
error: 1 compilation errors
and I’ve been descending dvui dependencies curious to see what is still blocking.
