On 12/06/2014 7:02 pm, Xiaofan Chen wrote: > On Thu, Jun 12, 2014 at 3:47 PM, Andrew Leech <[email protected]> wrote: >> On 2/06/2014 3:52 PM, Paul Fertser wrote: >>> On Mon, Jun 02, 2014 at 02:48:21PM +1000, Andrew Leech wrote: >>>> I quickly ditched it and used msys2 to set up a nice clean relocatable >>>> install of mingw64 that I could transfer to the build machine easily. >>> This is an interesting note indeed. Do you think msys2 has the >>> potential to become "Homebrew for Windows"? Have you probably tried >>> porting the OpenOCD recipe from "Arch Linux" GNU/Linux distro to >>> msys2? >>> >>> If it'd be possible to self-compile OpenOCD HEAD on windows as easily >>> as it is now with "brew" on OS X, that would be rather useful. >>> >>> Please keep us updated, I'm ready to add easy building instructions to >>> README.Windows as soon as they're available. >>> >> Hi Paul, >> I have a feeling it could be. I've been working with it and openocd over >> the last few days and have a workable solution up and running. > I am not so sure after trying it for once under Windows two days > ago and in the end delete the whole thing after getting multiple > problems with MSys 2. > > I am quite good at messing up with different systems > and I have no problems with pacman under Arch > Linux. However, it seems the pacman port under > MSys 2 does not work well. > > Anyway, I might want to give it another try since there > are quite some people seem to have good success > with MSys 2 from the MinGW-w64 mailing list. I can't say I've used it a lot, but have certainly found it quicker to use to get a useful *nix style build system under windows. I've been liking pacman in msys2 a lot more than any msys or cygwin one's I've used in the past, although I've never used arch before to know how different it is there, I'm more of a debian/mint far on the linux side. It took a little while to get used to the separation in the three different console launchers, and the fact that binary packages are similarly segregated into whether you're using the msys gcc or mingw ones. I've stuck with the mingw-w32 personally.
I'd expect the 64 bit console/build to work fine as well, just haven't tried it yet. I'm not sure if there's much advantage to a native 64 bit build under windows? The issue with the console launching bat files is a bit strange, I'm not sure if the shipped ones work for some people, not sure how they could? Either way I can't complain too much, I've fixed it for myself (as described on my wiki) but haven't actually published any patch upstream. >> >> I've forked the scripts repo and added packages for libusb, >> libusb-compat and openocd, both 0.8.0 and git-master. >> I've also done a really quick walkthrough to get it all compiled and >> installed, although no guarantees I haven't missed anything, I haven't >> been through it in one go on a different machine yet. >> >> Instructions: >> https://gitlab.alelec.net/corona/mingw-packages/wikis/openocd_msys2_mingw_w64 >> > Once potential problem could be with libusb-compat. It is not > officially supported by the libusb project under Windows since > there is this libusb-win32 project which is still alive. > > I happen to be both the admin of libusb-win32 and libusb. Even > though we do not plan anything new things to libusb-win32 it still > enjoy very wide use and so far we do not see any need to > have the new libusb-compat under Windows since it > will not offer many advantages compared to libusb-win32. > In fact it can not support the full feature of libusb-win32 > API which is a superset of libusb-0.1/libusb-compat. > I'm certainly not going to argue with you on this, I only threw the libusb-compat script together today just to get openocd to compile with the standard adapters enabled following the homebrew suggestions for that package. I've previously used libusb-win32 on windows and I'm certainly happy to push it over libusb-compat if it's still the preferred libusb 0.1 layer on windows. The lack of official support for libusb-compat on windows makes a lot of sense to me, considering it wouldn't just build for me. I did have to make a small patch for it to cover some undefined things (u_int*_t types and ENODATA in errno.h) Cheers, Andrew ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
