Consider using zig cc to make prebuilt binaries #231
Comments
|
Looks extremely promising. |
|
Was thinking about this as well. Would be interesting to try. |
|
+1 |
|
Played around with it a bit. Was able to get luv to compile but the resulting LuaJIT fails to load the resulting luv.so.
EDIT: ( EDIT#2: My guess is that its the unfinished "passing args to the linker" bullet point, as the end-result LuaJIT compile command ends up being: so I would bet that EDIT#3: Running the above directly gives the output: coming from here, presumably. EDIT#4: Manually just added This is worth noting because it will potentially affect the portability of |
|
I'm happy to work with y'all on this, give me a couple days to fix up that flag integration like @squeek502 noted above and then let's coordinate on this use case. For glibc versions, as long as you know which glibc version you want to target and we add some way to communicate that info to holy-build-box readme says:
So you should be able to use |
|
I have a feeling the tough part will be getting OpenSSL to compile. We use a CMake |
|
One problem with cmake I learned this week is that it does not have a separate concept of a "host compiler" and a "target compiler". So unless the upstream project adds support for it, there will be an issue when a project builds a binary and then tries to run it. A better build system would allow you to choose which binaries were native and which were for the target, so that you could build your native tools natively, and build your target code for the target. |
|
Instead of using holy-build-box libc, I'd prefer if we could do a static build with musl. Then it will work on even more linux versions than our old binaries. I had trouble before trying to build static luajit binaries, but I seem to remember that was exactly one of the examples in @andrewrk's blog post. |
|
Was actually able to build a static musl binary of the luvi (the However, when running the resulting meaning that something is going wrong with the embedding of |
|
Oh, just remembered that I tried making a That is, when compiled statically, |
True, anybody needing to load native modules will need this. I wonder if it's worth the effort to have a static build that disables loading native modules. Even ffi use cases often use dlopen to call the libraries. |
|
The other option zig cc provides you is "static except glibc" builds, and if you pick an old enough glibc version (e.g. matching holy-build-box) then your binary tarballs will work on any linux distro that uses glibc and standard dynamic linker path (which is most). This is the The nice thing about static tarballs is they work on all linux distros, even ones like NixOS which have non-standard dynamic linker paths, and alpine linux which uses musl instead of glibc. |
|
Alright, I've done some polishing on this feature, and it's about 1 week until the 0.6.0 release. If you're still exploring this use case, now would be a good time to try it out and report issues that you run into. Let me know if I can help. |
|
Being able to target a specific glibc version would be nice. I'll look into the embedded-Lua file issue mentioned here and try to figure out what's going wrong and how/if it's related to |
I'm not planning to solve ziglang/zig#4911 before the release, so you can use this syntax:
|
|
results in: EDIT: Can't seem to make a minimal reproduction:
#include <fcntl.h>
#include <stdio.h>
int main() {
int mode = fcntl(0, F_GETFL);
printf("mode=%d\n", mode);
return 0;
}works fine and results in |
|
I begin to learn "zig cc" build for macos but cross build openssl-1.0.2 for windows on macos success with great, @andrewrk, and I hope a Edit 1.1.1f fail opt_init should be in apps/libapps.a |
|
It's been a while since this has been touched up on, but we can now obtain a run-able (but non-functional) luvi using zig. Building on linux: $ export CC="zig cc -target native-linux-gnu.2.28"
$ export CXX="zig c++ -target native-linux-gnu.2.28"
$ export ASM="zig cc -target native-linux-gnu.2.28"
$ make tiny
$ makeLuvi can be run: But the first test case (samples/test.app) panics with the following error: Which happens on (using lldb) the following traceback: |
|
I contine todo this with a checklist, after all build pass, I will make a PR to finish this job.
Tips |
|
I have build luvi success, but fail to run it. and sometimes got I have no ideas, and just guest not compat with JIT feature |
|
My latest attempt at building luvi. TLDR; I now have luvi building for x86_64-linux-gnu on linux. Successes
BuldingUsing zig version: Setupzig-cc: zig-asm: zig-cxx: export CC="$(pwd)/zig-cc"
export CXX="$(pwd)/zig-cxx"
export ASM="$(pwd)/zig-asm"CMAKE_FLAGS: make tiny "CMAKE_FLAGS=$CMAKE_FLAGS"
make
make testTargetsMuch Bug
Less BugSome of these are probably caused by a lack of system support (see emulation)
The biggest issue for major systems right now is linking dlopen |
|
Would a version that disables dlopen be useful? It would break loading native modules as well as dynamic linking to libraries using ffi, but we would still have access to all the built-in native code and can still use ffi for ctypes type stuff. |
|
Seen above, @zhaozg did get cross compiling to work for most of the systems we care about, but I assume thats after modifying the build system to make proper assumptions about cross compilation. Not linking dlopen is actually an issue because of how luvi loads itself, its compiled as a dynamic library which loads itself, which is how the precompiled luajit stuff works (init, luvibundle, luvipath are all loaded this way). If we were to link without dlopen, those would no longer work and everything would break. |
|
Bleh, I forgot about that part. At least we're making good progress. |
That list is obsolete, some build broken or output run crash, I need recheck it, and we should give more time to wait zig grows |
https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html
I think this might enable us to build all the prebuilt luvi binaries using a single linux host such as our CI servers.
The text was updated successfully, but these errors were encountered: