zig detects wrong libc version #6469
Labels
bug
Observed behavior contradicts documented or intended behavior
contributor friendly
This issue is limited in scope and/or knowledge of Zig internals.
frontend
Tokenization, parsing, AstGen, Sema, and Liveness.
os-linux
Milestone
Comments
alexnask
added
bug
|
I am also running void linux, but Zig does detect the right version: pub const os = Os{
.tag = .linux,
.version_range = .{ .linux = .{
.range = .{
.min = .{
.major = 3,
.minor = 16,
.patch = 0,
},
.max = .{
.major = 5,
.minor = 5,
.patch = 5,
},
},
.glibc = .{
.major = 2,
.minor = 30,
.patch = 0,
},
}},
}; |
|
@ifreund can you double check with |
|
Excuses, i hadn't built the most recent Zig compiler. It now also detects 2.17 on my system, so this seems to be a regression. |
valgrind log |
|
Two problems here, the first being that |
|
Does the latter problem mean Zig should search the other places like DT_RPATH, LD_LIBRARY_PATH, /lib and /usr/lib similar to ld? |
|
Regarding the |
--- a/src/stage1/codegen.cpp
+++ b/src/stage1/codegen.cpp
@@ -8815,7 +8815,7 @@ Buf *codegen_generate_builtin_source(CodeGen *g) {
buf_append_str(contents, "/// Deprecated: use `std.Target.current.cpu.arch.endian()`\n");
buf_append_str(contents, "pub const endian = Target.current.cpu.arch.endian();\n");
buf_appendf(contents, "pub const output_mode = OutputMode.Obj;\n");
- buf_appendf(contents, "pub const link_mode = LinkMode.Static;\n");
+ buf_appendf(contents, "pub const link_mode = LinkMode.Dynamic;\n");
buf_appendf(contents, "pub const is_test = false;\n");
buf_appendf(contents, "pub const single_threaded = %s;\n", bool_to_str(g->is_single_threaded));
buf_appendf(contents, "pub const abi = Abi.%s;\n", cur_abi);try this. should be OK because this applies only to building zig1.o I'm not sure why the |
Tried and confirmed that it fixed the issue for me at least. Should this be PR'd? |
|
Is libc bundled with zig or there are two versions in my computer. |
Shit hits the fan pretty quickly if you want to do things right, here's a quote from ld.so manpage: |
andrewrk
added a commit
that referenced
this issue
Oct 4, 2020
Now it is Dynamic unless -DZIG_STATIC=on is passed to cmake. This partially addresses #6469.
andrewrk
added
enhancement
|
@ifreund one thing I still want to figure out, is why did zig get the wrong OS version? 3.16.0...5.5.5 means it failed to extract the value from the |
|
Here's what I get from the uname syscall on my machine using the following code: const std = @import("std");
pub fn main() !void {
std.debug.print("{}\n", .{std.os.uname()});
} |
|
Hi, I have the same issue on Archlinux. I get linking error: Enviroment:
Packages versions: |
ifreund
changed the title
|
@vesim987, whats the output of |
|
|
Perhaps it's time to reconsider whether the extra-smart, super-complex and fallible heuristic used here is pulling its own weight. |
No. I veto adding a dependency on |
andrewrk
added
bug
This was referenced May 28, 2022
|
Looks like there is a regression:
...
pub const os = std.Target.Os{
.tag = .linux,
.version_range = .{ .linux = .{
.range = .{
.min = .{
.major = 5,
.minor = 18,
.patch = 1,
},
.max = .{
.major = 5,
.minor = 18,
.patch = 1,
},
},
.glibc = .{
.major = 2,
.minor = 19,
.patch = 0,
},
}},
};
...Same on Arch Linux. |
|
Problem is that on Arch For that matter, neither is They do both support being executed with a |
|
Maybe we can use confstr() with name upd: or execute |
andrewrk
added a commit
that referenced
this issue
Sep 9, 2022
Previously, this code would fail to detect glibc version because it relied on libc.so.6 being a symlink which revealed the answer. On modern distros, this is no longer the case. This new strategy finds the path to libc.so.6 from /usr/bin/env, then inspects the .dynstr section of libc.so.6, looking for symbols that start with "GLIBC_2.". It then parses those as semantic versions and takes the maximum value as the system-native glibc version. closes #6469 see #11137 closes #12567
|
Could I get someone affected by this issue to verify that #12788 indeed solves it? |
andrewrk
added a commit
that referenced
this issue
Sep 9, 2022
Previously, this code would fail to detect glibc version because it relied on libc.so.6 being a symlink which revealed the answer. On modern distros, this is no longer the case. This new strategy finds the path to libc.so.6 from /usr/bin/env, then inspects the .dynstr section of libc.so.6, looking for symbols that start with "GLIBC_2.". It then parses those as semantic versions and takes the maximum value as the system-native glibc version. closes #6469 see #11137 closes #12567
andrewrk
added a commit
that referenced
this issue
Sep 9, 2022
Previously, this code would fail to detect glibc version because it relied on libc.so.6 being a symlink which revealed the answer. On modern distros, this is no longer the case. This new strategy finds the path to libc.so.6 from /usr/bin/env, then inspects the .dynstr section of libc.so.6, looking for symbols that start with "GLIBC_2.". It then parses those as semantic versions and takes the maximum value as the system-native glibc version. closes #6469 see #11137 closes #12567
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
My system libc version is
2.30but zig detects and builds2.17which causes linking errors withexpatfor example:Compiling with
--show-builtingives the following os struct, demonstrating that the wrong glibc version is detected.The text was updated successfully, but these errors were encountered: