Inflation

> I see, going from the error log I assume the issues to be cause by the calls to `__builtin_cpu_supports` in here https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_fast_lossless.cc#L4176 - would you be able to test...

It seems your compiler doesn't have threads support, which is surprising. `libjxl` uses C++ standard library for threads and etc.

> My compiler is fine, and I can build libjxl from source myself which is what I'm using to work around the broken vendored feature. Whatever jpegxl-rs is doing is...

> That seems to break as well, seems like it might be a GCC14/clang18 change https://gcc.gnu.org/gcc-14/porting_to.html#header-dep-changes, anyway I guess it's a libjxl bug rather than a jpegxl-rs bug. Try `BUILD_SHARED_LIBS=OFF`...

> `cmake -DJPEGXL_STATIC=on -DBUILD_SHARED_LIBS=off` runs into the same error. Without `JPEGXL_STATIC=ON`

@veluca93 Try `fix/macos` branch or #57, it may solve the build problem on macOS. @awused I've switched to that option on master.

> Dear apple experts, do you know if macOS expects dylib symbol names with an underscore prefix? Yes. dyld expects anything beyond assembly procedures starts with an underscore prefix.

quinn's Connection uses Arc under the hood, so if you're holding MutexGuard now, you probably will hold the guard when locking internal states too.

I prefer to make `explicit=true` the default behavior, since the first foot gun in the current situation after adding `extra-index-url`, are packages in the `pytorch` channel taking precedence over `pypi`.

Yes, I would prefer to not introduce another dependency for such a small change. Also, the encoding speed enum is from `libjxl` and could add extra validation upon usage. I'm...