On May 24, 2012 15:24:10 PDT, Yves Arrouye wrote:
How can I do that? Just trying to pass arch flags in CFLAGS/LDFLAGS is
not working:
% make
make all-recursive
Making all in libusb
CC libusb_1_0_la-core.lo
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch
I am porting iguanaWorks' code to drive their USB IR transceiver to OS
X. Their code uses libusb(x). I am testing both on my Macbook and on
Ubuntu Linux inside Virtual Box. On Ubuntu Linux, a
But on OS X, if I set debug level to 3, I get an incessant stream of
timeout messages. I wonder: timeouts
>> and also am not sure what would then happen to the *.la etc. files
>> that only knew about one arch.
>
> They are libtool files which do not really matter except when using
> libtool to link against the library.
What I meant is that if I make install twice, only one arch goes into
the libtool f
This TN describes exactly what I am doing: passing -arch flags in
compiler flags. However, this does not work with libusbx, apparently
because those flags are passed to a cc -E or -M command. An example
showing the issue is:
% cc -E -arch i386 -arch x86_64
llvm-gcc-4.2: -E, -S, -save-temps and -M
On Thu, 24 May 2012 15:24:10 -0700, Yves Arrouye said:
>How can I do that? Just trying to pass arch flags in CFLAGS/LDFLAGS is
>not working:
Apple's Technical Note TN2137 describes how to get universal binaries working
in autoconf projects. The document seems to have disappeared however. :( Bu
Yves Arrouye wrote:
> How can I do that?
No solution AFAIK.
> It does not help that the full command-line isn't displayed (how can I
> see that instead of the fake command lines here, by the way)...
make V=1
> rather not have to build twice and lipo everything together,
This does however wor
How can I do that? Just trying to pass arch flags in CFLAGS/LDFLAGS is
not working:
% make
make all-recursive
Making all in libusb
CC libusb_1_0_la-core.lo
llvm-gcc-4.2: -E, -S, -save-temps and -M options are not allowed with
multiple -arch flags
It does not help that the full command-line
Hello Pete,
> please be aware that the Windows driver we use at the
> moment doesn't support isoch (see "Known Restrictions" for WinUSB at
> [1]),
Indeed. Why on earth make WinUSB without isoch support.
> though we're planning to add drivers that support isoch in the future.
Has anyone started
This one does a few things:
1. It sets the origin of the timestamps to the first libusb_init() call
issued by the application. The idea is to avoid getting an arbitrary
origin once we have toggleable logging, as it is currently set to the
first debug message ever issued, which isn't something
Since the next item on the agenda will be toggleable logging, we might
as well take care of some minor logging improvements beforehand.
This patch moves the definition of the logging levels from libusbi.h to
libusb.h.
The idea is that since we provide a libusb_set_debug() call that takes a
l
On 2012.05.24 14:12, Xiaofan Chen wrote:
> I am not so sure if gerrit is good for libusbx or not. From the OpenOCD
> side it seems to be a success mostly. But it does prevent some users
> from posting patches as well. OpenOCD is considered to be a big
> project whereas libusb/libusbx are much small
This one should work a bit better.
Regards,
/Pete
>From 67abd67778893631da0e822b57feef68cf9208e4 Mon Sep 17 00:00:00 2001
From: Pete Batard
Date: Thu, 24 May 2012 11:42:47 +0100
Subject: [PATCH 2/2] Darwin: Align severity of OS-X logging messages
* Some informational messages were actually de
On 05/17/2012 04:27 PM, Peter Stuge wrote:
> Uri Lublin wrote:
Only if old backend api is UNSUPPORTED.
>>> Hm. Shouldn't the check be done unconditionally - and for all
>>> devices, ie. in every pass except perhaps HCD? Otherwise I think
>>> the bug still bites when installing the previous dri
On 2012.05.24 14:17, Xiaofan Chen wrote:
> One git question first, how to revert the v2 patch and then apply
> this patch?
If you just applied a patch, "git reset HEAD" should do the job... I
think (I'd have to look up the command, since with TGit I'm just doing
that in a couple of clicks by acc
On Thu, May 24, 2012 at 7:11 PM, Pete Batard wrote:
> While I was at it, and since it's an open 1.0.12 item
> (https://sourceforge.net/apps/trac/libusbx/ticket/1)...
>
> Apart from one message that looked like info we want to carry out with debug
> level info, most of the usbi_info() calls looked
On Thu, May 24, 2012 at 9:17 PM, Xiaofan Chen wrote:
> On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote:
>> On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
>>> Finally got around looking further at the Darwin issue. It looks like the
>>> main problem was that process_new_device() was main
On Thu, May 24, 2012 at 9:12 PM, Xiaofan Chen wrote:
> On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
>> Finally got around looking further at the Darwin issue. It looks like the
>> main problem was that process_new_device() was maintaining a static device
>> pointer for the last device seen
On Thu, May 24, 2012 at 7:10 PM, Pete Batard wrote:
> Finally got around looking further at the Darwin issue. It looks like the
> main problem was that process_new_device() was maintaining a static device
> pointer for the last device seen (last_dev), and the value wasn't reset as
> it should when
While I was at it, and since it's an open 1.0.12 item
(https://sourceforge.net/apps/trac/libusbx/ticket/1)...
Apart from one message that looked like info we want to carry out with
debug level info, most of the usbi_info() calls looked like they should
actually be usbi_dbg(), especially when c
Finally got around looking further at the Darwin issue. It looks like
the main problem was that process_new_device() was maintaining a static
device pointer for the last device seen (last_dev), and the value wasn't
reset as it should when calling get_device_list(), resulting in a bad
pointer re
20 matches
Mail list logo
