Skip to content
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

dynlib use zig ld invalid #21918

Open
htqx opened this issue Nov 5, 2024 · 2 comments
Open

dynlib use zig ld invalid #21918

htqx opened this issue Nov 5, 2024 · 2 comments
Labels
bug Observed behavior contradicts documented or intended behavior

Comments

@htqx
Copy link

htqx commented Nov 5, 2024

Zig Version

0.14.0-dev.1860+2e2927735

Steps to Reproduce and Observed Behavior

I just try the DLL function. There are many problems.

Create DLL and EXE by default, and use the command line link to occur.

But the method of using Dynlib can be used normally.

zig build-lib -dynamic lib.zig
zig build-exe -llib -L. exe.zig

Later, after I tried -fno -lld, the link was directly commanded, which was normal.

zig build-exe -llib -L. -fno-lld exe.zig

But the method of using Dynlib collapsed.

Finally, I tried to use -lc to replace someone's Dynlib implementation. As a result, both methods can be used normally.

zig build-exe -llib -L. -fno-lld exe.zig -lc

uname -a
Linux arch-pc-lv3 6.11.5-arch1-1 #1 SMP PREEMPT_DYNAMIC Tue, 22 Oct 2024 18:31:38 +0000 x86_64 GNU/Linux

Expected Behavior

run is ok.

@htqx htqx added the bug Observed behavior contradicts documented or intended behavior label Nov 5, 2024
@rohlem
Copy link
Contributor

rohlem commented Nov 5, 2024

Can you provide the source code of the lib.zig and exe.zig files that you attempted this with? (Or alternatively a reduced version that still causes the issue for you?)

But the method of using Dynlib collapsed.

I assume you mean that the built executable crashed at the point that it would execute a function from the dynamic/shared library?

@htqx
Copy link
Author

htqx commented Nov 5, 2024

Because the process is more tortuous, it can no longer be reproduced.

The default DynLib is not normal, and I have forgotten what parameters make it normal.

What can be reproduced now is:

-lc : can be normal, which is the most critical parameter.

but:
-fno-lld: can make the link method normal, but Dynlib cannot be normal.
-lc :also allows Dynlib to be normal.

//exe.zig
const std = @import("std");

const S = extern struct {
    name: [*:0]const u8,
    age: u8,
};
extern fn get() S;
const println = struct {
    fn println(comptime fmt: []const u8, args: anytype) void {
        std.debug.print(fmt ++ "\n", args);
    }
}.println;
const message = struct {
    fn message(msg: []const u8) void {
        println("{s}", .{msg});
    }
}.message;

pub fn main() !void {
    message("call lib...");
    println("dynLink: name:{s}, age:{}", .{ get().name, get().age });
    var lib = try std.DynLib.open("./liblib.so");
    defer lib.close();
    const dnyGet = lib.lookup(@TypeOf(&get), "get") orelse return error.noOpen;
    println("dllopen: age:{}, name:{s}", .{ dnyGet().age, dnyGet().name });
}
// lib.zig
pub const S = extern struct {
    name: [*:0]const u8,
    age: u8 = 213,
};

pub export fn get() S {
    return .{ .name = "来自 lib 的爱。" };
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior
Projects
None yet
Development

No branches or pull requests

2 participants