Menu
▾
▴
libusb-devel
|
From: Adam N. <a.n...@sh...> - 2010-11-21 03:31:13
|
Hi all, I'm somewhat new to USB programming in general, and I am in the process of porting an application from using Windows APIs to libusb. So far it mostly works, except for one issue I'm a little confused about. When I call libusb_bulk_transfer to receive data, the buffer that gets passed in is 5.4MB in size. libusb_bulk_transfer fails immediately with the return code -99, which seems to indicate an unknown/other error. I can't find anything in the docs about a limit on the buffer size, so I am not sure what this means. If I override the app's length field and tell libusb_bulk_transfer it's only a few kilobytes in size then it seems to work fine, however what confuses me is that if the length is set to 300-400k then I can call libusb_bulk_transfer a few times before it fails. Does this mean there's some internal caching/buffering going on, and eventually I will get the same failures with small buffers too? On a related note, running the Windows version of this application through VirtualBox causes the same failure, so VirtualBox appears to be passing the 5.4MB buffer through as-is, causing the same libusb error. The app works under native Windows though, so if there is an undocumented buffer limit perhaps it is worth enforcing it in libusb? Thanks, Adam. |
|
From: Michael P. <mic...@gm...> - 2010-11-21 04:33:51
|
Adam Nielsen wrote: >> When I call libusb_bulk_transfer to receive data, the buffer that gets passed >> in is 5.4MB in size. libusb_bulk_transfer fails immediately with the return >> code -99, which seems to indicate an unknown/other error. Immediately? That seems odd. What does the debug log show? I believe Pete has posted instructions on enabling debug logging by a function call in his custom binaries, if you're using those (libusb_set_debug(context, 4);). >> The app works >> under native Windows though, so if there is an undocumented buffer limit >> perhaps it is worth enforcing it in libusb? When you say "native", do you mean WinUSB (e.g., WinUsb_ReadPipe/WinUsb_WritePipe), or some other "native" API? Michael |
|
From: Pete B. <pb...@gm...> - 2010-12-01 19:15:55
|
Peter, Can you tell where [1] comes from, and if this was ever tested on cygwin? If Windows specific patches like this one are being introduced without being properly tested (haven't tested MSVC, since we don't have the project files), this is going to be a major headache. Or at least, please submit it as a proposal to the list so that I can try to test it. I'm only realizing now that you have added a lot of changes in your tree that were never publicly debated on the list. Even as one of the libusb maintainers, if you want to integrate some non trivial changes into official, please try to submit a patch on the mailing list for review. I'm afraid keeping all of MinGW, MSVC and cygwin happy at the same time is almost never straightforward, no matter how simple the patch might look, so for now, I'd suggest we revert this change (if it ain't broke...), and spend time on the rest of the integration instead. If I have a chance, I'll see if I can pick up your patch, and fix it for my branch, so that you get it back when official catches up. Regards, /Pete [1] http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=e01877bec72eddeb314e1caf4047ee424d18ce66;js=1 |
|
From: Adam N. <a.n...@sh...> - 2010-11-21 12:49:18
|
>> libusb_bulk_transfer fails immediately with the return >>> code -99, which seems to indicate an unknown/other error. > > Immediately? That seems odd. What does the debug log show? I believe Pete > has posted instructions on enabling debug logging by a function call in his > custom binaries, if you're using those (libusb_set_debug(context, 4);). Thanks for the quick reply, I'll see if I can work it out. I'm running Gentoo, so building from source. Yes it fails immediately, although when I shrink the buffer size and the call succeeds it's so fast I couldn't really say either way. >>> The app works >>> under native Windows though, so if there is an undocumented buffer limit >>> perhaps it is worth enforcing it in libusb? > > When you say "native", do you mean WinUSB (e.g., > WinUsb_ReadPipe/WinUsb_WritePipe), or some other "native" API? Sorry, by native I mean when Windows is running on real hardware. It only breaks when Windows is running inside VirtualBox, which as far as I'm aware, uses libusb for its pass-through USB support. But yes, the app under Windows uses WinUSB. Thanks, Adam. |
|
From: Michael P. <mic...@gm...> - 2010-11-21 13:29:04
|
Adam Nielsen wrote: >> >>> libusb_bulk_transfer fails immediately with the return >> >>> code -99, which seems to indicate an unknown/other error. >> > >> > Immediately? That seems odd. What does the debug log show? I believe Pete >> > has posted instructions on enabling debug logging by a function call in his >> > custom binaries, if you're using those (libusb_set_debug(context, 4);). >> >> I'm running >> Gentoo, so building from source. Yes it fails immediately, although when I >> shrink the buffer size and the call succeeds it's so fast I couldn't really >> say either way. Ok, I think the key to making that function call work is that he uses ./configure --enable-toggable-debug (but the function of this has changed a few times, and I'm not sure what state it's in right now). Pete may be able to guide further here. I assume you're building from libusb-pbatard.git, not libusb.git, right? The latter is significantly behind. >> Sorry, by native I mean when Windows is running on real hardware. It only >> breaks when Windows is running inside VirtualBox, which as far as I'm aware, >> uses libusb for its pass-through USB support. Ah, I missed that part, sorry. I was thrown off by the part "I am in the process of porting an application from using Windows APIs to libusb." Regards, Michael |
|
From: Adam N. <a.n...@sh...> - 2010-11-22 22:09:54
|
> Ok, I think the key to making that function call work is that he uses
>
> ./configure --enable-toggable-debug
>
> (but the function of this has changed a few times, and I'm not sure what
> state it's in right now). Pete may be able to guide further here.
>
> I assume you're building from libusb-pbatard.git, not libusb.git, right?
> The latter is significantly behind.
I have built libusb-pbatard.git and linked it to the app, this is the
problematic call:
int status = libusb_bulk_transfer(this->hdev, LIBUSB_ENDPOINT_IN |
LIBUSB_RECIPIENT_ENDPOINT, buf, blen, &rxlen, DEF_USBTIMEOUT);
Which only fails if blen is greater than about 256000. This is the debug
output I get for this call only:
libusb:debug [submit_bulk_transfer] need 328 urbs for new transfer with length
5370447
libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=121
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1500ms (first
in line)
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-121 transferred=3215
libusb:debug [handle_bulk_completion] handling completion status -121 of bulk
urb 1/328
libusb:debug [handle_bulk_completion] abnormal reap: urb status -121
libusb:debug [handle_bulk_completion] received 3215 bytes of surplus data
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk
urb 2/328
libusb:debug [handle_bulk_completion] abnormal reap: urb status -104
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk
urb 3/328
libusb:debug [handle_bulk_completion] abnormal reap: urb status -104
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk
urb 4/328
libusb:debug [handle_bulk_completion] abnormal reap: urb status -104
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk
urb 5/328
libusb:debug [handle_bulk_completion] abnormal reap: urb status -104
libusb:debug [libusb_handle_events_timeout_check] doing our own event handling
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk
urb 6/328
...
FWIW I've seen another person report the same problem (but with VirtualBox) on
a Mac and a Linux PC.
Let me know if/where you need debug output from next.
Thanks,
Adam.
|
|
From: Peter S. <pe...@st...> - 2010-11-22 22:17:46
|
Adam Nielsen wrote: > > I assume you're building from libusb-pbatard.git, not libusb.git, right? > > The latter is significantly behind. This is true for Windows support only. > I have built libusb-pbatard.git and linked it to the app, this is the > problematic call: > > int status = libusb_bulk_transfer(this->hdev, LIBUSB_ENDPOINT_IN | > LIBUSB_RECIPIENT_ENDPOINT, buf, blen, &rxlen, DEF_USBTIMEOUT); > > Which only fails if blen is greater than about 256000. This is the debug > output I get for this call only: > > libusb:debug [submit_bulk_transfer] need 328 urbs for new transfer with length > 5370447 > libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=121 > libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1500ms (first > in line) It goes wrong right away. 121 means a bus error. Actually there are some fairly significant fixes for bulk on Linux in libusb-stuge.git - could I ask you to try that also? And it would be interesting to see usbmon output from when you run this. See Documentation/usb/usbmon.txt in the kernel source for instructions. //Peter |
|
From: Adam N. <a.n...@sh...> - 2010-11-23 08:40:16
|
> It goes wrong right away. 121 means a bus error. Actually there are > some fairly significant fixes for bulk on Linux in libusb-stuge.git - > could I ask you to try that also? Sure, here's the output from libusb-stuge.git. Looks pretty similar. Note that I did change something else in the code which I think has resulted in a slightly different buffer size, but the failure still occurs for the same reason. libusb:debug [submit_bulk_transfer] need 330 urbs for new transfer with length 5400000 libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=121 libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1500ms (first in line) libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms libusb:debug [handle_events] poll() returned 1 libusb:debug [reap_for_handle] urb type=3 status=-121 transferred=0 libusb:debug [handle_bulk_completion] handling completion status -121 of bulk urb 1/330 libusb:debug [handle_bulk_completion] abnormal reap: urb status -121 libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms libusb:debug [handle_events] poll() returned 1 libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0 libusb:debug [handle_bulk_completion] handling completion status -104 of bulk urb 2/330 libusb:debug [handle_bulk_completion] abnormal reap: urb status -104 libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms libusb:debug [handle_events] poll() returned 1 libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0 libusb:debug [handle_bulk_completion] handling completion status -104 of bulk urb 3/330 > And it would be interesting to see usbmon output from when you run > this. See Documentation/usb/usbmon.txt in the kernel source for > instructions. Here is the usbmon output narrowed down to just this call - please advise if you need any earlier output - there's a lot of it thanks to firmware uploads etc. ffff880027efbe00 1899543261 S Bi:065:02 -115 16384 < ffff88014030b8c0 1899543297 S Bi:065:02 -115 16384 < ffff8800350a2600 1899543327 S Bi:065:02 -115 16384 < ffff880128d7d380 1899543359 S Bi:065:02 -115 16384 < . . . ffff8800276c5d40 1899544828 S Bi:065:02 -115 16384 < ffff880052d06ec0 1899544916 S Bi:065:02 -115 16384 < ffff880052d06680 1899545006 S Bi:065:02 -115 16384 < ffff880052d06980 1899545112 S Bi:065:02 -115 16384 < ffff880027efbe00 1899545149 C Bi:065:02 -121 0 ffff88014030b8c0 1899545255 C Bi:065:02 -104 0 ffff8800350a2600 1899545317 C Bi:065:02 -104 0 ffff880128d7d380 1899545374 C Bi:065:02 -104 0 ffff88010cc9d980 1899545442 C Bi:065:02 -104 0 . . . ffff8800276c5d40 1899548320 C Bi:065:02 -104 0 ffff880052d06ec0 1899548466 C Bi:065:02 -104 0 ffff880052d06680 1899548610 C Bi:065:02 -104 0 ffff880052d06980 1899548665 C Bi:065:02 -104 0 I also got this as the -121 response in the middle on an earlier run with libusb-pbatard.git: ffff8801103c1e40 1422146944 C Bi:065:02 -121 4098 = 0d010800 00000000 00000000 0006010c 322e2e4b 47494a2f 2e4b474a 492f2e4b Cheers, Adam. |
|
From: Alan S. <st...@ro...> - 2010-11-23 15:13:29
|
On Tue, 23 Nov 2010, Adam Nielsen wrote: > > It goes wrong right away. 121 means a bus error. Actually there are > > some fairly significant fixes for bulk on Linux in libusb-stuge.git - > > could I ask you to try that also? > > Sure, here's the output from libusb-stuge.git. Looks pretty similar. Note > that I did change something else in the code which I think has resulted in a > slightly different buffer size, but the failure still occurs for the same reason. > > libusb:debug [submit_bulk_transfer] need 330 urbs for new transfer with length > 5400000 > libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=121 > libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1500ms (first > in line) > libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms > libusb:debug [handle_events] poll() returned 1 > libusb:debug [reap_for_handle] urb type=3 status=-121 transferred=0 > libusb:debug [handle_bulk_completion] handling completion status -121 of bulk > urb 1/330 > libusb:debug [handle_bulk_completion] abnormal reap: urb status -121 > libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms > libusb:debug [handle_events] poll() returned 1 > libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0 > libusb:debug [handle_bulk_completion] handling completion status -104 of bulk > urb 2/330 > libusb:debug [handle_bulk_completion] abnormal reap: urb status -104 > libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms > libusb:debug [handle_events] poll() returned 1 > libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0 > libusb:debug [handle_bulk_completion] handling completion status -104 of bulk > urb 3/330 > > > And it would be interesting to see usbmon output from when you run > > this. See Documentation/usb/usbmon.txt in the kernel source for > > instructions. > > Here is the usbmon output narrowed down to just this call - please advise if > you need any earlier output - there's a lot of it thanks to firmware uploads etc. > > ffff880027efbe00 1899543261 S Bi:065:02 -115 16384 < > ffff88014030b8c0 1899543297 S Bi:065:02 -115 16384 < > ffff8800350a2600 1899543327 S Bi:065:02 -115 16384 < > ffff880128d7d380 1899543359 S Bi:065:02 -115 16384 < > . > . > . > ffff8800276c5d40 1899544828 S Bi:065:02 -115 16384 < > ffff880052d06ec0 1899544916 S Bi:065:02 -115 16384 < > ffff880052d06680 1899545006 S Bi:065:02 -115 16384 < > ffff880052d06980 1899545112 S Bi:065:02 -115 16384 < > ffff880027efbe00 1899545149 C Bi:065:02 -121 0 > ffff88014030b8c0 1899545255 C Bi:065:02 -104 0 > ffff8800350a2600 1899545317 C Bi:065:02 -104 0 > ffff880128d7d380 1899545374 C Bi:065:02 -104 0 > ffff88010cc9d980 1899545442 C Bi:065:02 -104 0 > . > . > . > ffff8800276c5d40 1899548320 C Bi:065:02 -104 0 > ffff880052d06ec0 1899548466 C Bi:065:02 -104 0 > ffff880052d06680 1899548610 C Bi:065:02 -104 0 > ffff880052d06980 1899548665 C Bi:065:02 -104 0 This trace shows that what happened wasn't an error. The device sent a bulk-IN transfer of length 0, that's all. I don't see any reason why that should be connected to the original length of the request. > I also got this as the -121 response in the middle on an earlier run with > libusb-pbatard.git: > > ffff8801103c1e40 1422146944 C Bi:065:02 -121 4098 = 0d010800 00000000 00000000 > 0006010c 322e2e4b 47494a2f 2e4b474a 492f2e4b Again, -121 merely indicates a short transfer. In this case, 4098 bytes instead of 16384. Alan Stern |
|
From: Adam N. <a.n...@sh...> - 2010-11-27 22:47:29
|
> This trace shows that what happened wasn't an error. The device sent a > bulk-IN transfer of length 0, that's all. I don't see any reason why > that should be connected to the original length of the request. This still happens when I use a smaller buffer size, and it works fine then. So I don't think this is related to the problem. > Again, -121 merely indicates a short transfer. In this case, 4098 > bytes instead of 16384. Looking more closely, libusb-stuge.git no longer reports an error, but for some reason it receives less data. Using a large (5MB) receive buffer, the application receives ~7kB of data before the receive completes (and it repeats this about four times then reports a 'corrupted data' error), whereas using a 6kB buffer it receives 4-6kB of data, and repeats this dozens of times to end up receiving much more data and reporting success. I'm not familiar enough with USB protocols, but could this be because sending so many 'get data' requests to the USB device is confusing it? With a 5MB buffer the debug messages indicate 330 URBs are allocated, whereas the 6kB buffer results in only one URB being allocated. Thanks, Adam. |
|
From: Alan S. <st...@ro...> - 2010-11-28 03:11:22
|
On Sun, 28 Nov 2010, Adam Nielsen wrote: > > This trace shows that what happened wasn't an error. The device sent a > > bulk-IN transfer of length 0, that's all. I don't see any reason why > > that should be connected to the original length of the request. > > This still happens when I use a smaller buffer size, and it works fine then. > So I don't think this is related to the problem. Can you post two usbmon traces? One using the smaller buffer size and one using the larger buffer size. It would be interesting to compare them. > > Again, -121 merely indicates a short transfer. In this case, 4098 > > bytes instead of 16384. > > Looking more closely, libusb-stuge.git no longer reports an error, but for > some reason it receives less data. Using a large (5MB) receive buffer, the > application receives ~7kB of data before the receive completes (and it repeats > this about four times then reports a 'corrupted data' error), whereas using a > 6kB buffer it receives 4-6kB of data, and repeats this dozens of times to end > up receiving much more data and reporting success. > > I'm not familiar enough with USB protocols, but could this be because sending > so many 'get data' requests to the USB device is confusing it? With a 5MB > buffer the debug messages indicate 330 URBs are allocated, whereas the 6kB > buffer results in only one URB being allocated. No, the same number of "get data" requests are sent to the device either way. Alan Stern |
|
From: Peter S. <pe...@st...> - 2010-11-21 20:38:56
|
Adam Nielsen wrote: > Thanks for the quick reply, I'll see if I can work it out. I'm > running Gentoo, so building from source. Ok. > Sorry, by native I mean when Windows is running on real hardware. > It only breaks when Windows is running inside VirtualBox, which as > far as I'm aware, uses libusb for its pass-through USB support. > > But yes, the app under Windows uses WinUSB. Please clarify under which circumstances you experience the problem. You have so far mentioned: building libusb from source on Gentoo running Windows on hardware running Windows in VirtualBox (on Gentoo? maybe also on Windows?) It would seem to me that you're reporting a problem with USB in Windows in VirtualBox on Linux behaving different from USB in Windows on hardware. This would be about Linux libusb support. Please provide usbmon logs in that case. I have heard a lot of nonsense failures with VirtualBox so I am thoroughly unimpressed by it's capabilities in general and not at all surprised if it is the cause of the problem, but let's find out the details and I'll try to avoid jumping to a conclusion. :) //Peter |
|
From: Adam N. <a.n...@sh...> - 2010-11-21 20:56:46
|
> Please clarify under which circumstances you experience the problem. > > You have so far mentioned: > > building libusb from source on Gentoo This fails with large buffer sizes. I'll try to get debugging logs to you this evening from libusb-pbatard.git. > running Windows on hardware This works fine. > running Windows in VirtualBox (on Gentoo? maybe also on Windows?) On Gentoo. This fails. > It would seem to me that you're reporting a problem with USB in > Windows in VirtualBox on Linux behaving different from USB in Windows > on hardware. Indirectly yes, but given the same problem exists when using libusb natively under Linux (i.e. libusb is the common factor in all the failure scenarios) I thought this the best place to report it. It is my expectation that should this prove to be a problem in libusb, fixing it will also fix VirtualBox. > This would be about Linux libusb support. Please provide usbmon logs > in that case. I have only briefly checked with Wireshark and VirtualBox (before I realised the problem existed under Linux/libusb also), and I could see the device returning data, but this never made it back to the application. I will try to send whatever debugging info I can later today. > I have heard a lot of nonsense failures with VirtualBox so I am > thoroughly unimpressed by it's capabilities in general and not at all > surprised if it is the cause of the problem, but let's find out the > details and I'll try to avoid jumping to a conclusion. :) I'm not that worried about VirtualBox, my main concern is getting the app working natively under Linux - if that results in a VirtualBox fix as well, then all the better :-) Cheers, Adam. |
|
From: Segher B. <se...@ke...> - 2010-11-21 21:35:22
|
It fails on native Linux? In that case, please file a bugreport at http://libusb.org/newticket -- thanks! Segher |
|
From: Xiaofan C. <xia...@gm...> - 2010-11-22 01:09:11
|
On Mon, Nov 22, 2010 at 4:56 AM, Adam Nielsen <a.n...@sh...> wrote: >> Please clarify under which circumstances you experience the problem. > >> building libusb from source on Gentoo > > This fails with large buffer sizes. I'll try to get debugging logs to you > this evening from libusb-pbatard.git. > If this is the case, maybe it is better to use libusb.git and not libusb-pbatard.git since they are not that different under Linux. Only for Windows, libusb.git is lag behind libusb-pbatard.git. One more thing, I just wonder if increasing the time out helps or not. Just a guess here. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2010-11-22 05:29:06
|
On Mon, Nov 22, 2010 at 9:09 AM, Xiaofan Chen <xia...@gm...> wrote: > If this is the case, maybe it is better to use libusb.git and not > libusb-pbatard.git since they are not that different under Linux. > Only for Windows, libusb.git is lag behind libusb-pbatard.git. > Hmm, just noticed that Peter seems to use libusb-stuge.git as the basis to close the tickets and not libusb.git http://git.libusb.org/?p=libusb-stuge.git;a=shortlog;js=1 -- Xiaofan |
|
From: Peter S. <pe...@st...> - 2010-11-22 05:59:51
|
Xiaofan Chen wrote: > On Mon, Nov 22, 2010 at 9:09 AM, Xiaofan Chen <xia...@gm...> wrote: > > If this is the case, maybe it is better to use libusb.git and not > > libusb-pbatard.git since they are not that different under Linux. > > Only for Windows, libusb.git is lag behind libusb-pbatard.git. > > Hmm, just noticed that Peter seems to use libusb-stuge.git as the > basis to close the tickets and not libusb.git > http://git.libusb.org/?p=libusb-stuge.git;a=shortlog;js=1 That is a bug in the git->Trac integration! I do not want Trac to change tickets based on commit messages in any other repository than libusb.git, but that is clearly not how it works right now. Thanks for pointing it out - I will have to fix that somehow! I have been massaging patches for a good while and am pretty close to a bunch of patches that I'm happy with. When done I would push all patches to libusb-stuge.git, push trivial patches to libusb.git, and send the rest to the mailinglist for review, and push them to libusb.git if there was not a lot of protests for a couple of days. libusb-stuge.git is the current state of my working tree. That is rebased frequently, but I only expect one split in there for now, and a few commit message changes. If anyone wants to review these commits, even if they will still change a little further, please go for it! I'll take into account any and all comments in my further work. Sorry for the confusion! //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-01 17:49:08
|
On 2010.11.22 05:59, Peter Stuge wrote: > libusb-stuge.git is the current state of my working tree. That is > rebased frequently, but I only expect one split in there for now, > and a few commit message changes. If anyone wants to review these > commits, even if they will still change a little further, please go > for it! I'll take into account any and all comments in my further > work. libusb-stuge broke cygwin compilation. Getting the following when running configure from autogen.sh: ... checking for sys/time.h... yes configure: creating ./config.status .in'ig.status: error: cannot find input file: ` Yup, the last line is verbatim. And I'm going to rant again, but was it really necessary to split the configure.ac changes into 9 commits? What good will come of going atomic with such single liners as "Quote AC_COMPILE_IFELSE() input" or "Trivial whitespace changes and reordering", *REALLY*? IMO, a simple "configure.ac improvements" with bullet points detailing each improvements could do wonders, especially as configure.ac is far from being our bread and butter. If producing such commits has been taking time away from progressing on the actual official integration for 1.0.9, maybe we need to review our approach... Regards, /Pete |
|
From: Pete B. <pb...@gm...> - 2010-12-01 18:31:35
|
On 2010.12.01 17:49, Pete Batard wrote: > .in'ig.status: error: cannot find input file: ` Why, yes, it's the old "cygwin doesn't like multiple files to be provided on multiple lines - YOU HAVE BEEN WARNED!" issue [1]. Please don't reorganize the AC_CONFIG_FILES list. It doesn't work with multiple lines on cygwin [2], even if you quote each file as I have just tested. And I for one would like to place my vote into delaying all cosmetic changes, like the above, until much later, and instead focus only on what is really needed for the 1.0.9 release. Regards, /Pete PS: now configure works, but I'm getting the following, still in cygwin (NB: MinGW was OK). make[2]: Entering directory `/cygdrive/d/libusb-pbatard/libusb' CC libusb_1_0_la-core.lo In file included from core.c:30: libusbi.h:831: error: parse error before "nfds_t" libusbi.h:831: warning: function declaration isn't a prototype make[2]: *** [libusb_1_0_la-core.lo] Error 1 [1] http://git.libusb.org/?p=libwdi.git;a=blob;f=configure.ac#l238 [2] http://git.libusb.org/?p=libusb-stuge.git;a=commitdiff;h=ea9f79daa3aec3c0c9b53b8fbac90ac0d0d28d3f;hp=a4a00780a224efc2dca4f3168509b99a1364e8a7;js=1 |
|
From: Peter S. <pe...@st...> - 2010-12-01 20:23:12
|
Pete Batard wrote: > On 2010.12.01 17:49, Pete Batard wrote: > > .in'ig.status: error: cannot find input file: ` > > Why, yes, it's the old "cygwin doesn't like multiple files to be > provided on multiple lines - YOU HAVE BEEN WARNED!" issue [1]. > > Please don't reorganize the AC_CONFIG_FILES list. It doesn't work with > multiple lines on cygwin [2], even if you quote each file as I have just > tested. Ouch. Did you research the cause of the problem when you ran into it? It seems that this was fixed already in 2005. http://www.mail-archive.com/aut...@gn.../msg00507.html discusses the problem. A workaround would be to do multiple AC_CONFIG_FILES() calls, but I could also be convinced to simply bump AC_PREREQ() up to a version where this has been fixed. git://git.sv.gnu.org/autoconf has this commit, which seems related: commit 22efb81e0aaad363d4b0f9fb6cfef80aa6e46f85 Author: Ralf Wildenhues <Ral...@gm...> Date: Mon Aug 4 08:02:53 2008 +0200 Fix AC_CONFIG_FILES([$var]) 2.62 regression. * lib/autoconf/status.m4 (_AC_OUTPUT_CONFIG_STATUS): Flatten whitespace in $ac_config_files and $ac_config_headers. * tests/torture.at (Parameterized AC_CONFIG_FILES): New test. Report by Andreas Schwab and Per Øyvind Karlsen. * THANKS: Update. Signed-off-by: Ralf Wildenhues <Ral...@gm...> The first version to include it is 2.63. Which version of autoconf is in your Cygwin? > And I for one would like to place my vote into delaying all cosmetic > changes, like the above, until much later, and instead focus only on > what is really needed for the 1.0.9 release. I didn't spend significant time on that particular change in configure.ac, but I want the change because it makes for significantly simpler patches if and when the list of files is updated later. > PS: now configure works, but I'm getting the following, still in > cygwin (NB: MinGW was OK). > > make[2]: Entering directory `/cygdrive/d/libusb-pbatard/libusb' > CC libusb_1_0_la-core.lo > In file included from core.c:30: > libusbi.h:831: error: parse error before "nfds_t" > libusbi.h:831: warning: function declaration isn't a prototype > make[2]: *** [libusb_1_0_la-core.lo] Error 1 Could you send me config.log from that configure run? (May need to send directly, don't know if it will be too large for the list.) > Can you tell where [1] comes from, Detecting variable types is one of the things autoconf is meant for, and some of our platforms do not have nfds_t, but we need it for poll() in the backends. The check was inspired by a Hadoop configure source and introduced because of build failure on an older version of Mac OS X as reported by Segher. > and if this was ever tested on cygwin? Not before, no. Then I would probably also have seen the error. I hope we can fix it easily. > If Windows specific patches like this one are being introduced > without being properly tested (haven't tested MSVC, since we don't > have the project files), this is going to be a major headache. It's relevant also for Macs. Only Linux is guaranteed to have nfds_t. I agree that testing is very important. > Or at least, please submit it as a proposal to the list so that I > can try to test it. I'm only realizing now that you have added a > lot of changes in your tree that were never publicly debated on > the list. Even as one of the libusb maintainers, if you want to > integrate some non trivial changes into official, please try to > submit a patch on the mailing list for review. I agree completely with this approach, it has always been the plan, and it still is. Even though you've also said that trivial things could go directly to libusb.git I actually think it is good to run also those by the mailing list, even if just for a day or two. I would consider this configure.ac multiple lines change as trivial, not knowing that autoconf had a problem but you would probably have caught it just by seeing the patch on the list, and I expect that this will happen more times across our zoo of platforms. As I pointed out already it was a mistake for Trac to act on the commands in my commit messages, so I need to fix that and clean it up. Meanwhile please don't push commits with commands to the master branch in any other repo either, to avoid needing more manual cleanup. Sorry for this trouble, but at least branches are easy. Changes in libusb-stuge.git are not and were never really intended to go to libusb.git without more review and/or testing. > I'm afraid keeping all of MinGW, MSVC and cygwin happy at the same > time is almost never straightforward, no matter how simple the > patch might look, True, and it's an argument for ignoring some or more of them, but I think it is very nice if we can have support for them all, so I want to try to figure the issues out. > so for now, I'd suggest we revert this change (if it ain't > broke...), and spend time on the rest of the integration instead. Let's just fix this change. Would you favor bumping AC_PREREQ, or prefer multiple calls to AC_CONFIG_FILES? > If I have a chance, I'll see if I can pick up your patch, and fix > it for my branch, so that you get it back when official catches up. Only do this if you first rebase your work onto libusb-stuge.git, or you will be creating a lot of extra complications in your repo. I'll fix it in libusb-stuge.git when there is a solution. I will apply the future state of libusb-stuge.git (whatever that will be) onto libusb.git before other changes, so if you want to work on some stuff that I am also working on in my repo then you'll have to work with the changes as they are in my repo, and in particular keep in mind that I will rebase potentially frequently. Hopefully the nfds_t thing can also be fixed fairly easily! //Peter |
|
From: Pete B. <pb...@gm...> - 2010-12-01 22:18:02
|
On 2010.12.01 20:23, Peter Stuge wrote: > Ouch. Did you research the cause of the problem when you ran into it? Yes I did, briefly, because spending time purely on cosmetics is not my idea of time well spent. Found a reference indicating that you had to set binmode, before I remembered that I had seen something similar in libwdi, tested it, and found that it was the same issue. As I personally don't give a damn about the length of our lines in configure.ac (only libusb developers, not libusb developer-users will ever look at that file), I stopped there. Also, the idea that we should alienate everybody who has an old version of autoconf, when we can EASILY avoid it is 100% foreign to me. Seriously, are we going to make sure that people who haven't upgraded their tools pay the price, simply because one individual can't stand the idea of a long line not being broken down in autoconf.ac? Puh-lease! > The first version to include it is 2.63. Which version of autoconf is > in your Cygwin? 2.65, which is about one year old. If once again you want to make sure that libusb is impossible to build, should one happen to use slightly obsolete versions of autotools, be my guest. But don't be surprised if I'm not that inclined to help you there. Using a single line is 100% acceptable by my records. Regards, /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-01 22:40:55
|
> Also, the idea that we should alienate everybody who has an old version > of autoconf, when we can EASILY avoid it is 100% foreign to me. People who use tarballs never run autoconf. People who build from source will get an error "you need a newer version of autoconf", so that's no problem either. > Seriously, are we going to make sure that people who haven't upgraded > their tools pay the price, simply because one individual can't stand the > idea of a long line not being broken down in autoconf.ac? Puh-lease! As you have shown yourself, we will run into the same problem over and over again. Also, we will eventually run into other bugs in old versions of autoconf. We should simply require a new enough version of autoconf whenever we need a certain bugfix, or want a certain feature. Every other serious project does the same. >> The first version to include it is 2.63. Which version of autoconf is >> in your Cygwin? > > 2.65, which is about one year old. If once again you want to make sure > that libusb is impossible to build, should one happen to use slightly > obsolete versions of autotools, be my guest. But don't be surprised if > I'm not that inclined to help you there. Using a single line is 100% > acceptable by my records. It's what, five, ten lines by now? We _will_ run into the same problem again. And it adds up. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-01 22:52:32
|
On 2010.12.01 22:40, Segher Boessenkool wrote: > It's what, five, ten lines by now? We _will_ run into the same problem > again. And if we do, and it's a simple issue of not using multiple lines vs requiring everybody to upgrade, we'll use a single line, because this is called helping our users and provding software that strightforward to use, rather than polishing our navel with the shiniest configure.ac ever. The only people that are affected by using a single line are us. Even if we meet the same issue in the future, at most us+1 (one user will report it, we'll fix it the same way, and move on). The people that are affected by not using a single line is everybody who has a slightly old version of autotools. Somehow, the logic of ensuring that our users have difficulties building libusb, when it takes less than 30 seconds (and 30 seconds next time around, and 30 seconds the time after that...) to ensure that they don't is completely alien to me. Regards, /Pete |
|
From: Segher B. <se...@ke...> - 2010-12-01 23:29:48
|
> On 2010.12.01 22:40, Segher Boessenkool wrote: >> It's what, five, ten lines by now? We _will_ run into the same problem >> again. > > And if we do, and it's a simple issue of not using multiple lines vs > requiring everybody to upgrade, we'll use a single line, because this is > called helping our users and provding software that strightforward to > use, rather than polishing our navel with the shiniest configure.ac ever. blub:~ segher$ autoconf --version autoconf (GNU Autoconf) 2.57 It doesn't work with libusb's configure.ac -- are you going to fix that? And this is a quite recent machine and OS install. I also have a 2.59 if you didn't think that example fair; that OS install is merely three years old. More seriously, like I already said, when you have to update minimum prerequisites to get a bugfix, just do it. The required version here would be two years old (if I understand correctly), an eternity! Also, as I already said, users do not need autoconf _at all_. A generated ./configure is in the tarballs. Segher |
|
From: Pete B. <pb...@gm...> - 2010-12-02 00:26:01
|
On 2010.12.01 23:29, Segher Boessenkool wrote: > blub:~ segher$ autoconf --version > autoconf (GNU Autoconf) 2.57 > > It doesn't work with libusb's configure.ac -- are you going to fix that? Depends. Wouldn't be the first time I provide simple fixes for older versions. I did provide fixes for older versions of libtools, to support CJK users, which were rejected after a long debate. The only question we should ask ourselves is, if we find users that run into a specific issue, do we want to help them or not. If someone other than you complains about 2.57, I think I'd probably look into it, because it might be a nothing change like the multiline ones. > I also have a 2.59 if you didn't think that example fair; that OS install > is merely three years old. Let's cut to the chase here. Yes we should set a limit. But here's my problem: the cygwin I (re)installed was in late March, and I also applied an update in July. So at worst, the version I use of cygwin is supposed to be 9 months old. If 9 months is what we want to affix with the label "obsolete", that's not going to fly. To me obsolete should not apply to anything that's less than 2 years, because I fully expect people to use 2 year old development platforms, especially on Windows. Heck, we support XP, and we'll probably support Windows 2000 when we add libusb-win32, because we've been asked to. clearly, there's gotta be some kind of middle ground about where obsolete stands. > More seriously, like I already said, when you have to update minimum > prerequisites to get a bugfix, just do it. Not when people using 9 months old development platforms have to do it. > The required version here > would be two years old (if I understand correctly), an eternity! Nope. Found that my 1 year old autoconf 2.65 version (src released 2009.11) wouldn't work either, and with that 1 year old version having taken about 3 months to be integrated into cygwin, it probably means that if 2.66 actually fixed the issue, we'll be asking cygwin users to use an autoconf cygwin package that is less than 6-7 months old. Do you upgrade your autotools every 6 months? Regards, /Pete |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X