1826812 - Crates using a `build.rs` (specifically with bindgen) should be provided with the mozbuild toolchain libraries at build script runtime

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Alex Franchuk [:afranchuk]]

bindgen is compiled against the mozbuild toolchain, which means it will need whichever libclang version that's in the toolchain when it's linked and run within a build.rs. Right now, the build.rs executables resolve dependent shared libraries using system libraries, so I found out the hard way that my system libclang was a bit old.

If we could figure out a way to use the mozbuild toolchain when running build.rs executables that would be ideal. On linux, maybe LD_LIBRARY_PATH would be sufficient; unfortunately I doubt there's a way to add e.g. rpaths only when compiling the build scripts, but if there is that would be even cleaner.

Comment 1

[Mike Hommey [:glandium]]

It's supposed to use the right libclang via LIBCLANG_PATH.

Comment 2

[Alex Franchuk [:afranchuk]]

If I'm not mistaken, that is functioning correctly. According to the clang-sys docs, it uses LIBCLANG_PATH at compile time to find the library. That is working because the resulting build.rs executable is referencing libclang.so.15 (which, at the time, was only in the mozbuild toolchain). But the build.rs executable then has a NEEDED entry for just libclang.so.15 (rather than for example the full path), which fails to resolve when it is run.

Comment 3

[Mike Hommey [:glandium]]

then has a NEEDED entry for just libclang.so.15

It's not supposed to. In fact, it doesn't on my machine. Do you have local changes?

Comment 4

[Alex Franchuk [:afranchuk]]

My local changes are the addition of a new crate (gtkbind) which uses bindgen. This is user error; I needed the runtime feature (or static would probably work too if the toolchain includes the static libs) so that it doesn't link to the shared object at compile time.