Undefined symbols for architecture x86_64: "DUK_VARARGS" about ducc HOT 6 CLOSED

Hey! I can't reproduce this myself, but I've run into similar problems in the past on macOS. The existence of an alternative toolchain (Xcode) can lead to toolchain mismatches. So I believe the problem is a configuration issue on your machine.

Here's someone who seems to have recently experienced this problem, and who is using the same sort of machine as you are: https://users.rust-lang.org/t/link-failure-when-trying-to-use-cc-bindgen-to-link-c-code/27156

The resolution post in that thread points to this StackOverflow post for more info: https://stackoverflow.com/a/43452124. If you use Homebrew, perhaps running brew unlink binutils is all you need?

I hope this helps. Let me know if you run into more trouble.

from ducc.

I found the "problem" but I'm not sure how to properly solve it.

Basically clang prepends an underscore on every link while compiling duktape, in fact if you run cargo run --bin ffi-gen --features="build-ffi-gen" inside the ducc-sys crate while on a Mac, you'll notice that bindgen expects that behavior and automatically adds the [#link_name] attribute into all bindings. For example:

extern "C" {
    #[link_name = "\u{1}_DUK_VARARGS"]
    pub static mut DUK_VARARGS: duk_int_t;
}

These are all the steps I performed to fix the issue in my machine:

1. Cloned https://github.com/SkylerLipthay/ducc.git
2. Ran cargo run --bin ffi-gen --features="build-ffi-gen inside ducc/ducc-sys
3. Went back to my project and changed the location of ducc inside my Cargo.toml

[dependencies]
ducc = { path = "../ducc/ducc" }

I would submit a PR for ducc-sys but I'm not sure how to correctly deal with this situation. Do you think build.rs should generate the bindings on the fly for non-Linux OS instead of relying on the shipped bindings.rs?

I also created a gist with the bindings.rs generated by my machine in case someone is curious: https://gist.github.com/alanhoff/6e02532ca93f3c9b2ca0296e3da17b6f

Thanks for your time.

from ducc.

Out of curiosity, what happens if you use the original bindings.rs but remove its two #[link_name = ...] attributes (lines 1868 and 1872)? Does compilation work then? Seeing that DUK_VARARGS was the only binding that failed to link, I wonder if the linker has no trouble with the bindings without a link_name explicitly marked.

from ducc.

Removing #[link_name] from the original bindings.rs did the trick :-)

from ducc.

Perfect! To systematically prevent #[link_name]s it looks like we can just specify .trust_clang_mangling(false) in ffi_gen.rs. I'll go ahead and make these changes, including merging your PR to whitelist the ducc_* functions. (I'm starting to remember what a pain all of this was for me. I must have added the ducc_* functions to bindings.rs manually so I wouldn't be forced to run ffi_gen again.)

Thanks for troubleshooting!

from ducc.

🙌

from ducc.