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-...
The closest thing I could find online is: https://stackoverflow.com/questions/78892396/how-to-link-to-...
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?
None of this is Linux's fault. I'd argue this is both C's and GNU's fault. The need for a copy of the library, seems to be just a tooling convention. GCC's linker requires it, so others do the same thing. The executable itself doesn't need to know where a given symbol is in a shared library's memory at runtime (or even what shared library a symbol comes from, just that it's inside one of the libraries declared as needed in its dynamic section), because that's the (runtime) linker's job to figure out. Regardless, you don't actually need a full copy of the library—a stub will suffice.
I don't know a ton about compilers, but as far as I know, there's no reason clang's linker (LLD) couldn't just not require an existing copy of the shared library you're linking to. Can't do anything about requiring a version of the libc headers you need for every platform though.
I would argue that it does, but because its apparently illegal (obvious exaggeration alert) to package all the parts of a single entity together in one package, it just seems like it doesn't, where as on Windows there's a single package (the Windows SDK) that contains the majority of the relevant stuff.
I do however 100% agree with you on linking to shared libraries. The way Linux compilers handle that is fucking stupid.
https://github.com/ziglang/zig/tree/master/lib/libc/include
There is one set of headers for Windows. One set for macOS. And a fucking kajillion different headers for Linux.
And of course glibc is a fucking dumpster fire that doesn’t let you trivially target and arbitrary version.
Grumble grumble
:(