On Tue, Sep 14, 2021 at 6:21 AM Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> wrote: > > I've also run into downstream patches around broken toolchains that > change <libusb.h> to <libusb-1.0/libusb.h>, so the header is found. How does this become a problem exactly? If the toolchain has the file in the location <includedir>/ibusb-1.0/libusb.h, then shouldn't pkg-config --cflags have returned -I<includedir>/libusb-1.0 and it would then find the file just fine? Or is the problem really that the cross building setup does not have correct .pc files? If it's the latter, then I'll point out that my previous email would let someone put CROSS_LIBUSB_CFLAGS=-I<cross-include-dir>/libusb-1.0 on the make command line and get a build without having .pc files. This is pretty much what you get with autoconf configure scripts when you put headers in a non-standard place and don't have .pc files setup to find them. You need to supply CFLAGS, LDFLAGS, etc. variables with the proper -L and -I options to find them. > +++ b/scripts/libusb.h By naming this libusb.h, it requires that "libusb.h" find this file and <libusb.h> find a different header of the same name. That's certainly possible by being careful with the "" and <> search paths. But it seems unnecessarily fragile. I suggest using libusb-wrapper.h for this file so you avoid name collisions with the real header file. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox