Am 06.06.2012 18:23, schrieb Pete Batard: > On 2012.06.06 16:50, Lars Kanis wrote: >> Other compilers than gcc may not understand the option, but for >> mingw-gcc it should be safe to set -fno-omit-frame-pointer, since the >> option is quite old, now. > > Does the libusb-1.0-binding for Ruby need to support cygwin as well? > From my understanding of the issue, I'd expect a cygwin's gcc 4.6 to > also use -fomit-frame-pointer and run into the same problem, so I'm > planning to add that option for both MinGW and cywgin at this stage. In theory libusb for Ruby should work on cygwin too, but I don't have a proper test environment currently. Cygwin's gcc 4.6 will also default to -fno-omit-frame-pointer but it shouldn't break anything there, since it does not depend on msvcrt.dll.
>> Libusbx-commit cf6e68a fixes the issue. A dummy call to >> But according to the API docs I would >> expect, that any logging is done based on the particular context. > > That's not exactly true if you also display debug logging, as debug > also uses the default context. > > At this stage, if anybody thinks using the default context on a very > limited set of warnings/errors is an issue, what will happen is that I > will set these calls back to usbi_dbg(), which I believe is what they > original were before I decided they may be better off bumped to > warn/error. You will understand that we are of course under no > obligation to provide any error or warning logging messages on > potential issues, and therefore entitled to switch a message to debug > if we so choose. At this stage, I don't think it makes any sense to > modify the calls to add the passing of a context for a couple of > messages that, at least as far as poll_windows.c is concerned, should > only occur if someone modifies the library itself and doesn't properly > use the internal usbi_... calls, even more so as such a modification > would affect all platforms. > > Therfore what will happen is that, if you tell us that you cannot live > with a handful of messages using the default context, we will patch > those back to using usbi_dbg, and if you tell us that you can, we will > not change anything. > To set the first context also as default context (Libusbx-commit cf6e68a) is a good solution. I also would consider the warning about a threading issue as a warning not just a debug message for the library user. -- Regards, Lars Kanis ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libusbx-devel
