Hi. On Sun, May 17, 2009 at 08:11:06PM +0200, Samuel Thibault wrote: > > A lot of packages depend on libusb, and more and more do. It seems to > me illusory to try to make them all include [!hurd-i386] conditionals, > it'd be easier to just manage to compile libusb, even if it's only to > always report that no device is available. > > Now the problem is that PATH_MAX appears in libusb's usb.h...: > > struct usb_device { > struct usb_device *next, *prev; > > char filename[PATH_MAX + 1]; > ... > > And applications often do use that field, for outputing debugging > message apparently. I can see several solutions: > > - patch libusb into not having the field. Completely safe option, but > quite a few applications won't build, notably some that are big > blockers like pcsc-lite. > - patch libusb into using a char *filename instead. Applications might > have been using sizeof(dev->filename) and get wrongly compiled. > - like in libusb-win32, patch libusb into defining a LIBUSB_PATH_MAX > constant to some arbitrary value and use that instead. Some > applications might still be using the PATH_MAX constant, but we do not > define it anyway, so it should be safe. > - just wait for libusb-1.0 that has a PATH_MAX-free interface. That's > not for tomorrow, as the interface is very different from the legacy > libusb and thus applications will have to be fixed one by one. > > What do people think? I believe the 3rd solution uploaded to > debian-ports could be a safe interim clearing the way for porting.
Would this field even be used at runtime given that we don't have any devices? In that case we could just remove the PATH_MAX. Regards, Fredrik -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org