Skip to content

Cannot build with libbpf-sys 1.1.0 #303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
krallin opened this issue Jan 9, 2023 · 9 comments
Closed

Cannot build with libbpf-sys 1.1.0 #303

krallin opened this issue Jan 9, 2023 · 9 comments
Assignees

Comments

@krallin
Copy link

krallin commented Jan 9, 2023

Like it says in the title. A new version of libbpf-sys 1.1.0 was released and breaks this crate:

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
  --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/map.rs:39:43
   |
39 |                 data.len() as libbpf_sys::size_t,
   |                                           ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
  --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/object.rs:42:83
   |
42 |             sz: mem::size_of::<libbpf_sys::bpf_object_open_opts>() as libbpf_sys::size_t,
   |                                                                                   ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/object.rs:100:42
    |
100 |                 mem.len() as libbpf_sys::size_t,
    |                                          ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/perf_buffer.rs:114:43
    |
114 |                 self.pages as libbpf_sys::size_t,
    |                                           ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/perf_buffer.rs:175:86
    |
175 |             libbpf_sys::perf_buffer__consume_buffer(self.ptr, buf_idx as libbpf_sys::size_t)
    |                                                                                      ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/perf_buffer.rs:186:90
    |
186 |             unsafe { libbpf_sys::perf_buffer__buffer_fd(self.ptr, buf_idx as libbpf_sys::size_t) };
    |                                                                                          ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/program.rs:308:44
    |
308 |                 func_offset as libbpf_sys::size_t,
    |                                            ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
  --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/tc.rs:50:89
   |
50 |         tc_hook.hook.sz = std::mem::size_of::<libbpf_sys::bpf_tc_hook>() as libbpf_sys::size_t;
   |                                                                                         ^^^^^^ not found in `libbpf_sys`

error[E0412]: cannot find type `size_t` in crate `libbpf_sys`
  --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/tc.rs:51:89
   |
51 |         tc_hook.opts.sz = std::mem::size_of::<libbpf_sys::bpf_tc_opts>() as libbpf_sys::size_t;
   |                                                                                         ^^^^^^ not found in `libbpf_sys`

error[E0308]: mismatched types
  --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/ringbuf.rs:68:67
   |
68 |         let c_sample_cb: libbpf_sys::ring_buffer_sample_fn = Some(Self::call_sample_cb);
   |                                                                   ^^^^^^^^^^^^^^^^^^^^ expected `usize`, found `u64`
   |
   = note: expected fn pointer `unsafe extern "C" fn(_, _, usize) -> _`
                 found fn item `unsafe extern "C" fn(_, _, u64) -> _ {RingBufferBuilder::<'_>::call_sample_cb}`

error[E0308]: mismatched types
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/skeleton.rs:172:17
    |
172 |             sz: size_of::<bpf_object_skeleton>() as c_ulong,
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `usize`, found `u64`

error[E0308]: mismatched types
   --> /home/torozco/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-rs-0.19.1/src/skeleton.rs:182:21
    |
182 |         s.data_sz = self.data.len() as c_ulong;
    |         ---------   ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `usize`, found `u64`
    |         |
    |         expected due to the type of this binding

Some errors have detailed explanations: E0308, E0412.
For more information about an error, try `rustc --explain E0308`.

I'm guessing a new release of this crate is forthcoming considering they're maintained by the same organization, but until then perhaps this one can be pinned to the version of libbpf-sys it requires?

@mimullin-bbry
Copy link
Contributor

#304

Build is failing because the time crate now requires a minimum rust version of 1.60

@danielocfb
Copy link
Collaborator

That is a very unfortunate semver violation, it appears. It seems to have been caused by libbpf/libbpf-sys@aa4a577#diff-c030113407a164cbd1ad3500c613f59abd4346ba13ee5b653c56f393c937b0a8L317

@alexforster can you please clarify whether libbpf-sys intends to follow semver versioning rules? Or is the assumption that we should be pinning the version we consume?

@danielocfb danielocfb self-assigned this Jan 9, 2023
@danielocfb
Copy link
Collaborator

@krallin I think you should be able to pin libbpf-sys from your code base as a work around.

But yeah, we probably want a new release or a yank of the latest libbpf-sys release. I will wait for @alexforster to get back to us first, though, to get his take.

@krallin
Copy link
Author

krallin commented Jan 9, 2023 via email

@alexforster
Copy link
Member

alexforster commented Jan 9, 2023

@alexforster can you please clarify whether libbpf-sys intends to follow semver versioning rules?

Yes, at least insofar as libbpf itself does.

I'll yank this version of libbpf-sys and figure out what's up. I bumped the version of bindgen and maybe that messed things up.

@alexforster
Copy link
Member

Looks like they changed a default behavior in rust-lang/rust-bindgen#2278. Fortunately, it looks like there's an escape hatch to revert to previous behavior.

@alexforster
Copy link
Member

Published 1.1.1+v1.1.0, and the diff from 1.0.4+v1.0.1 looks more reasonable this time around:

https://github.com/libbpf/libbpf-sys/compare/86d135b2aa27fbea4d2e1a01832bf18ab5f9e8b0..bdfb1d2c4d1b01fadb20270b5744d7c29e2c16c9

@mimullin-bbry
Copy link
Contributor

#306

This reverts the changes commited to compile against libbpf-sys 1.1.0 and updates libbpf-rs and libbpf-cargo to use libbpf-sys 1.1.1

danielocfb pushed a commit to danielocfb/libbpf-sys that referenced this issue Jan 11, 2023
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior.
To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent version of libbpf-rs with the
current libbpf-sys.

[0] libbpf/libbpf-rs#303
danielocfb pushed a commit to danielocfb/libbpf-sys that referenced this issue Jan 11, 2023
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: libbpf#53
danielocfb pushed a commit to danielocfb/libbpf-sys that referenced this issue Jan 11, 2023
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: libbpf#53
Signed-off-by: Daniel Müller <[email protected]>
@danielocfb
Copy link
Collaborator

I think we can close this issue, as the breakage has been addressed. I've proposed the addition of a CI step to detect and flag such breakages early on the libbpf-sys side, as per Alex' suggestion. If merged, that should help prevent similar issues in the future.

alexforster pushed a commit to libbpf/libbpf-sys that referenced this issue Jan 26, 2023
libbpf-sys aims to adhere to semantic versioning rules and indicate
incompatible changes by bumping major version numbers. However, it is
sometimes hard to identify breaking changes in advance and so breakage
may happen unintentionally. Detecting of such breaking changes also
becomes harder with auto-generated code, and libbpf-sys has a bunch of
that, owing due to it binding to a C library. For example, in libbpf-rs
[0] we have encountered a case where we were relying on a bindgen
generated type exported by libbpf-sys that got removed because bindgen
changed its behavior, which effectively is a semver violation.

To aid with the detection such unintended incompatibilities, this change
adds a CI step that builds the most recent published version of
libbpf-rs with the current libbpf-sys snapshot, to flag accidental
breakage.

[0] libbpf/libbpf-rs#303

Closes: #53
Signed-off-by: Daniel Müller <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants