Hi,
my compiler is Clang on MacOS 10.7.5.
I run
./configure --disable-log --prefix=/opt/local
make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6"
and here's the output:
Making all in libusb
CC libusb_1_0_la-core.lo
core.c:1755:30: warning: use of logical '&&' with constant ope
On Thu, Apr 4, 2013 at 4:27 PM, nico wrote:
> Hi,
> my compiler is Clang on MacOS 10.7.5.
> I run
> ./configure --disable-log --prefix=/opt/local
> make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6"
> and here's the output:
>
> Making all in libusb
>CC libusb_1_0_la-core.lo
On Thu, Apr 4, 2013 at 6:24 PM, Xiaofan Chen wrote:
> Yes you are right. If using Apple gcc, then there are no warnings.
> If using clang, then yes two warnings are generated. Tested
> under Mac OS X 10.7.5.
Another thing for Mac OS X, I probably misled Nathan on
the bInterval fix.
The following
On 03/04/13 20:35, Pete Batard wrote:
On 2013.04.03 12:09, Toby Gray wrote:
The attached patch fixes this.
Thanks for testing.
Your patch is now part of RC2, and I confirmed that RC2 compiled for
WinCE on my test environment.
Agreed. RC2 works fine for me too.
If I provide a zip of pre-buil
Hi,
I'm in the middle of tracking down (and hopefully fixing) a rare memory
fault in the desktop Windows version of libusbx*.
When the issue was reported by one of our internal testers it wasn't
possible for me to decode the Windows Error Reporting (WER) information
in any sensible way as I di
Hi,
As I mentioned in a previous email, I've been tracking down a rare NULL
pointer dereference in the windows desktop backend.
The problem is that the backend private information for transfers wasn't
getting correctly cleared before the transfer completion callback was
called.
This meant
2013/4/4 nico
> Hi,
> my compiler is Clang on MacOS 10.7.5.
> I run
> ./configure --disable-log --prefix=/opt/local
> make CFLAGS="-arch i386 -arch x86_64 -mmacosx-version-min=10.6"
> and here's the output:
>
> Making all in libusb
>CC libusb_1_0_la-core.lo
> core.c:1755:30: warning: us
On 2013.04.04 09:27, nico wrote:
> Making all in libusb
>CC libusb_1_0_la-core.lo
> core.c:1755:30: warning: use of logical '&&' with constant operand
Thanks for the report, and the test.
This is now fixed in RC3, along with a couple minor issues.
The new RC is available from:
http://sour
On 2013.04.04 17:04, Toby Gray wrote:
> As I mentioned in a previous email, I've been tracking down a rare NULL
> pointer dereference in the windows desktop backend.
Thanks!
> The problem is that the backend private information for transfers wasn't
> getting correctly cleared before the transfer
On 2013.04.04 14:45, Toby Gray wrote:
> Would it make sense to create a zip of the symbols for the pre-compiled
> binaries available on sourceforge?
Well, I guess if we do, we might as well make that part of the Windows
binary generation process, since I get to generate them then. It's a
simple
On 2013.04.04 14:08, Xiaofan Chen wrote:
> The following lines should be removed,
> https://github.com/libusbx/libusbx/commit/2ffefc04769845dcb682655a437fa604e0299683
> + /* work around buggy devices */
> + if (0 == interval) {
> +interval = 9;
> + }
> +
Oh yeah, this has been included in R
Hi,
merci beaucoup to everyone for your work...
Le 04/04/13 20:35, Pete Batard a écrit :
> On 2013.04.04 09:27, nico wrote:
>> Making all in libusb
>> CC libusb_1_0_la-core.lo
>> core.c:1755:30: warning: use of logical '&&' with constant operand
> Thanks for the report, and the test.
> Thi
On Fri, Apr 5, 2013 at 12:04 AM, Toby Gray wrote:
> I understand that this is probably too risky a change to get into 1.0.15,
> especially as no-one else seems to have reported it.
There were past reports of issues under Windows XP and Windows 7
when using libusbx async API with multithreaded pr
On Fri, Apr 5, 2013 at 3:04 AM, Pete Batard wrote:
> On 2013.04.04 14:08, Xiaofan Chen wrote:
>> The following lines should be removed,
>> https://github.com/libusbx/libusbx/commit/2ffefc04769845dcb682655a437fa604e0299683
>> + /* work around buggy devices */
>> + if (0 == interval) {
>> +int
14 matches
Mail list logo