On Wed, Feb 26, 2014 at 3:06 PM, Adrien Nader wrote:
> Hi,
>
> On Wed, Feb 26, 2014, Xiaofan Chen wrote:
>> On Tue, Feb 18, 2014 at 9:08 AM, Xiaofan Chen wrote:
>> > Ref: http://marc.info/?l=libusb-devel&m=139259972118999&w=2
>> >
>> > I'd
On Tue, Feb 18, 2014 at 9:08 AM, Xiaofan Chen wrote:
> Ref: http://marc.info/?l=libusb-devel&m=139259972118999&w=2
>
> I'd like to seek the advice from MinGW-w64 project on which
> compiler to use to build libusb binary (now that libusb and
> libusbx project are merg
Ref: http://marc.info/?l=libusb-devel&m=139259972118999&w=2
I'd like to seek the advice from MinGW-w64 project on which
compiler to use to build libusb binary (now that libusb and
libusbx project are merged, we will refer to them as libusb).
My understanding is that libusb is a C only project so
On Tue, Feb 19, 2013 at 11:23 PM, Xiaofan Chen wrote:
> On Tue, Feb 19, 2013 at 9:48 PM, Ruben Van Boxem
> wrote:
>> 2. Forget everything I said above, and add
>>
>> -DMS_WIN64
>>
>> to your module compilation. This will fix all of your problems (it fixed
&
On Tue, Feb 19, 2013 at 9:48 PM, Ruben Van Boxem
wrote:
>
> Note official Python 2.7 uses MSVC2008 and Python 3.x use MSVC2010.
>
> Two things:
> 1. You're sure you have installed the MSVC++ redistributables
> that Python needs? Check with Dependency Walker to be sure.
Thanks. I have access to MS
On Tue, Feb 19, 2013 at 5:22 PM, JonY wrote:
> On 2/19/2013 08:12, Xiaofan Chen wrote:
>> On Tue, Feb 19, 2013 at 6:12 AM, JonY wrote:
>>> On 2/18/2013 22:56, Xiaofan Chen wrote:
>>>> Ref:
>>>> http://developer.intra2net.com/mailarchive/html/libftdi/2
On Tue, Feb 19, 2013 at 6:12 AM, JonY wrote:
> On 2/18/2013 22:56, Xiaofan Chen wrote:
>> Ref:
>> http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html
>>
>> I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for
>> libftdi1-
Ref: http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html
I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for
libftdi1-1.0 ( http://www.intra2net.com/en/developer/libftdi/download.php )
with MinGW-w64 (Ruben personal build 4.7.2 release).
But somehow it does no
On Wed, Jan 23, 2013 at 2:58 PM, Jim Michaels wrote:
>
> and, alas, microsoft has made sp2 unavailable and xp next year is support
> EOL except for embedded. so SP1 users (like me) are out of luck unless they
> have already downloaded and burned a copy of SP2 and SP3. after EOL, updates
> will no
On Wed, Jan 23, 2013 at 2:50 PM, Jim Michaels wrote:
> just what is TDM-GCC? I have seen this mentioned a number
> of times, but I haven't seen a folder for it in the mingw-w64 folder tree
> that I remember.
>
> my guess is it's some sort of code name for something.
>
TDM-GCC is a disro of MinGW.
On Mon, Nov 12, 2012 at 3:55 PM, Pau Garcia i Quiles
wrote:
> As for your concerns about CMake being available or not: it's
> available from all Linux and BSD variants I know because more and more
> projects are moving to CMake because more and more projects are
> concerned about cross-platform, i
On Mon, Jun 18, 2012 at 4:05 PM, Xiaofan Chen wrote:
> On Mon, Jun 18, 2012 at 2:41 PM, Ruben Van Boxem
> wrote:
>> You're. Somehow trying to build with -m32, which is multilib, which is not
>> enabled in my build. I'm not sure why gcc doesn't complain; it shoul
On Mon, Jun 18, 2012 at 2:41 PM, Ruben Van Boxem
wrote:
> You're. Somehow trying to build with -m32, which is multilib, which is not
> enabled in my build. I'm not sure why gcc doesn't complain; it should. If
> you want to build 32-bit binaries with my toolchains, you will have to
> download the
After sorting out issues with the libusbx build, my next experiment
is with libusbK examples build. Take note we only support WDK
for the driver build and WDK/MSVC for the library, tools and driver
installer. We do support MSVC and MinGW-w64 for the examples
build. So far we use TDM64 as the offici
On Mon, Jun 18, 2012 at 10:39 AM, Xiaofan Chen wrote:
> On Sun, Jun 17, 2012 at 7:26 PM, Ruben Van Boxem
> wrote:
>> 2012/6/17 Xiaofan Chen
>>> On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz
>>> wrote:
>>> > Yes, the .def file has a syntax error and shoul
On Sun, Jun 17, 2012 at 7:26 PM, Ruben Van Boxem
wrote:
> 2012/6/17 Xiaofan Chen
>> On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz
>> wrote:
>> > Yes, the .def file has a syntax error and should be fixed.
>> >
>> > there is a LIBRARY command specifying no
On Mon, Jun 18, 2012 at 9:14 AM, Chris Sutcliffe wrote:
> On 17 June 2012 09:29, Ruben Van Boxem wrote:
>> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
>> website.
>
> Anybody else have them as showing non-downloadable even though they
> were uploaded to SourceForge 12 hour
On Sun, Jun 17, 2012 at 9:29 PM, Ruben Van Boxem
wrote:
> Hi all,
>
> I have uploaded the newest GCC release 4.7.1 to the MinGW-w64 SF.net
> website.
>
> Updated since the last round of builds:
> - binutils/gdb to latest master state
> - GMP to 5.0.5
> - libexpat to v2.1
>
> MinGW-w64 crt and h
On Sun, Jun 17, 2012 at 6:13 PM, Kai Tietz wrote:
> Yes, the .def file has a syntax error and should be fixed.
>
> there is a LIBRARY command specifying no library name, which is a syntax
> error.
>
> Change .def file from
>
> LIBRARY
> EXPORTS
> libusb_alloc_transfer
> ...
>
> to:
> LIBRARY "li
On Sun, Jun 17, 2012 at 1:07 PM, Xiaofan Chen wrote:
> Usually I use MinGW.org (32bit) and TDM64 for libusb/libusbx/libusbk
> related testing. So today I gave the personal build of rubenvb a try
> and tried to build libusbx 1.0.12 release but somehow it failed.
> TDM64 is okay.
Usually I use MinGW.org (32bit) and TDM64 for libusb/libusbx/libusbk
related testing. So today I gave the personal build of rubenvb a try
and tried to build libusbx 1.0.12 release but somehow it failed.
TDM64 is okay. Tested under Windows XP 64bit.
The reason might be the bundled dlltool.exe insid
On Mon, Jun 4, 2012 at 9:26 AM, Xiaofan Chen wrote:
> On Sun, Jun 3, 2012 at 7:22 PM, Ruben Van Boxem
> wrote:
>> What do you mean? MinGW-w64 is completely seperate from the Windows SDK and
>> whatever they leave out of it. If anything MinGW-w64 will become really
>> p
On Mon, Jun 4, 2012 at 9:14 AM, NightStrike wrote:
> I could forsee an issue where future OS's contain an extremely
> stripped down msvcrt.dll, forcing users to have a copy of the VS crt
> dll to do anything worthwhile. In this case, ironcrate will become a
> necessity. But that's not MS's direc
On Sun, Jun 3, 2012 at 7:22 PM, Ruben Van Boxem
wrote:
> What do you mean? MinGW-w64 is completely seperate from the Windows SDK and
> whatever they leave out of it. If anything MinGW-w64 will become really
> popular (I mean even more than right now) real fast because of this...
That is quite pos
On Sat, Apr 14, 2012 at 4:36 PM, JonY wrote:
> Don't do that, add -I/path/to/ddk instead, and get rid of the ddk/
> prefix in your include lines, its only applicable to mingw.org.
> mingw-w64 follows MSVC DDK conventions.
What do you mean by "mingw-w64 follows MSVC DDK conventions"?
I can not see
] libusb-1.0.9-rc1 pushed,
libusb.git/testing, what now?
To: libusb-de...@lists.sourceforge.net
On 2011.09.18 15:33, Xiaofan Chen wrote:
> There are two minor warnings for MinGW-w64 4.6.2 gcc.
>
> CC libusb_1_0_la-io.lo
> ../../libusb/io.c: In function 'get_next_timeout'
On Sun, Aug 7, 2011 at 6:49 PM, Xiaofan Chen wrote:
>
> LinkedIn
>
> I'd like to add you to my professional network on LinkedIn.
>
Please ignore this. I accidentally click a "yes".
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- Xiaofan
Xiaofan Chen
Staff Engineer at Rockwell Automation
Singapore
Confirm that you know Xiaofan Chen
https://www.linkedin.com/e/-dalyc2-gr1w4f2h-6j/isd/3781283553/T5EkL8JE/
--
(c) 2011, Lin
On Fri, Aug 5, 2011 at 7:30 AM, Greg Peele wrote:
> Does anyone know of a site which hosts pre-built Win64 binaries / developer
> kits for common open source C libraries? I haven't been able to find one so
> I've been building random things such as zlib, libpng, libjpeg, etc. using
> MinGW-w64 si
On Fri, Oct 1, 2010 at 7:44 AM, JonY wrote:
>> BTW, what is the supported OS for MinGW-w64 32bit and 64bit
>> tool chain. Win2k onwards? Or XP onwards? I could not find this
>> out from the Wiki.
>>
>
> XP onwards, ymmv with Win2k.
Thanks for the information. Maybe this should be put prominately
i
On Wed, Sep 29, 2010 at 9:52 PM, JonY wrote:
> On 9/29/2010 21:39, Dongsheng Song wrote:
>> But we can not ensure third party software DO NOT call those functions,
>> so we must drop them or defined in guard blocks like this:
>>
>> /* Windows 7 */
>> #if _WIN32_WINNT >= 0x0601
>> #endif
>>
>> /* W
On Thu, Sep 30, 2010 at 2:09 PM, JonY wrote:
> It is available in Windows 7 msvcrt.dll, of course, that doesn't mean
> you should call it if you want your program to work on an older version
> of Windows.
>
> The comments in the def files are not entirely accurate, msvcrt.dll has
> versions as wel
On Thu, Sep 30, 2010 at 9:43 AM, Dongsheng Song
wrote:
> Maybe there have another solution:
>
> S1: the intersection of XP and 2k3 symbols in msvcrt.dll
> S2: the intersection of VISTA and 2k8 symbols in msvcrt.dll
> S3: the Windows 7 symbols in msvcrt.dll
>
> libmsvcrt: S1
> libvista: (S2 - S1)
On Wed, Sep 29, 2010 at 10:06 PM, JonY wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/29/2010 21:56, Xiaofan Chen wrote:
>> On Wed, Sep 29, 2010 at 5:56 PM, JonY wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
On Wed, Sep 29, 2010 at 5:56 PM, JonY wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 9/29/2010 16:34, Dongsheng Song wrote:
>> When I build libiconv NLS version, I can not run iconv.exe, which reference
>> a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol
On Tue, Sep 21, 2010 at 10:19 AM, Xiaofan Chen wrote:
> On Tue, Sep 21, 2010 at 8:27 AM, JonY wrote:
>> libusb usb.h can live in its own dir. All that is needed is the proper -I.
>> In libusb usb.h, use #include_next to include mingw-w64 usb.h.
>>
>> Its that simpl
On Tue, Sep 21, 2010 at 8:27 AM, JonY wrote:
>>> Long time reader of this discussion :)
>>> Why not just add this to the bottom/top of libusb's usb.h header:
>>>
#ifdef __MINGW64_VERSION_MAJOR
#include_next
#endif // __MINGW64_VERSION_MAJOR
Actually it is not libusb-w
On Mon, Sep 20, 2010 at 10:30 PM, Ruben Van Boxem
wrote:
> 2010/9/20 JonY
>> OK, I see. I suppose some include_next tricks are in order for libusb.
>>
>
> Long time reader of this discussion :)
> Why not just add this to the bottom/top of libusb's usb.h header:
>
>> #ifdef __MINGW64_VERSION_MAJOR
On Mon, Sep 20, 2010 at 9:57 PM, Ozkan Sezer wrote:
> On Mon, Sep 20, 2010 at 4:03 PM, Xiaofan Chen wrote:
>> In this case, MinGW is actually following MS side, and not MinGW-w64,
>> Even Kai Tietz admits that MinGW-w64 usb.h belongs to DDK. It is just
>> because of the co
On Mon, Sep 20, 2010 at 8:50 PM, Earnie wrote:
> Ozkan Sezer wrote:
>> Mingw has not been updating their ddk for years and certainly they
>> don't reflect the changes is directory structure from the MS side:
>> mingw does not define the api or directory structure, ms does.
>>
>> I think we put eve
On Mon, Sep 20, 2010 at 1:28 AM, Kai Tietz wrote:
> The usb.h header is here in our platform headers as we need it for the
> case that no ddk is installed and somebody wants to use winusb.h
> header.
OK this is a very good reason. WinUSB is useful. And indeed using
WinUSB will need to have access
On Sun, Sep 19, 2010 at 6:44 PM, Ozkan Sezer wrote:
>> However, MinGW does not break existing software and puts
>> those files inside include\ddk sub-directory. Why not
>> MinGW-w64?
>
> What will happen to other software that expect usb.h
> out of ddk subdirectory, then?
Please name one. And you
On Sun, Sep 19, 2010 at 6:18 PM, Ozkan Sezer wrote:
>> Yes WDK has several directories of headers. Apparently
>> "api" sub-directory is more than the "SDK counterpart"
>> since it includes many files not included in the SDK.
>>
>
> The point is, the "api" subdirectory also contains windows.h,
> e
On Sun, Sep 19, 2010 at 4:54 PM, Ozkan Sezer wrote:
>>> I said that assuming mingw-w64 was following MS. Ozkan where
>>> does usb.h live in MS's SDK stack?
>>
>
> Dongsheng Song is correct that WDK has it in the "api"
> directory which is the sdk counterpart in their standalone
> ddk package. (WD
On Sun, Sep 19, 2010 at 9:54 AM, JonY wrote:
> All the headers provided under our include directory are
> already part of sdk, therefore I don't know how a separation
> can be possible.
>
> Admins?
>
Personally, I think deviating from MS is a bad idea. If ms puts it in
On Sun, Sep 19, 2010 at 10:04 AM, Dongsheng Song
wrote:
> On Sun, Sep 19, 2010 at 07:50, Ozkan Sezer wrote:
>>
>> AFAIK, usb.h is out of ddk because it is part of ms platform sdk,
>> therefore, it _needs_ to be out of a ddk subdirectory for proper
>> compatibility.
>
> No, usb.h is in MS WDK 7.1
On Sun, Sep 19, 2010 at 9:44 AM, Xiaofan Chen wrote:
> On Sun, Sep 19, 2010 at 9:03 AM, JonY wrote:
>>> All the headers provided under our include directory are
>>> already part of sdk, therefore I don't know how a separation
>>> can be possible.
>>
On Sun, Sep 19, 2010 at 9:03 AM, JonY wrote:
>> All the headers provided under our include directory are
>> already part of sdk, therefore I don't know how a separation
>> can be possible.
>>
>> Admins?
>>
> Personally, I think deviating from MS is a bad idea. If ms puts it in the
> normal psdk, s
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezer wrote:
> On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chen wrote:
>> I think the MinGW-w64 newly included usb.h will break
>> many existing software which uses libusb-win32. For
>> example, libftdi's header is called ftdi.h whic
On Sun, Sep 12, 2010 at 5:34 PM, Xiaofan Chen wrote:
> On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
>> 2. the name of your src/usb.h is, well, usb.h, and it conflicts, ie.
>> searched before the system provided usb.h. Therefore, it must be
>> renamed to something el
On Sun, Sep 12, 2010 at 5:26 PM, Ruben Van Boxem
wrote:
>> building. What is the easy way to differentiate MinGW-w64
>> 32bit compiler and MinGW.org 32bit compiler? Then we
>> can add ifdefs in the source codes to cater for both in the
>> future.
>>
>> The current codes are set up in a way to supp
On Sun, Sep 12, 2010 at 11:52 AM, Xiaofan Chen wrote:
> 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 performanc
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().
>>
>>
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
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 a
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 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-
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 pleas
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 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
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 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
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 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 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 mak
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
On Fri, Sep 10, 2010 at 4:37 PM, Kai Tietz wrote:
Hrmph, I guess the only way here is to bite the bullet and
really add a -lmingwex after all other libs. However it would
have been really nice if we provided them as always_inlines
>>> Hmm, always inline is bad too. As gcc
On Fri, Sep 10, 2010 at 10:16 PM, Travis wrote:
> I'm playing catch up here so apologies if this has already been covered,
> but..
>
> There is an @8 on DriverEntry in the libusb0_drv.def file. I'm not exactly
> sure how gcc handles this on a 64bit machine. Could this be causing a
> problem?
As
On Fri, Sep 10, 2010 at 5:59 PM, Xiaofan Chen wrote:
>> Not sure here, it could be here undefined references DLLs, or
>> unavailable API. You can check imports here by using objdump -x
>> to see more details.
>
> I will check that.
Even though the issue seems to be
On Fri, Sep 10, 2010 at 6:40 PM, Ozkan Sezer wrote:
> On Fri, Sep 10, 2010 at 1:34 PM, Xiaofan Chen wrote:
>> On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
>>
>>> Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
>>> to it? AFAICS,
On Fri, Sep 10, 2010 at 6:31 PM, Ozkan Sezer wrote:
> Speaking of linkage to usbd.sys, where did you get libusbd.a for linking
> to it? AFAICS, we don't provide it (shame on us.) Your libusb0.sys looks
> for a _USBD_CreateConfigurationRequestEx, notice the leading underscore,
> so can this be th
Thanks for all the suggestions. I will try them and report back.
On our side, we need quite a bit of cleaning on supporting MinGW-w64
as well, not only for the driver building, but also for other parts
(dll/filter/test/testwin target) and fix the Makefile for infwizard
(mixed 32bit/64bit build iss
On Fri, Sep 10, 2010 at 5:43 PM, Kai Tietz wrote:
>> Unfortunately it does not work under Windows 7 x64.
>>
>> I got the following error.
>> "Windows cannot load the device driver for this hardware.
>> The driver may be corrupted or missing. (Code 39)"
>>
>> I will update later with more informat
On Fri, Sep 10, 2010 at 4:27 PM, Xiaofan Chen wrote:
>> Thanks for the explanations. Now I need to test this MinGW-w64
>> build driver. I will come back if I encounter problems.
>
> The modified source and binaries are archived here.
> http://code.google.com/p/picusb/down
On Fri, Sep 10, 2010 at 4:21 PM, Xiaofan Chen wrote:
> On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz wrote:
>>>> Hrmph, I guess the only way here is to bite the bullet and
>>>> really add a -lmingwex after all other libs. However it would
>>>> have
On Fri, Sep 10, 2010 at 4:18 PM, Kai Tietz wrote:
>>> Hrmph, I guess the only way here is to bite the bullet and
>>> really add a -lmingwex after all other libs. However it would
>>> have been really nice if we provided them as always_inlines
>>
>> Yes changing the Makefile to link to libmingwex
On Fri, Sep 10, 2010 at 3:59 PM, Ozkan Sezer wrote:
Well, to link without mingwex library cause here for sure issues as
all intrinsics are missing. If they can't link to this library, then
they need to provide at least a library which declares those
intrinsics of VC, which are
On Fri, Sep 10, 2010 at 3:34 PM, Kai Tietz wrote:
>>> On 64-bit are acutual no Interlocked...-API. It reflects always to
>>> _Interlocked..-API on x64. But why you get unresolved externals? We
>>> are providing those intrinsics in libminwex.a
>>
>> See wdm.h, they are probably expected to be expor
On Fri, Sep 10, 2010 at 3:29 PM, Ozkan Sezer wrote:
>>> gcc -o libusb0.sys abort_endpoint.o claim_interface.o clear_feature.o
>>> dispatch.o
>>> get_configuration.o get_descriptor.o get_interface.o get_status.o ioctl.o
>>> libus
>>> b_driver.o pnp.o release_interface.o reset_device.o reset_endp
On Fri, Sep 10, 2010 at 2:07 PM, Ozkan Sezer wrote:
> Well, src/driver/usbdlib_gcc.h at line around 23, I added :
>
> #if !defined(DDKAPI)
> #define DDKAPI NTAPI
> #endif
>
> ... and error.c compiled just fine.
>
Thanks a lot for the fast help. Now every files can be compiled. The linking
step f
On Fri, Sep 10, 2010 at 12:16 PM, Xiaofan Chen wrote:
> Now it is getting very close. Hopefully you guys have some idea
> to fix this last problem. Thanks a lot.
>
> mc...@mcuee-pc-win7 /d/work/mingw-w64/libusb-win32-src-1.2.1.20
> $ make driver -i
> gcc -c ./src/error.c -o erro
On Thu, Sep 9, 2010 at 7:50 AM, Xiaofan Chen wrote:
> On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
>> I made some progress: I checked out branches/libusb-testing/ from
>> your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c
>> and it succeeded with
On Thu, Sep 9, 2010 at 12:09 PM, John E. / TDM wrote:
> On 9/8/2010 9:43 PM, Xiaofan Chen wrote:
>> I see. This makes sense. However, TDM64 does use "gcc", under
>> 32bit or 64bit Windows. I think it is a cross-compiler as well.
>
> No, TDM64 GCC is a native x8
On Thu, Sep 9, 2010 at 11:11 AM, JonY wrote:
>> Can this be fixed and lib64 directory be removed?
>>
> If you have moved them and lib64 becomes empty, yes.
Move them to lib, right? What are the use of those files?
>> Another thing, typically other MinGW-w64 binaries for Windows
>> will have gcc
On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 10:36 AM, JonY wrote:
>>
>> Ok, to clear everything up, for non-multilib 4.6, you should only have
>> "lib", "lib64" only if you have non-multilib 4.5.
>>
>
> It s
On Thu, Sep 9, 2010 at 3:53 AM, Ozkan Sezer wrote:
> I made some progress: I checked out branches/libusb-testing/ from
> your libusb-win32 svn, I tried compiling src/driver/abort_endpoint.c
> and it succeeded with the following changes:
>
> 1. one thing causing the mess was the windows.h include
On Wed, Sep 8, 2010 at 1:22 PM, Xiaofan Chen wrote:
> On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer wrote:
>
>> See
>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
>> I'd say take
>> http://mingw-w64.svn.sourceforge.net/vie
On Wed, Sep 8, 2010 at 1:16 PM, Ozkan Sezer wrote:
> See
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/
> I'd say take
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include/ddk/
> from there and put it into its exclusive directory l
On Tue, Sep 7, 2010 at 11:13 PM, Ozkan Sezer wrote:
> On Tue, Sep 7, 2010 at 6:02 PM, Xiaofan Chen wrote:
>>> I am not using the ddk from mingw.org. I am using the TDM64 version.
>>> I believe the ddk inside TDM64 is from the svn version.
>>
>
> The order here is
On Tue, Sep 7, 2010 at 9:58 PM, JonY wrote:
> Please do not use the ddk from mingw.org, use the ones from svn instead.
>
> The ddk headers in use by mingw-w64 is from ReactOS, you could say they are
> more complete.
I am not using the ddk from mingw.org. I am using the TDM64 version.
I believe th
On Tue, Sep 7, 2010 at 9:18 PM, JonY wrote:
> Hi,
>
> I assume this is a 32bit build with mingw-w64.
>
> -mno-cygwin option is unsupported at all on win64, and soon to be removed
> even on 32bit target.
Yes we can remove that. This is for the Cygwin.
> -DWINVER=0x500 does not work on mingw-w64,
On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chen wrote:
> On Tue, Sep 7, 2010 at 10:36 AM, JonY wrote:
>>
>> Ok, to clear everything up, for non-multilib 4.6, you should only have
>> "lib", "lib64" only if you have non-multilib 4.5.
>>
>
> It s
On Tue, Sep 7, 2010 at 10:36 AM, JonY wrote:
>
> Ok, to clear everything up, for non-multilib 4.6, you should only have
> "lib", "lib64" only if you have non-multilib 4.5.
>
It seems the latest automatic build version still has the same issue
as previous versions, I just checked the following one
On Tue, Sep 7, 2010 at 9:40 AM, JonY wrote:
> I think I can see where the problem is, but I'm still guessing at this
> point.
>
> TDM multilib has lib and lib32, but your non-multilib has lib and lib64, and
> they are not linked. I suppose the fix is to move all the contents in lib
> (or lib64) to
On Mon, Sep 6, 2010 at 11:15 PM, John E. / TDM wrote:
> It is correct that TDM64 GCC does not include a "lib64" directory of any
> sort (symlink or copy). I've simply never found it necessary when building
> GCC or any of the other software I build on a regular basis.
>
> Since GCC searches the "
On Tue, Sep 7, 2010 at 8:12 AM, JonY wrote:
>> My problem is that libtool was pointing to lib64 directory in the 64bit
>> cross build (under Linux or 32bit Windows) cases. I need to check again
>> under 32bit Win 7 with TDM.
>>
>> I just checked under Windows 7 64bit and TDM64 is okay there
>> wit
On Mon, Sep 6, 2010 at 11:15 PM, John E. / TDM wrote:
> It is correct that TDM64 GCC does not include a "lib64" directory of any
> sort (symlink or copy). I've simply never found it necessary when building
> GCC or any of the other software I build on a regular basis.
>
> Since GCC searches the "
On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
> Are you using a multilib setup? There should not be a lib64 directory around
> for non-multilib toolchains.
>
> If you are using a multilib setup, lib is where the arch default libraries
> are. For x86_64-w64-mingw32, lib points to lib64.
>
BTW, for T
On Mon, Sep 6, 2010 at 7:26 PM, JonY wrote:
> Are you using a multilib setup? There should not be a lib64 directory around
> for non-multilib toolchains.
I have tried different binary downloads. The one from MinGW-w64 Sourceforge
site and the one from http://www.drangon.org/mingw/ both are not
mu
1 - 100 of 101 matches
Mail list logo
