Rust-bindgen: The link options are ignored.

[emilio]

It seems that I dropped them during the rewrite, can't remember if I did it accidentally or not.

In any case, we announce to support it and don't, which should be fixed either removing the option or supporting it properly.

[jdub]

What should they do? Detect if its running in build.rs and print cargo:rustc-link-lib= lines? Add #[link] attributes?

[emilio]

The old behavior for this option is to create #[link] attributes. I'm still pretty dubious it's the right functionality to have builtin support for in bindgen, but some people seemed to disagree on IRC and found it useful.

[metajack]

This is probably a good thing to ask @alexcrichton

[alexcrichton]

rustc-link-lib and #[link] are equivalent, so it shouldn't matter which is used

[metajack]

I think in the past we've preferred rustc-link-lib because having this information outside of build.rs made a mess.

[jdub]

OK, for now I'll spit out rustc-link-lib directives if we're in build.rs, and otherwise continue to ignore the link flags.

I'll fix this with my docopt changes in servo/rust-bindgen#202.

[jdub]

Hmm, I might hold off and do it separately. It's unclear when it should happen in the library use case: On generate() or write()? Probably write(), but your feedback would be appreciated.

[jsgf]

I was expecting these options to add #[link] to the extern block. I'm currently faking this with --raw-line=#[link(name = "mylib++")] extern {} which seems OK, but I'm concerned that a future version of the compiler would treat the extern {} as useless and drop it - I'd feel more comfortable if it were attached to an extern block with signatures in it.

build.rs-based approaches aren't useful for me because I'm not using cargo to build.

[ryankurte]

Updating stuff from a previous bindgen / rust version, and also not using cargo to build. Is there a recommended solution for this?
Current approach is sed -i '' 's/^extern "C" {/#[link(name = "${LIBNAME}")] extern "C" {/' ${FILENAME} after generation, in case that is useful to others.

[emilio]

@ryankurte I believe the cleanest solution for this is --raw-line for now. I don't have the time right now to implement this, but I'm happy to mentor anyone wanting to do so.

[ryankurte]

Oh right! Trouble there is that raw line only seems to accept one line, and
I have also had to blacklist and manually replace some types. Might be
cleaner for now just to cat two files together.
Cheers for the response, I will have a nosey into it if I have some time.

On Tue, 14 Feb 2017, 1:01 AM Emilio Cobos Álvarez, [e-mail]
wrote:

@ryankurte https://github.com/ryankurte I believe the cleanest solution
for this is --raw-line for now. I don't have the time right now to
implement this, but I'm happy to mentor anyone wanting to do so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/servo/rust-bindgen/issues/104#issuecomment-279368358,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA0hzO5MJ4gtZCgiSEGFdoilMJepMCyVks5rcEYmgaJpZM4KbbEq
.

[mitchmindtree]

I've just run into this issue when generating new bindings using the CLI (and regenerating old bindings) for the coreaudio-sys crate, specifically when linking the necessary frameworks (CoreAudio, AudioUnit, AudioToolbox, etc).

The generated link_name for each function (e.g. #[link_name = "\u{1}__Z21AudioUnitUninitialize"]) results in "undefined symbols for platform" when depending on coreaudio-sys from another crate.

However if I remove the link_name above each generated function and add #[link(name = "AudioUnit", kind = "framework")] above the enclosing extern "C" block that is around each function, it works successfully.

I'm unsure how to work around this in the meantime as there's a few thousand of these blocks in each module, and although I could test a few individual functions successfully my sed/grep find and replace skills are not quite up to this task of handling every function properly.

Any tips on how to either work around this or fix this in rust-bindgen itself would be greatly appreciated!

[mitchmindtree]

FWIW I'm getting the same issue even when generating the bindings using a build.rs script - see the build script on the branch here. Perhaps i'm incorrectly linking the frameworks here?

[mitchmindtree]

Ah, disabling trust_clang_mangling seems to fix linking with the build.rs-generated approach.