Crate-type = ["cdylib"] produces dylib

help
1

Hi!
I was trying to create Node native addon using Neon bindings and stumbled into a problem, that Rust ignores crate-type = ["cdylib"] in Cargo.toml and produces .dylib as a cargo build result.
I tried to reproduce this on other projects, and got reproduction even on a very simple example like GitHub - John2143/rust-example-cdylib: example of a rust -> c library
I even created clean MacOS VM in UTM, installed latest Rust, and got reproduction.
Can someone please help me to investigate this issue?

To clarify, I am using MacOS 14.6.1 on M1 mac, Rust 1.80.1.
When running cargo build --message-format=json I am getting result

{
    "reason": "compiler-artifact",
    "package_id": "path+file:///.../rust-example-cdylib-master/my-lib#0.1.0",
    "manifest_path": "/.../rust-example-cdylib-master/my-lib/Cargo.toml",
    "target": {
        "kind": [
            "cdylib"
        ],
        "crate_types": [
            "cdylib"
        ],
        "name": "my_lib",
        "src_path": "/.../rust-example-cdylib-master/my-lib/src/lib.rs",
        "edition": "2018",
        "doc": true,
        "doctest": false,
        "test": true
    },
    "profile": {
        "opt_level": "0",
        "debuginfo": 2,
        "debug_assertions": true,
        "overflow_checks": true,
        "test": false
    },
    "features": [],
    "filenames": [
        "/.../rust-example-cdylib-master/target/debug/libmy_lib.dylib"
    ],
    "executable": null,
    "fresh": false
}
2

This is expected.

crate-type = ["cdylib"] tells Cargo to produce a C-compatible dynamic library. The dynamic library will have a .dylib extension on macOS, a .dll extension on Windows, and a .so extension on Linux and other ELF platforms.

2 Likes
3

Are you sure? Neon bindings provide cargo-cp-artifact package to copy the assembled library and rename it into .node And this package is specifically looking for cdylib extension: neon/pkgs/cargo-cp-artifact/src/args.js at 37e43ccbe0320d2eb67f80be6d52cec9ef040ce0 · neon-bindings/neon · GitHub
That made my think that expected result is a cdylib, not a dylib

4

That script does not use cdylib as a filename extension. It looks up filenames from the filenames field of the cargo JSON output: neon/pkgs/cargo-cp-artifact/src/index.js at 37e43ccbe0320d2eb67f80be6d52cec9ef040ce0 · neon-bindings/neon · GitHub

It then matches each filename entry with the corresponding entry from the target.kinds JSON field. It is this kind that is expected to be the string "cdylib": neon/pkgs/cargo-cp-artifact/src/index.js at 37e43ccbe0320d2eb67f80be6d52cec9ef040ce0 · neon-bindings/neon · GitHub

5

Checked another project using cargo-cp-artifact GitHub - zkemail/relayer-utils and it builds successfully for me. Must be some other reason why cargo-cp-artifact prints Did not copy in my project. Thank you very much for such a quick support!

6

cdylib is not a real extension, dynamic libraries have had the extension .dylib on macOS by convention (or none when inside a Framework bundle) for decades.

7

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.