Cargo update broke my build process: cannot find function clang_CXXMethod_isVirtual

After running cargo update for mmtkvdb I got this:

% cargo update
    Updating crates.io index
    Updating clang-sys v1.4.0 -> v1.5.1
    Updating either v1.8.0 -> v1.8.1
    Updating nom v7.1.2 -> v7.1.3
    Updating proc-macro2 v1.0.49 -> v1.0.51
    Updating which v4.3.0 -> v4.4.0
% cargo clean
% cargo build
   Compiling memchr v2.5.0
   Compiling glob v0.3.1
   Compiling libc v0.2.139
   Compiling proc-macro2 v1.0.51
   Compiling unicode-ident v1.0.6
   Compiling quote v1.0.23
   Compiling cfg-if v1.0.0
   Compiling syn v1.0.107
   Compiling log v0.4.17
   Compiling minimal-lexical v0.2.1
   Compiling either v1.8.1
   Compiling bindgen v0.63.0
   Compiling regex-syntax v0.6.28
   Compiling shlex v1.1.0
   Compiling bitflags v1.3.2
   Compiling rustc-hash v1.1.0
   Compiling lazy_static v1.4.0
   Compiling lazycell v1.3.0
   Compiling peeking_take_while v0.1.2
   Compiling deref_owned v0.10.2
   Compiling libloading v0.7.4
   Compiling clang-sys v1.5.1
   Compiling nom v7.1.3
   Compiling which v4.4.0
   Compiling regex v1.7.1
   Compiling cexpr v0.6.0
error[E0425]: cannot find function `clang_CXXMethod_isVirtual` in this scope
    --> /home/jbe/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.63.0/clang.rs:822:18
     |
822  |           unsafe { clang_CXXMethod_isVirtual(self.x) != 0 }
     |                    ^^^^^^^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `clang_CXXMethod_isPureVirtual`
     |
    ::: /home/jbe/.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-1.5.1/src/lib.rs:1735:1
     |
1735 | / link! {
1736 | |     pub fn clang_CXCursorSet_contains(set: CXCursorSet, cursor: CXCursor) -> c_uint;
1737 | |     pub fn clang_CXCursorSet_insert(set: CXCursorSet, cursor: CXCursor) -> c_uint;
1738 | |     pub fn clang_CXIndex_getGlobalOptions(index: CXIndex) -> CXGlobalOptFlags;
...    |
2289 | |     pub fn clang_VerbatimLineComment_getText(comment: CXComment) -> CXString;
2290 | | }
     | |_- similarly named function `clang_CXXMethod_isPureVirtual` defined here

For more information about this error, try `rustc --explain E0425`.
error: could not compile `bindgen` due to previous error

My system setup:

% freebsd-version
13.1-RELEASE-p5
% clang --version 
FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303)
Target: x86_64-unknown-freebsd13.1
Thread model: posix
InstalledDir: /usr/bin

What can I do?

The problem seems to be solved now as clang-sys 1.5.1 and 1.5.0 got yanked. cargo update now performed a downgrade automatically:

% cargo update
    Updating crates.io index
    Updating clang-sys v1.5.1 -> v1.4.0
% cargo build
   Compiling clang-sys v1.4.0
   Compiling bindgen v0.63.0
   Compiling mmtkvdb v0.9.1 (/usr/home/jbe/repos/mmtkvdb)
    Finished dev [unoptimized + debuginfo] target(s) in 6.64s

So I guess the issue is known already and solved.

1 Like

I wonder how many people can break (or repair) my builds by pressing a "yank"/"unyank" button somewhere. I would assume that this number is scaringly big, but I guess that's natural when you have a lot of dependencies. Opposed to publishing new crates, however, yanking/unyanking doesn't get documented anywhere though, right?

Yanking a crate doesn't break the build of anyone who already has the yanked version in their lockfile.

I know that, but libraries aren't usually shipped with a Cargo.lock file. And even if cargo build doesn't break, cargo update with a following cargo build does.


My point is that yanking/unyanking probably should be made transparent (i.e. publicly recorded) in some way. It might be used to introduce security relevant bugs/backdoors also.


This is an even more sensitive issue considering that accounts can be hacked. I don't think I even get a private notify myself or record of some kind if one of my crates is yanked/unyanked (by my own account).

Yanked versions are still visible and marked as yanked on crates.io: https://crates.io/crates/clang-sys/versions

You could argue that's not discoverable enough, though.

That's not enough, as on that page it's (currently) not visible whether a crate has been yanked or unyanked in the past.

An attacker could temporarily yank a bugfix for a certain period and then unyank it again, leaving seemingly no traces (as yanking history isn't shown in the GUI). There might be more situations where yanking/unyanking could be used to craft an attack. For example, by yanking, I could pinpoint anyone using tokio = { version = "1" } to any published 1.x.x version of tokio. Thus if there's just a single version with a flaw in the version history, I could exploit that.

However, I just learned that the yanking/unyanking history is indeed published (not through the GUI though). It's available at https://crates.io/api/v1/crates/clang-sys/1.5.1 for example. So there is a recording of who yanks/unyanks a crate. This diminishes the risk of unnoticed/untracable attacks through yanking/unyanking (i.e. the data for auditing such things is available).

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.