▲ | remindmeagain 3 days ago | ||||||||||||||||||||||||||||||||||||||||||||||
I'm trying to wrap my mind around what you wrote. Do you envision a different binary separate from zig? The closest thing I could find online is: https://stackoverflow.com/questions/78892396/how-to-link-to-... | |||||||||||||||||||||||||||||||||||||||||||||||
▲ | forrestthewoods 3 days ago | parent [-] | ||||||||||||||||||||||||||||||||||||||||||||||
Cross-compiling is super super easy conceptually. All you need is headers and an import library. Windows is trivial to cross compile for because there is a single set of headers. And for DLLs Windows compiler like to generate an import lib. Which is basically a stub function for all exports. Linux is stupid and sucks. Linux doesn’t have a single set of headers because programmers in the 80s didn’t know better. And Linux linking to a shared library expects you to have a full copy of the library you expect to exist at runtime. Which is fucking stupid and ass backwards. But I digress. So. Why is Zig awesome for crosscompiling C++? Because Zig fixed Linux sucking ass. Zig moves mountains to generate thin “import libs” of the half dozen .so files you need to link against to run on Linux. If you want to cross compile C++ for Linux all you need is clang++ executable, headers, and those stub .so files. Zig generates the libs implicitly as part of its zig cc build process. I’m asking for the half dozen (C) or dozen (C++) libs to be explicitly exportable by Zig. So that they can be trivially used in other build systems. I’ve got a custom polyglot build system that leverages Zig. But I have to zig cc a hello_world.cpp and parse the output to get the paths to those libs. Which is annoying and janky. Hopefully that helps? | |||||||||||||||||||||||||||||||||||||||||||||||
|