find libc and zig std lib at runtime #872
Conversation
this removes the following configure options: * ZIG_LIBC_LIB_DIR * ZIG_LIBC_STATIC_LIB_DIR * ZIG_LIBC_INCLUDE_DIR * ZIG_DYNAMIC_LINKER * ZIG_EACH_LIB_RPATH * zig's reliance on CMAKE_INSTALL_PREFIX these options are still available as command line options, however, the default will attempt to execute the system's C compiler to collect system defaults for these values. closes #870
|
Oops, forgot to implement self_exe_path for macos. That should fix that build. Not sure why windows is failing yet. |
|
|
||
| if (g->zig_target.os == OsWindows) { | ||
| ZigWindowsSDK *sdk = get_windows_sdk(g); | ||
| if (os_get_win32_ucrt_include_path(sdk, g->libc_include_dir)) { | ||
| zig_panic("Unable to determine libc include path."); | ||
| } | ||
| } else if (g->zig_target.os == OsLinux) { | ||
| g->libc_include_dir = get_linux_libc_include_path(); |
There was a problem hiding this comment.
I'm curious, is this ever anything but /usr/include? When cross-compiling perhaps? (But wasn't the plan to only support that in the stage 2 compiler or did I misunderstand?)
Another question: is a single include directory enough? I'm guessing the answer is 'yes' because it already works this way today.
Normally /usr/include contains libc-related files (stdio.h, stdlib.h, etc.) whereas arch/compiler-specific files go into /usr/lib/gcc/x86_64-linux-gnu/*/include (stdarg.h, stddef.h, etc.)
There was a problem hiding this comment.
on my system (nixos) it can vary depending on what shell you're in. here's an example of the values for me in master branch:
#define ZIG_LIBC_INCLUDE_DIR "/nix/store/p85kjy91dfvs4in358zyfxlksvibw0zn-glibc-2.26-131-dev/include"
#define ZIG_LIBC_LIB_DIR "/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib"
#define ZIG_LIBC_STATIC_LIB_DIR "/nix/store/bm7pb1s7rx1ad80706b5xqrznq7fgpgx-gcc-7.3.0/lib/gcc/x86_64-unknown-linux-gnu/7.3.0"
#define ZIG_DYNAMIC_LINKER "/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2"
is a single include directory enough?
I believe so. I think the libc standard specifies the .h file layout, and there is only 1 root directory.
whereas arch/compiler-specific files go into ...
Zig actually provides these headers - we copy them from the clang project. They're in the c_headers/ directory and we install them to $(prefix)/lib/zig/include, and then when we do C imports, we put this path as an include path.
| if (buf_len(out_stdout) == 0 || buf_eql_str(out_stdout, "ld-linux-x86-64.so.2")) { | ||
| return target_dynamic_linker(&g->zig_target); | ||
| } | ||
| return out_stdout; |
There was a problem hiding this comment.
Can this ever return anything but /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2?
There was a problem hiding this comment.
on nixos you can have multiple shells open with different dynamic linker versions. here's an example value for me:
#define ZIG_DYNAMIC_LINKER "/nix/store/2kcrj1ksd2a14bm5sky182fv2xwfhfap-glibc-2.26-131/lib/ld-linux-x86-64.so.2"
| @@ -863,6 +863,10 @@ Buf *target_dynamic_linker(ZigTarget *target) { | |||
| env == ZigLLVM_GNUX32) | |||
| { | |||
| return buf_create_from_str("/libx32/ld-linux-x32.so.2"); | |||
| } else if (arch == ZigLLVM_x86_64 && | |||
| (env == ZigLLVM_Musl || env == ZigLLVM_MuslEABI || env == ZigLLVM_MuslEABIHF)) | |||
There was a problem hiding this comment.
Correct me if I'm wrong but EABI is ARM-only, isn't it?
There was a problem hiding this comment.
I thought it stood for ELF Application Binary Interface. But now that you mention it, I don't know how x86_64 could need a Hard Float argument.
I should probably consult the code in clang that this was originally ported from - I'm sure they've added correct handling for the new Musl environment entries.
ported from the zig std lib this fixes looking for zig std lib at runtime on darwin
this removes the following configure options:
these options are still available as command line options, however,
the default will attempt to execute the system's C compiler to
collect system defaults for these values.
closes #870
cc @tgschultz
I'm going to let the Windows/MacOS tests finish before merging.