experimental/zig: new package (0.11.0)#263
experimental/zig: new package (0.11.0)#263nekopsykose wants to merge 1 commit intochimera-linux:masterfrom nekopsykose:zig-init
Conversation
|
gotta fix $ zig version
0.11.0
error: Zig was built/linked incorrectly: LLVM and Clang have separate copies of libc++
If you are dynamically linking LLVM, make sure you dynamically link libc++ toowhich is // Get a pointer to a static variable in libc++ from LLVM and make sure that
// it matches our own.
//
// This check is needed because if static/dynamic linking is mixed incorrectly,
// it's possible for Clang and LLVM to end up with duplicate "copies" of libc++.
//
// This is not benign: Static variables are not shared, so equality comparisons
// that depend on pointers to static variables will fail. One such failure is
// std::generic_category(), which causes POSIX error codes to compare as unequal
// when passed between LLVM and Clang.
//
// See also: https://github.com/ziglang/zig/issues/11168
bool ZigClangIsLLVMUsingSeparateLibcxx() {
// Temporarily create an InMemoryFileSystem, so that we can perform a file
// lookup that is guaranteed to fail.
auto FS = new llvm::vfs::InMemoryFileSystem(true);
auto StatusOrErr = FS->status("foo.txt");
delete FS;
// This should return a POSIX (generic_category) error code, but if LLVM has
// its own copy of libc++ this will actually be a separate category instance.
assert(!StatusOrErr);
auto EC = StatusOrErr.getError();
return EC.category() != std::generic_category();
}
|
|
@andrewrk do you know why this check fails? i imagine "llvm has its own libc++ copy" is true just because the entire base c++ std is libcxx (for the whole system, there's no gcc components) (in which case i'm not sure how to handle that), but maybe there's actually something else that's wrong |
|
for light reference $ ldd /usr/bin/zig
/lib/ld-musl-x86_64.so.1 (0x7ff981200000)
libclang-cpp.so.16 => /lib/libclang-cpp.so.16 (0x7ff97bc00000)
libLLVM-16.so => /lib/libLLVM-16.so (0x7ff974400000)
libz.so.1 => /lib/libz.so.1 (0x7ff9897b1000)
libzstd.so.1 => /lib/libzstd.so.1 (0x7ff98112c000)
libc.so => /lib/ld-musl-x86_64.so.1 (0x7ff981200000)
libc++.so.1 => /lib/../lib/libc++.so.1 (0x7ff97fcb4000)
libffi.so.8 => /lib/../lib/libffi.so.8 (0x7ff9897a5000)
libedit.so.0 => /lib/../lib/libedit.so.0 (0x7ff989767000)
libncursesw.so.6 => /lib/../lib/libncursesw.so.6 (0x7ff97b989000)
$ ldd /usr/lib/libLLVM-16.0.6.so
ldd (0x7fddaea00000)
libffi.so.8 => /usr/lib/../lib/libffi.so.8 (0x7fddb6f90000)
libedit.so.0 => /usr/lib/../lib/libedit.so.0 (0x7fddb6f52000)
libz.so.1 => /usr/lib/../lib/libz.so.1 (0x7fddb6f34000)
libzstd.so.1 => /usr/lib/../lib/libzstd.so.1 (0x7fdda6f2c000)
libncursesw.so.6 => /usr/lib/../lib/libncursesw.so.6 (0x7fddae989000)
libc++.so.1 => /usr/lib/../lib/libc++.so.1 (0x7fdda6de0000)
libc.so => ldd (0x7fddaea00000)
$ ldd /usr/lib/libclang-cpp.so.16
ldd (0x7f6d44200000)
libLLVM-16.so => /usr/lib/../lib/libLLVM-16.so (0x7f6d38800000)
libc++.so.1 => /usr/lib/../lib/libc++.so.1 (0x7f6d440b4000)
libc.so => ldd (0x7f6d44200000)
libffi.so.8 => /usr/lib/../lib/../lib/libffi.so.8 (0x7f6d4c7dd000)
libedit.so.0 => /usr/lib/../lib/../lib/libedit.so.0 (0x7f6d4c79f000)
libz.so.1 => /usr/lib/../lib/../lib/libz.so.1 (0x7f6d4c781000)
libzstd.so.1 => /usr/lib/../lib/../lib/libzstd.so.1 (0x7f6d3852c000)
libncursesw.so.6 => /usr/lib/../lib/../lib/libncursesw.so.6 (0x7f6d4c70a000) |
There was a problem hiding this comment.
I'm sorry, I don't have any clue why this check is failing. Based on your cmake configuration and ldd output, it seems like it should be OK.
Unfortunately, I don't think it's safe to ignore. Maybe there is someone more familiar with C++ you could ask?
In the long term, this issue will be resolved by ziglang/zig#16270.
| elseif("${CMAKE_BUILD_TYPE}" STREQUAL "RelWithDebInfo") | ||
| set(ZIG_RELEASE_ARG -Doptimize=ReleaseFast) | ||
| else() | ||
| - set(ZIG_RELEASE_ARG -Doptimize=ReleaseFast -Dstrip) |
There was a problem hiding this comment.
This also affects conditional compilation & code generation - stack trace printing code will be omitted when strip is true. If you strip later, this code will remain, bloating the binary, but unable to be useful.
There was a problem hiding this comment.
ah, good to know. i assume the fact it's not actually strip(1) but rather objcopy'd with debuglink (-dbg subpackaged) still makes it useless? (i.e. zig itself won't be able to load it, so may as well just strip it fully by leaving the -Dstrip)
There was a problem hiding this comment.
Hmm well it may be the case that zig could be enhanced to find -dbg files being separately packaged. But let me switch topics for a moment. You shouldn't need that patch because if you want debug info you should use -DCMAKE_BUILD_TYPE=RelWithDebInfo as you can see in the if statement above. I would expect this to already be the default in chimera's package manager. Not sure why you would need a patch here.
There was a problem hiding this comment.
the default is =None, aside from this conditional the only difference for cmake is RelWithDebInfo appends -O2 -g to c*flags (None does nothing), and in this case everything is identical regardless of build type (the default is.. -O2 -g2 via env) up until this conditional
There was a problem hiding this comment.
completely offtopic, the general philosophical reasoning distros use =None instead of other types is because aside from setting some default flags appended to env flags, they don't actually do anything by themselves. i.e.:
None:
Release: -O3 -DNDEBUG
RelWithDebInfo: -O2 -g
MinSizeRel: -Os -DNDEBUG
and they are appended to the env (CFLAGS="stuff" cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo gives CFLAGS="stuff -O2 -g"), which is sometimes unwanted. this basic difference aside, it's project-dependent what anyone does (sometimes a non-release type adds a bunch of stuff one doesn't want, sometimes the release type adds a bunch of stuff one doesn't want (in contrast to None), ...)
it's really a case by case basis so i read through every cmake project because people end up doing anything imaginable with conditionals :D
There was a problem hiding this comment.
Thanks for the explanation! That is a useful perspective for me to be aware of.
|
@nekopsykose, a couple of next-steps that may help: We need to see the
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 2c812f2a7..0395383d4 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -877,6 +877,7 @@ set(ZIG_BUILD_ARGS
"-Dtarget=${ZIG_TARGET_TRIPLE}"
"-Dcpu=${ZIG_TARGET_MCPU}"
"-Dversion-string=${RESOLVED_ZIG_VERSION}"
+ --verbose
)
add_custom_target(stage3 ALL
My current speculation is that a |
|
oh... I think this is the cause: https://github.com/ziglang/zig/blob/d34201c8491007c5a24b4175a5170a5b6cc3d55e/build.zig#L632-L641 Looks like we should enhance the linux case, if Additionally there is a slight complication. We can no longer assume |
shared, but i assume the same thing:
good point, not sure why i didn't get a verbose log in the first place since it's very useful:
to rule that out in another way too, slightly- the build root does not install
ehrm, no. libraries meant to be linked to have a bare .so: |
|
extracted from above: it has a regular -lc++ which i assume would pick up the one from the path. i assume the real issue is just that |
|
but if i'm wrong, then:
if that is actually the case and there is a bundled libc++.a somewhere, then that would cause it. but one never exists in the buildroot from what i can tell, unless zig's compilation process makes one and deletes it after. |
to clarify- development ( |
After a build, And if it is, here's a patch that just may solve issue... diff --git a/build.zig b/build.zig
index 2dd71c5ec..7e8727dbb 100644
--- a/build.zig
+++ b/build.zig
@@ -630,14 +630,19 @@ fn addCmakeCfgOptionsToExe(
const lib_suffix = if (static) exe.target.staticLibSuffix()[1..] else exe.target.dynamicLibSuffix()[1..];
switch (exe.target.getOsTag()) {
.linux => {
- // First we try to link against gcc libstdc++. If that doesn't work, we fall
- // back to -lc++ and cross our fingers.
- addCxxKnownPath(b, cfg, exe, b.fmt("libstdc++.{s}", .{lib_suffix}), "", need_cpp_includes) catch |err| switch (err) {
- error.RequiredLibraryNotFound => {
- exe.linkLibCpp();
- },
- else => |e| return e,
- };
+ // First we try to link against system libstdc++.
+ // Next we try to link against system libc++.
+ // If that doesn't work, we fall to -lc++ and cross our fingers.
+ var found = false;
+ for ([_][]const u8{ "stdc++", "c++" }) |name| {
+ addCxxKnownPath(b, cfg, exe, b.fmt("lib{s}.{s}", .{ name, lib_suffix }), "", need_cpp_includes) catch |err| switch (err) {
+ error.RequiredLibraryNotFound => continue,
+ else => |e| return e,
+ };
+ found = true;
+ break;
+ }
+ if (!found) exe.linkLibCpp();
exe.linkSystemLibrary("unwind");
},
.ios, .macos, .watchos, .tvos => { |
it indeed doesn't find anything, same output as the but then i noticed, that the ldd above was misleading, because it prints the entire graph, flat. i.e. if anything links libc++, obviously ldd will output libc++. but zig itself does not contain a NEEDED for it- so it was actually statically linked! and so:
it works. thanks! the |
|
FYI, the fix landed in zig master, and andrew has flagged it to be part of see commit ziglang/zig@901457d |
|
thanks! |
|
ppc64le fail: |
|
aarch64 is pass (incl tests), but the test suite should probably print some progress or at least a summary, because being completely silent is pretty unhelpful |
|
think that should address both, but if if the powerpc remap works then i'll send that upstream |
|
the patch let it get past the original error, but now i'm getting this: there is no error message... ah: |
|
|
the relevant function is the mentioned line is |
|
unfortunate, no idea how to fix that one :)
that was helpfully also already fixed: ziglang/zig@1c5c3f4 |
|
here is the listing of the local variables in frame 1: and the single relevant global: the segfault seems to be from but that's for later i guess |
|
I have isolated a standalone case: https://gist.github.com/q66/c2ca25698a348c01b96809553893e610 however, compiling and running that does not segfault... |
|
after dehardening the build: |
4 participants
No description provided.