Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 18:51
    emilio labeled #1500
  • Jan 31 18:47
    highfive commented #1508
  • Jan 31 18:47
    highfive labeled #1508
  • Jan 31 18:47
    flowbish opened #1508
  • Jan 31 14:34
    emilio closed #1506
  • Jan 31 14:34
    emilio commented #1506
  • Jan 31 14:18
    wellorange commented #1507
  • Jan 31 14:17
    wellorange commented #1507
  • Jan 31 14:16
    wellorange commented #1507
  • Jan 31 13:08
    emilio closed #1507
  • Jan 31 13:08
    emilio commented #1507
  • Jan 31 12:58
    wellorange opened #1507
  • Jan 31 12:01
    stephank commented #1506
  • Jan 31 11:58
    stephank commented #1506
  • Jan 31 11:57
    stephank commented #1506
  • Jan 31 11:10
    emilio labeled #1506
  • Jan 31 11:10
    emilio commented #1506
  • Jan 31 08:14
    stephank edited #1506
  • Jan 31 08:14
    stephank opened #1506
  • Jan 29 15:38
    emilio commented #1270
Kitsu
@l4l
Hey! I'm trying to make working cxx bindings. Unfortunately it fails with parse failed and I'm using clang 6.0.0. I tried switch to clang3.9 via CXX var but that doesn't help
Igor Matuszewski
@Xanewok
@fitzgen so I just wanted to cite bindgen project in my thesis and realized the LICENSE may be... not up to date? lol
and it's more confusing, since https://github.com/rust-lang-nursery/rust-bindgen/blob/master/Cargo.toml#L11 specifies BSD, but the repository contains an all rights reserved one dating from 2013
vthriller
@vthriller
I stumbled upon #defines that bindgen can't currently handle, namely in the form of #define FOO (~(u_int)0). The stupid question I have is whether I should just add a comment to rust-lang-nursery/rust-bindgen#316 regarding bitwise not or go ahead and file separate issue (cause support for ~whatever in #defines seems limited, if not, uhm, incidental?)
Silvan Mosberger
@Infinisil
Hey, is there a way to add additional CFLAGS to bindgen via some environment variable?
Emilio Cobos Álvarez
@emilio
@vthriller yeah, support for more than simple constants in #define is always going to be a hack if we ever implement it
@vthriller You can work around it doing const u_int MY_FOO = FOO in a header of yours. Bindgen should pick up MY_FOO
@Infinisil if you mean to bindgen's CLI, you can pass as many flags as you want
@Infinisil Of the form of `bindgen <bindgen-flag>.. -- <clang-flag>..
Otherwise you need a build script
Err, otherwise you need to handle it yourself from the build script, I mean
Josh Hejna
@Lytigas
I don't know if this is the right place to ask for help, but its all I could find in the docs. I have some (unfortunately) C++-only headers that have non-bindgen-compatible features (Unhandled cursor kind 400) But I only want bindings for stuff in extern "C" {} blocks in the headers. Any way to do that?
Théo Degioanni
@Moxinilian
Hello!
I've been experiencing issues with bindgen on iOS.
https://github.com/Moxinilian/coreaudio-sys/blob/master/build.rs
I'm currently updating this so that it works on iOS, but unfortunately while generating the bindgens, I get the cryptic error thread 'main' panicked at 'TranslationUnit::parse failed', libcore/option.rs:917:5
However I noticed this crate was running on bindgen 0.32, so I updated it to 0.36 but it seems that the API changed and builder.link_framework(absolute_path); apparently is missing. I could not find what replaced it, does it still exist?
Thanks in advance!
Théo Degioanni
@Moxinilian
Apparently, even if I don't link the frameworks i get the exact same errors. Do you think I should open an issue maybe?
Hans W. Uhlig
@huhlig
oh...
I may know why
Théo Degioanni
@Moxinilian
Hm?
Hans W. Uhlig
@huhlig
What version of clang is bindgen based on
vs what version of clang is xcode based on
Théo Degioanni
@Moxinilian
Oh no
Hans W. Uhlig
@huhlig
are there any constructs or syntax updates that either apple or newer clang has made
Hans W. Uhlig
@huhlig
Question... When doing bindgen, shouldn't clang be using the target triple for generating bindings and not the host triple https://gist.github.com/huhlig/767b57376d598462d6457c5774a64e8b
Patrick Brown
@patrickbrownsync

Hi,

I’m building off this project https://github.com/jamesmunns/teensy3-rs which is using bindgen to create bindings for teensy3 libraries (a micro controller).

I am trying to add a new library ( https://github.com/PaulStoffregen/OctoWS2811
), and create safe wrappers around the functionality. However it fails linking: linking witharm-none-eabi-gccfailed: exit code: 1
with a few undefined reference issues, like this one: teensy3_wall1-a1c9b6821d0c6eb7910efb36c11e12e2.rs:(.text.main+0x54): undefined reference toOctoWS2811::getPixel(unsigned int)'`

Seems like this might be a mangling issue, my OctoWS2811.o seems to have the name as _ZN10OctoWS28118getPixelEm and my generated bindings have _ZN10OctoWS28118getPixelEj but I don’t know why. I’ve seen issues relating to older clang versions, but I am on 3.9.

Any ideas on how to fix this?

Colin Valliant
@alcarithemad
How does bindgen decide to make a type opaque? I'm trying to generate some bindings from MacOS kernel headers and having a problem where 2 of 3 related structs are being bound with _bindgen_opaque_blob as their only field
vthriller
@vthriller

@emilio

@vthriller You can work around it doing const u_int MY_FOO = FOO in a header of yours. Bindgen should pick up MY_FOO

hey there, I just found some time to try this workaround and it doesn't quite work with typedefs, e.g.

// definitions from header files
typedef u_int path_id_t;
#define      CAM_XPT_PATH_ID ((path_id_t)~0)
// my own line in bindgen.h
const path_id_t bindgen_CAM_XPT_PATH_ID = CAM_XPT_PATH_ID;

results in

pub type u_int = ::std::os::raw::c_uint;
// …
pub type path_id_t = u_int;
// …
extern "C" {
    #[link_name = "bindgen_CAM_XPT_PATH_ID"]
    pub static bindgen_CAM_XPT_PATH_ID: path_id_t;
}

which is not what I want. am I missing something?

that's on 0.26.3 btw; I bumped bindgen to 0.37.0 and it emitted something weird (namely, \u{1}):
extern "C" {
    #[link_name = "\u{1}bindgen_CAM_XPT_PATH_ID"]
    pub static mut bindgen_CAM_XPT_PATH_ID: path_id_t;
}
vthriller
@vthriller
(well, I just realized I might try to define bindgen_CAM_XPT_PATH_ID as const u_int or whatever that u_int is an alias for, but it'd be really nice to not spend time on finding out what's the actual type of yet another whatever_t. should probably file github ticket at this point)
vthriller
@vthriller
oh great, I found https://github.com/rust-lang-nursery/rust-bindgen/issues/1316#issuecomment-390420764 :\ now go figure what IRC channel that was and whether its logs are available online…
Michael Mauderer
@MichaelMauderer

Hi all. I'm trying to create bindings for socket.io-cpp through bindgen and I'm running into trouble with a destructor of the client class. The destructor doesn't seem to be virtual

<snip>
 client();
 ~client();
<snip>

I'm seeing this linking error: libsocket_io_cpp-a45078ed8cdc214c.rlib(socket_io_cpp-a45078ed8cdc214c.2ig1rlai5fytur6s.rcgu.o) : error LNK2019: unresolved external symbol "public: void __cdecl sio::client::`vbase destructor'(void)" (??_Dclient@sio@@QEAAXXZ) referenced in function _ZN13socket_io_cpp8bindings4root3sio6client8destruct17ha165cf9bb3593cbbE

The generated bindings for the destructor look like this:

        extern "C" {
            #[link_name = "\u{1}??_Dclient@sio@@QEAAXXZ"]
            pub fn client_client_destructor(this: *mut root::sio::client);
        }

And I'm using these build options:

        .enable_cxx_namespaces()
        .conservative_inline_namespaces()
        .whitelist_type("sio::client")
        .opaque_type("std::.*")
        .whitelist_type("std::string")
        .whitelist_function("helper::.*")
        .whitelist_type("sio::socket::ptr")
        .whitelist_type("std::shared_ptr")
        .whitelist_type("std::nullptr_t")
        .trust_clang_mangling(true)
        .generate_inline_functions(false)
Michael Mauderer
@MichaelMauderer
Switching to .trust_clang_mangling(false) leads to other symbols not being found
libsocket_io_cpp-a45078ed8cdc214c.rlib(socket_io_cpp-a45078ed8cdc214c.2ig1rlai5fytur6s.rcgu.o) : error LNK2019: unresolved external symbol emit referenced in function _ZN13socket_io_cpp8bindings4root3sio6socket4emit17h41684459fdf6a655E
          libsocket_io_cpp-a45078ed8cdc214c.rlib(socket_io_cpp-a45078ed8cdc214c.2ig1rlai5fytur6s.rcgu.o) : error LNK2019: unresolved external symbol client referenced in function _ZN13socket_io_cpp8bindings4root3sio6client3new17hec7f4c6c2a89b45eE
          libsocket_io_cpp-a45078ed8cdc214c.rlib(socket_io_cpp-a45078ed8cdc214c.2ig1rlai5fytur6s.rcgu.o) : error LNK2019: unresolved external symbol client_destructor referenced in function _ZN13socket_io_cpp8bindings4root3sio6client8destruct17ha165cf9bb3593cbbE
Nick Cameron
@nrc
We've created a wg-bindgen channel in the dev-tools group on Discord. You can join here: https://discordapp.com/invite/rust-lang
Ingvar Stepanyan
@RReverser
one more messenger :scream:
Dmitry Kozlovtsev
@non-descriptive
dropbox link in chat description outdated
Douman
@DoumanAsh
Sorry to bump into here, but I'm curious is there any plans for featuring option to configure whether to use signed/unsigned integers for #define <name> <value>? It seems current bindgen generates unsigned for all positive integers
signed integer also makes more sense for defines
Emilio Cobos Álvarez
@emilio
Douman
@DoumanAsh
Yep thx, I found it later, thoguh I think using unsigned integer for defines in first place is wrong for bindgen
since in both C and C++ defines are just literals and often int
Mikko Lehtonen
@scoopr
Hello :wave:
I somehow missed this gitter room :)
Alexandru Ene
@AlexEne
Hi all

Just a quick question:

    let bindings = bindgen::Builder::default()
        .header("vendor/some_header.h")
        .rustfmt_bindings(true)
        .layout_tests(false)
        .generate()
        .expect("Unable to generate bindings");
    bindings.write_to_file("file.rs");

Doing this with or without rustfmt_bindings(true) makes no difference.

Am I not using that flag correctly?
Runnning the RLS-provided rustfmt on the genrated file on vs code arranges all the constants usually found at the top of generated bindings.
Matt Jadczak
@mjadczak
Does anyone know what happened to the bindgen user's guide?
Bruce Mitchener
@waywardmonkeys
@mjadczak ^
Matt Jadczak
@mjadczak
thanks!
inzanez
@inzanez
hi