-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
-lc
doesn't link c_nonshared
#11137
Comments
Prior to this commit, building on Arch Linux would result in the following linker error: undefined symbol: __libc_single_threaded Updates ziglang#11137.
Arch uses glibc 2.35. Looking through recent glibc changes related to |
The proper fix is probably adding |
At least for me a default build of glibc contains // The order of the elements in this array defines the linking order.
pub const libs = [_]Lib{
.{ .name = "m", .sover = 6 },
.{ .name = "pthread", .sover = 0 },
.{ .name = "c", .sover = 6 },
.{ .name = "dl", .sover = 2 },
.{ .name = "rt", .sover = 1 },
.{ .name = "ld", .sover = 2 },
.{ .name = "util", .sover = 1 },
}; Nevertheless, How is Zig picking up the correct paths to the libcs etc in |
Note that zig is perfectly capable of providing libc_nonshared.a... but in the case of native builds we don't do it because we want to actually integrate with system libc. So we're stuck figuring out what the various systems want from us. |
On my glibc 2.32 void linux system
This might help explain things, in particular why I wasn't seeing any reference to |
Ok, on my glibc 2.35 gentoo system
|
On Arch its similar /* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )
/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily. */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /usr/lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /usr/lib/ld-linux-x86-64.so.2 ) )
|
DONT INCLUDE THIS IN THE FINAL PR. This is just for convenience as I switch back and forth from my two laptops.
Ah, and |
On my system, Zig is in fact providing
If I request a system library so that Zig integrates with system libc, the example actually works:
|
Can you please share output of |
I guess this will be fixed when #6469 will be fixed:
|
Indeed, the wrong version of glibc is detected: pub const os = std.Target.Os{
.tag = .linux,
.version_range = .{ .linux = .{
.range = .{
.min = .{
.major = 5,
.minor = 10,
.patch = 102,
},
.max = .{
.major = 5,
.minor = 10,
.patch = 102,
},
},
.glibc = .{
.major = 2,
.minor = 19,
.patch = 0,
},
}},
}; |
that's tracked separately in 6469 |
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 check whether #12788 solves it? |
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
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
Duplicate of #6469 since the example works as expected with |
Not sure how this works on other targets but on Arch Linux it means that building stage2 with system LLVM requires this patch:
The text was updated successfully, but these errors were encountered: