`bindgen` and Windows build (for conda-forge packet manager)

[jcamiel]

Hi, I'm one of the maintainer of a Hurl, happy user of the libxml crates since a few years.

This issue is just for getting some advices and help, fell free to close it after discussion!

Hurl is avaible as packet for many platforms and we've just published a new version 7.0.0. This new version uses libxml and, for the first time, the "bindgen way" of generating the libxml binding.
For the moment, everythin looks OK (for instance, on macOS, Hurl 7.0.0 is available through brew without anny issue apart adding a new dependency on libclang).

Hurl is also available for macOS (arm64 & x86), Linux (arm64 & x86) and Windows (x86) through conda-forge.

For the 7.0.0 update, I strugle to make the new conda-forge version: evrything is OK for Linux and macOS, but the conda-forge "recipe" (a declarative file about how to build Hurl) is not builing on Windows.

You can see some logs here, the gist of it is this kind of error when trying to build libxml crate:

error[E0080]: evaluation of constant value failed
    --> D:\bld\hurl_1753997882865\work\target\release\build\libxml-71faa281837ea7b0\out/bindings.rs:5008:37
     |
5008 |   ["Size of _xmlParserNodeInfoSeq"][::std::mem::size_of::<_xmlParserNodeInfoSeq>() - 24usize];
     |                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `16_usize - 24_usize`, which would overflow

In the binding.rs file, this corresponds to this check on struct layout:

#[repr(C)]
#[derive(Debug, Copy, Clone)]
pub struct _xmlParserNodeInfoSeq {
  pub maximum: ::std::os::raw::c_ulong,
  pub length: ::std::os::raw::c_ulong,
  pub buffer: *mut xmlParserNodeInfo,
}
#[allow(clippy::unnecessary_operation, clippy::identity_op)]
const _: () = {
  ["Size of _xmlParserNodeInfoSeq"][::std::mem::size_of::<_xmlParserNodeInfoSeq>() - 24usize];
  ["Alignment of _xmlParserNodeInfoSeq"][::std::mem::align_of::<_xmlParserNodeInfoSeq>() - 8usize];
  ["Offset of field: _xmlParserNodeInfoSeq::maximum"]
    [::std::mem::offset_of!(_xmlParserNodeInfoSeq, maximum) - 0usize];
  ["Offset of field: _xmlParserNodeInfoSeq::length"]
    [::std::mem::offset_of!(_xmlParserNodeInfoSeq, length) - 8usize];
  ["Offset of field: _xmlParserNodeInfoSeq::buffer"]
    [::std::mem::offset_of!(_xmlParserNodeInfoSeq, buffer) - 16usize];
};

What I understand (I'm clearly not in my comfort zone) is that the binding.rs check expects that ::std::os::raw::c_long is 8 bytes, whereas, as I understand, ::std::os::raw::c_long should be 4 bytes on Windows targets with msvc compiler, which conda-forge uses.

My questions:

• in your comprehension, is it normal that this check fails for Windows and msvc compiler? I know that you build in CI for Windows target so I strugle to understand why this check can't pass on conda-forge CI/CD
• if I manage to disable this check (I think I can patch the Hurl recipe to set .layout_tests(false) in libxml crate build.rs), it will compile (I hope) but will it work ? Will the Hurl binary panic as soon as it uses libxml call?
• apart from patching some code, do you see anything I can try to make the build work

Once again, this is not an issue, just a request for advice and recommendation. Any help even minimal is welcome,

Thanks a lot!

Jc

[jcamiel]

Something that I miss I that I'm building on Windows by configuring the LIBXML2 env. In that case, the returned binding.rs is the scr/default_binding.rs:

rust-libxml/build.rs

Lines 10 to 41 in 9245d4c

	fn find_libxml2() -> Option<ProbedLib> {
	#![allow(unreachable_code)] // for platform-dependent dead code
	if let Ok(ref s) = std::env::var("LIBXML2") {
	// println!("{:?}", std::env::vars());
	// panic!("set libxml2.");
	let p = std::path::Path::new(s);
	let fname = std::path::Path::new(
	p.file_name()
	.unwrap_or_else(|| panic!("no file name in LIBXML2 env ({s})")),
	);
	assert!(
	p.is_file(),
	"{}",
	&format!("not a file in LIBXML2 env ({s})")
	);
	println!(
	"cargo:rustc-link-lib={}",
	fname
	.file_stem()
	.unwrap()
	.to_string_lossy()
	.strip_prefix("lib")
	.unwrap()
	);
	println!(
	"cargo:rustc-link-search={}",
	p.parent()
	.expect("no library path in LIBXML2 env")
	.to_string_lossy()
	);
	None

• is there a reason why we can't call <generate_bindings> etc... if we use LIBXML2 ?
• the scr/default_binding.rs is only for Linux / macOS.... architecture where unsigned long == 8 bytes right ? That would explain why the check are failing when using LIBXML2 on windows

[jcamiel]

Just FYI I've solved my build on Windows by patching the file default_binding.rs with a binding generated with libxml 2.13.8 on Windows.

My two cents on how we can improve the build using LIBXML2 env var:

• maybe have two default_binding.rs, one for those where unsigned long is 4 bytes, one for thos where unsigned long is 8 bytes
• if possible (?) use bindgen also even if we set LIBXML2
• is using LIBXML2 don't assume version is older than 2.12

It's simple to propose enhancement, it's harder to code them :)

Thanks for the crate