On Sun, Sep 12, 2010 at 10:19 AM, Luis Lavena wrote:
> On Sat, Sep 11, 2010 at 9:58 PM, Xiaofan Chen wrote:
>> From what I read, dlfcn.h should be deleted as it is not really
>> applicable to Windows. You should use Win32 functions
>> like LoadLibrary().
>>
>> That being said, not so sure if this
On 9/12/2010 11:38, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
>> So far, good news from both of the x86 and x64 fronts. Will wait
>> for the news about performance.
>
> I tried to use the 32bit driver under Windows 7 32bit and it
> seems to work fine. The simple te
On Sun, Sep 12, 2010 at 11:52 AM, Xiaofan Chen wrote:
>> I tried to use the 32bit driver under Windows 7 32bit and it
>> seems to work fine. The simple test programs (like testlibusb
>> and testlibusb-win) run fine.
>
> The main problem I found with the 64bit applications under
> Windows 7 x64 is
On Sun, Sep 12, 2010 at 11:38 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
>> So far, good news from both of the x86 and x64 fronts. Will wait
>> for the news about performance.
>
> I tried to use the 32bit driver under Windows 7 32bit and it
> seems to work fine
On Sat, Sep 11, 2010 at 9:36 PM, Ozkan Sezer wrote:
> So far, good news from both of the x86 and x64 fronts. Will wait
> for the news about performance.
I tried to use the 32bit driver under Windows 7 32bit and it
seems to work fine. The simple test programs (like testlibusb
and testlibusb-win)
On Sat, Sep 11, 2010 at 9:58 PM, Xiaofan Chen wrote:
> On Sun, Sep 12, 2010 at 5:56 AM, Luis Lavena wrote:
>> Hello,
>>
>> I'm using mingw-w64 to cross-compile Ruby and other libraries from OSX
>> to Windows.
>>
>> Using 4.5.1 prerelease
>> (mingw-w32-1.0-bin_i686-darwin_20100702.tar.bz2) from au
On Sun, Sep 12, 2010 at 5:56 AM, Luis Lavena wrote:
> Hello,
>
> I'm using mingw-w64 to cross-compile Ruby and other libraries from OSX
> to Windows.
>
> Using 4.5.1 prerelease
> (mingw-w32-1.0-bin_i686-darwin_20100702.tar.bz2) from automated
> builds, I found that dlfcn.h is included in i686-w64-
Hello,
I'm using mingw-w64 to cross-compile Ruby and other libraries from OSX
to Windows.
Using 4.5.1 prerelease
(mingw-w32-1.0-bin_i686-darwin_20100702.tar.bz2) from automated
builds, I found that dlfcn.h is included in i686-w64-mingw32/include
directory of the package, but there is not libdl.a
On 9/11/2010 12:19 PM, Kai Tietz wrote:
> , but nevertheless libelf (which
> isn't an elf OS specific library btw) is required so that LTO works as
> it should.
Trust me, it isn't! I have never installed libelf on my build machine,
but LTO is enabled and I see dramatic improvements when I use i
2010/9/11 John E. / TDM :
> On 9/11/2010 11:50 AM, Kai Tietz wrote:
>> Well, lto normally needs not to be explicit enabled. You just need to
>> have the libelf library installed on you host environment.
>
> Actually, libelf is not required to enable LTO for PE-COFF targets (i.e.
> Windows), since
On 9/11/2010 11:50 AM, Kai Tietz wrote:
> Well, lto normally needs not to be explicit enabled. You just need to
> have the libelf library installed on you host environment.
Actually, libelf is not required to enable LTO for PE-COFF targets (i.e.
Windows), since PE-COFF and ELF are two different
2010/9/11 Ruben Van Boxem :
>> Hmm, I don't get this failure on cygwin as host. Have you installed
>>
>> lto on msys for native compiler before proper?
>>
>> Kai
>
> I'm using TDM64 GCC 4.5.1 with lto enabled, and it works for eg building Qt
> without error. I have also built and installed libelf f
>
> Hmm, I don't get this failure on cygwin as host. Have you installed
>
lto on msys for native compiler before proper?
>
> Kai
>
I'm using TDM64 GCC 4.5.1 with lto enabled, and it works for eg building Qt
without error. I have also built and installed libelf for TDM64 GCC (it's
installed in the
2010/9/11 Ruben Van Boxem :
> 2010/9/11 Ruben Van Boxem
>>
>> Hi,
>>
>> Recently I started messing around with GCC and attempted to build it many
>> times. I first had lots of trouble with the 4.5 snapshots, but have now
>> moved to 4.6 and all seems well. I put all the instructions in a single fi
2010/9/11 Ruben Van Boxem
> Hi,
>
> Recently I started messing around with GCC and attempted to build it many
> times. I first had lots of trouble with the 4.5 snapshots, but have now
> moved to 4.6 and all seems well. I put all the instructions in a single file
> (not quite a script, but almost,
Hi,
Recently I started messing around with GCC and attempted to build it many
times. I first had lots of trouble with the 4.5 snapshots, but have now
moved to 4.6 and all seems well. I put all the instructions in a single file
(not quite a script, but almost, if you're willing to call a file with
On 9/11/2010 21:44, Ruben Van Boxem wrote:
> I have uploaded a new copy of the complete MSYS package. Changes include:
> - cygtools
> - console (this is not a binary, but an automated build script, probably
> some sort of licensing issue)
> - mintty
>
> Ruben
>
>
Hi,
Keep up the good work a
I have uploaded a new copy of the complete MSYS package. Changes include:
- cygtools
- console (this is not a binary, but an automated build script, probably
some sort of licensing issue)
- mintty
Ruben
--
Start uncover
On Sat, Sep 11, 2010 at 4:39 PM, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer :
>> On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
> OK, reading wdm.h more carefully, the FASTC
2010/9/11 Ozkan Sezer :
> On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
OK, reading wdm.h more carefully, the FASTCALL declarations are
protected by an #ifdef NO_INTER
On Sat, Sep 11, 2010 at 4:15 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
>>> OK, reading wdm.h more carefully, the FASTCALL declarations are
>>> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For
On Sat, Sep 11, 2010 at 9:10 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
>> OK, reading wdm.h more carefully, the FASTCALL declarations are
>> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For x86,
>> can you please recompile by adding -DNO_INTERLOCKE
On Sat, Sep 11, 2010 at 9:04 PM, Ozkan Sezer wrote:
> OK, reading wdm.h more carefully, the FASTCALL declarations are
> protected by an #ifdef NO_INTERLOCKED_INTRINSICS guard: For x86,
> can you please recompile by adding -DNO_INTERLOCKED_INTRINSICS
> and see if it links and works?
Yes this wor
On Sat, Sep 11, 2010 at 3:46 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 8:43 PM, Ozkan Sezer wrote:
>>> set_configuration.o:set_configuration.c:(.text+0x1c8): undefined reference
>>> to `U
>>> sbd_createconfigurationreques...@8'
>>
>> For this particular one, I think you can use your old
On Sat, Sep 11, 2010 at 3:50 PM, Pete Batard wrote:
> On 2010.09.11 13:46, Kai Tietz wrote:
>> 2010/9/11 Ozkan Sezer:
>>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
> You need the @8 _and_ the leading underscore for x86
>
On 2010.09.11 13:46, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer:
>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
You need the @8 _and_ the leading underscore for x86
So you need adjusting your Makefile and libusb0_drv.def
>>>
On Sat, Sep 11, 2010 at 3:46 PM, Kai Tietz wrote:
> 2010/9/11 Ozkan Sezer :
>> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
You need the @8 _and_ the leading underscore for x86
So you need adjusting your Makefile and libus
On Sat, Sep 11, 2010 at 8:43 PM, Ozkan Sezer wrote:
>> set_configuration.o:set_configuration.c:(.text+0x1c8): undefined reference
>> to `U
>> sbd_createconfigurationreques...@8'
>
> For this particular one, I think you can use your old usbd.def file but, ...
Yes you are right. I just reverted to
2010/9/11 Ozkan Sezer :
> On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
>> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
>>> You need the @8 _and_ the leading underscore for x86
>>> So you need adjusting your Makefile and libusb0_drv.def
>>> for two different builds.
>>
>> Thanks. I
On Sat, Sep 11, 2010 at 3:37 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
>> You need the @8 _and_ the leading underscore for x86
>> So you need adjusting your Makefile and libusb0_drv.def
>> for two different builds.
>
> Thanks. I fixed the Makefile and now I hav
On Sat, Sep 11, 2010 at 8:31 PM, Ozkan Sezer wrote:
> You need the @8 _and_ the leading underscore for x86
> So you need adjusting your Makefile and libusb0_drv.def
> for two different builds.
Thanks. I fixed the Makefile and now I have the following.
windres -I./src --target=pe-i386 ./src/dri
On Sat, Sep 11, 2010 at 3:20 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>> Oki dokie, msg received. Lets try with this new one (changed the
>> static inline to extern __inline __attribute__((__gnu_inline__))
>
> BTW, could you provide similar file for x86? Thank
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
> Oki dokie, msg received. Lets try with this new one (changed the
> static inline to extern __inline __attribute__((__gnu_inline__))
BTW, could you provide similar file for x86? Thanks.
I changed the Makefile to build the 32bit driver with TDM
On Sat, Sep 11, 2010 at 8:01 PM, Kai Tietz wrote:
> Another thing about performance issues here (those inlines will help
> for sure a bit). What optimizations you are using for gcc?
>
I am using -O2.
Actually the WDK build is with debug option on, not the release build.
But I need to carry out s
2010/9/11 Xiaofan Chen :
> On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>>>Try a recompile with this and see
>>>- if the likage succeds
>>>- if you still have a performance issue by comparison to the msvc builds
>>
>> Oki dokie, msg received. Lets try with this new one (changed the
>> stati
On Sat, Sep 11, 2010 at 4:00 PM, Ozkan Sezer wrote:
>>Try a recompile with this and see
>>- if the likage succeds
>>- if you still have a performance issue by comparison to the msvc builds
>
> Oki dokie, msg received. Lets try with this new one (changed the
> static inline to extern __inline __att
On Sat, Sep 11, 2010 at 10:52 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 3:38 PM, Ozkan Sezer wrote:
>>> It will still producing the following linking errors. Take note the
>>> underscore.
>>>
>>
>> Well, that should be the easy part to fix, see the new version attached
>> (was my fault f
On Sat, Sep 11, 2010 at 3:38 PM, Ozkan Sezer wrote:
>> It will still producing the following linking errors. Take note the
>> underscore.
>>
>
> Well, that should be the easy part to fix, see the new version attached
> (was my fault forgetting to add the underscores)
>
> Try a recompile with this
On Sat, Sep 11, 2010 at 10:34 AM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>>> I will carry out more tests but it seems there are performance issues
>>> when using the MinGW-w64 build of libusb0.sys compared to the WDK
>>> build, especially when using as a filter
On Sat, Sep 11, 2010 at 3:34 PM, Xiaofan Chen wrote:
> On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>> Try adding the attached inlines to your wdm.h (I think around line 242 just
>> before the #endif /* defined(__GNUC__) */ ) and remove the -lmingwex
>> from your makefile. These are the I
On Sat, Sep 11, 2010 at 2:44 PM, Ozkan Sezer wrote:
>> I will carry out more tests but it seems there are performance issues
>> when using the MinGW-w64 build of libusb0.sys compared to the WDK
>> build, especially when using as a filter driver. I am wondering if this can
>> be the consequences of
41 matches
Mail list logo
