Cargo update broke my build process: cannot find function clang_CXXMethod_isVirtual

After running cargo update for mmtkvdb I got this:

% cargo update
    Updating 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/
822  |           unsafe { clang_CXXMethod_isVirtual(self.x) != 0 }
     |                    ^^^^^^^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `clang_CXXMethod_isPureVirtual`
    ::: /home/jbe/.cargo/registry/src/
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
% clang --version 
FreeBSD clang version 13.0.0 ( 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 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

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 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.