Menu
▾
▴
openocd-devel
|
From: Ram B. <ra...@ra...> - 2014-06-01 21:11:10
|
How hard would it be to make OpenOCD build with visual studio? Would that be a worthwhile goal? I am willing to do this work - but I don't know if this would be considered valuable by the project. Thanks for any info. -Ram |
|
From: Paul F. <fer...@gm...> - 2014-06-02 03:41:04
|
Hi, On Sun, Jun 01, 2014 at 01:53:06PM -0700, Ram Bhamidipaty wrote: > How hard would it be to make OpenOCD build with visual studio? Would that be a > worthwhile goal? It would be impossible without massive modifications as MSVC doesn't support C99. I do not see why anyone might want it. > I am willing to do this work - but I don't know if this would be considered > valuable by the project. What's your motivation here? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Ram B. <ra...@ra...> - 2014-06-02 04:13:47
|
On 06/01/14 20:40, Paul Fertser wrote: > Hi, > > On Sun, Jun 01, 2014 at 01:53:06PM -0700, Ram Bhamidipaty wrote: >> How hard would it be to make OpenOCD build with visual studio? Would that be a >> worthwhile goal? > It would be impossible without massive modifications as MSVC doesn't > support C99. I do not see why anyone might want it. Right - I forgot about that. > >> I am willing to do this work - but I don't know if this would be considered >> valuable by the project. > What's your motivation here? > My impression is that the Windows build with Cygwin was a bit hard to duplicate. A while back (maybe 2 years) there were discussions on the list about the exact set of packages that were needed to build OpenOCD. It seemed (at that time) that creating a reproducible windows build environment was not so simple. Perhaps MinGW is easier? If that is no longer true - then there would be no need for this. And it may not matter since the C99 issue would be too much work. -Ram I woul |
|
From: Paul F. <fer...@gm...> - 2014-06-02 04:22:09
|
On Sun, Jun 01, 2014 at 09:13:37PM -0700, Ram Bhamidipaty wrote: > My impression is that the Windows build with Cygwin was a bit hard to > duplicate. A while back (maybe 2 years) there were discussions on the > list about the exact set of packages that were needed to build OpenOCD. > It seemed (at that time) that creating a reproducible windows build > environment was not so simple. Perhaps MinGW is easier? Should be rather easy now, both with Cygwin (+MinGW-w64 toolchain) and MSYS+MinGW-w64. Please see the README and README.Windows for details. > If that is no longer true - then there would be no need for this. And it > may not matter since the C99 issue would be too much work. Right. Please report if you find any issues with the current procedure. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Andrew L. <cor...@gm...> - 2014-06-02 04:48:35
|
On 2/06/2014 2:21 PM, Paul Fertser wrote: > On Sun, Jun 01, 2014 at 09:13:37PM -0700, Ram Bhamidipaty wrote: >> My impression is that the Windows build with Cygwin was a bit hard to >> duplicate. A while back (maybe 2 years) there were discussions on the >> list about the exact set of packages that were needed to build OpenOCD. >> It seemed (at that time) that creating a reproducible windows build >> environment was not so simple. Perhaps MinGW is easier? > Should be rather easy now, both with Cygwin (+MinGW-w64 toolchain) and > MSYS+MinGW-w64. Please see the README and README.Windows for details. > >> If that is no longer true - then there would be no need for this. And it >> may not matter since the C99 issue would be too much work. > Right. Please report if you find any issues with the current > procedure. > If you're really keen to give msvc a go you could try running the compile through c99wrap (https://github.com/libav/c99-to-c89/) which was written to compile ffmpeg/libav under msvc. I tried it out with ffmpeg simply because we use msvc on our build machine for other projects, however I found it so difficult to get going 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. Realistically, even if c99wrap works, if you want to support compiling under msvc you either need to use cmake or similar to generate vcproj's on demand based on build environment (and therefore have a dependency on cmake being installed) or someone needs to maintain checked in project files - not much fun at all. Cheers, Andrew |
|
From: Paul F. <fer...@gm...> - 2014-06-02 05:52:40
|
Hi Andrew, 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. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Andrew L. <cor...@gm...> - 2014-06-12 07:47:23
|
On 2/06/2014 3:52 PM, Paul Fertser wrote: > Hi Andrew, > > 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. Most packages on msys2 are distributed in binary form using pacman (ported from arch), but the definitions scripts they're built from are all on github and can be used directly with makepkg. 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 Cheers, Andrew |
|
From: Xiaofan C. <xia...@gm...> - 2014-06-12 09:02:23
|
On Thu, Jun 12, 2014 at 3:47 PM, Andrew Leech <cor...@gm...> 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. > Most packages on msys2 are distributed in binary form using pacman > (ported from arch), but the definitions scripts they're built from are > all on github and can be used directly with makepkg. > > 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. -- Xiaofan |
|
From: Andrew L. <cor...@gm...> - 2014-06-12 11:45:41
|
On 12/06/2014 7:02 pm, Xiaofan Chen wrote: > On Thu, Jun 12, 2014 at 3:47 PM, Andrew Leech <cor...@gm...> 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 |
|
From: Spencer O. <sp...@sp...> - 2014-06-02 07:55:41
|
On 2 June 2014 05:13, Ram Bhamidipaty <ra...@ra...> wrote: > > On 06/01/14 20:40, Paul Fertser wrote: >> Hi, >> >> On Sun, Jun 01, 2014 at 01:53:06PM -0700, Ram Bhamidipaty wrote: >>> How hard would it be to make OpenOCD build with visual studio? Would that be a >>> worthwhile goal? >> It would be impossible without massive modifications as MSVC doesn't >> support C99. I do not see why anyone might want it. > > Right - I forgot about that. > Thought 2013 was supposed to get better for C99. http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx Cheers Spen |
|
From: Paul F. <fer...@gm...> - 2014-06-12 08:00:38
|
Hi, On Thu, Jun 12, 2014 at 05:47:11PM +1000, Andrew Leech wrote: > Instructions: > https://gitlab.alelec.net/corona/mingw-packages/wikis/openocd_msys2_mingw_w64 That's a nice start indeed! A couple of comments: 1. All semicolons in commands are missing; 2. "autoconf automake mingw-w64-i686-libtool" should probably go to the first pacman -S invocation; I also do not see why you might want mingw-w64-i686-tcl there, is it used by anything? I also recommend to add hidapi unconditionally, as CMSIS-DAP is getting more and more common but newcomers might be confused there, so it better to enable it always IMHO; 3. Instructions for 64bit builds would be handy too, I hope someone will provide them eventually; 4. If you face any difficulties pushing libusb and openocd build scripts upstream, please notify this list just in case, somebody here might be able to help. Thank you for keeping us updated, and happy hacking :) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Andrew L. <cor...@gm...> - 2014-06-13 00:47:46
|
On 12/06/2014 9:45 PM, Andrew Leech wrote: > On 12/06/2014 7:02 pm, Xiaofan Chen wrote: >> 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) > A minor (?) issue with libusb-win32 in this context is that it does not support driver compilation under mingw... which means I can't really make a normal build script for it to go with the libusb and openocd ones. The scripts are pretty flexible however (basically bash scripts), and I could make a script that simply installs the binary distribution of libusb-win32 into the mingw environment such that it's available to openocd. I don't see that as a particularly bad option, seeing as the binary distributions are officially hosted on sf along with the source. Andrew |
|
From: Xiaofan C. <xia...@gm...> - 2014-06-13 11:22:41
|
On Fri, Jun 13, 2014 at 8:47 AM, Andrew Leech <cor...@gm...> wrote: > A minor (?) issue with libusb-win32 in this context is that it does not > support driver compilation under mingw... which means I can't really make a > normal build script for it to go with the libusb and openocd ones. That is true, we do not support anything other than WDK for Windows driver building (that is the norm for Windows driver). But if you look at the Makefile, it should work with building the import library and the test program. http://sourceforge.net/p/libusb-win32/code/HEAD/tree/trunk/libusb/Makefile#l129 > The scripts are pretty flexible however (basically bash scripts), and I > could make a script that simply installs the binary distribution of > libusb-win32 into the mingw environment such that it's available to openocd. > I don't see that as a particularly bad option, seeing as the binary > distributions are officially hosted on sf along with the source. > That is also okay. Take note that you will only need the header file and the import library for building libusb-win32 applications. The driver installer inside libusb-win32 1.2.6.0 package is actually deprecated and we recommend either libusbK driver installer or Zadig. -- Xiaofan |
|
From: Andrew L. <cor...@gm...> - 2014-06-13 04:29:44
|
On 12/06/2014 6:00 PM, Paul Fertser wrote: > On Thu, Jun 12, 2014 at 05:47:11PM +1000, Andrew Leech wrote: >> Instructions: >> https://gitlab.alelec.net/corona/mingw-packages/wikis/openocd_msys2_mingw_w64 > That's a nice start indeed! > > A couple of comments: > > 1. All semicolons in commands are missing; > > 2. "autoconf automake mingw-w64-i686-libtool" should probably go to > the first pacman -S invocation; I also do not see why you might want > mingw-w64-i686-tcl there, is it used by anything? I also recommend to > add hidapi unconditionally, as CMSIS-DAP is getting more and more > common but newcomers might be confused there, so it better to enable > it always IMHO; > > 3. Instructions for 64bit builds would be handy too, I hope someone > will provide them eventually; > > 4. If you face any difficulties pushing libusb and openocd build > scripts upstream, please notify this list just in case, somebody here > might be able to help. > > Thank you for keeping us updated, and happy hacking :) > Hi Paul, 1. Ah, it wasn't ; that was missing, it was newlines. Sure it could be either, but I was expecting them to have newlines. 2. Yeah I've cleaned up and consolodated the pacman installs, I generally do prefer walkthroughs that don't need too many separate package manager install steps at the expense of a little less granularity on the documenting of dependencies. I installed tcl early on in putting toghether these instruction. When trying to configure or compile openocd it was trying to run a tcl tool that was installed elsewhere on my system and failing. Once I installed that package it worked fine. 3. I've just updated my instructions to work with the 64 bit console in msys2, it works just fine for me :-) 4. Yeah for sure. I should be able to get around to creating pull requests, wait and see how that goes. For now my local copies are a good place to get started. Cheers, Andrew |
|
From: Paul F. <fer...@gm...> - 2014-06-13 05:18:06
|
Hi Andrew, On Fri, Jun 13, 2014 at 02:29:32PM +1000, Andrew Leech wrote: > I installed tcl early on in putting toghether these instruction. When > trying to configure or compile openocd it was trying to run a tcl tool > that was installed elsewhere on my system and failing. Once I installed > that package it worked fine. That sounds really strange, OpenOCD doesn't depend on any external Tcl tools. > 4. Yeah for sure. I should be able to get around to creating pull > requests, wait and see how that goes. For now my local copies are a good > place to get started. Great! Please keep us informed. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
|
From: Xiaofan C. <xia...@gm...> - 2014-06-02 08:23:02
|
On Mon, Jun 2, 2014 at 4:53 AM, Ram Bhamidipaty <ra...@ra...> wrote: > How hard would it be to make OpenOCD build with visual studio? Would that be > a worthwhile goal? > > I am willing to do this work - but I don't know if this would be considered > valuable by the project. > If you want to do that, you may want (and need) to work on the dependencies first. For libusb Windows, MSVC is 1st class citizen along with GCC so there are no problems. For libusb-win32, MSVC is 1st class citizen as well so there are no problems either. MinGW is supported only to build the For HIDAPI, I believe it should be okay as well since it supposedly support WDK build (never tried it myself). For libftdi, last time I tried, there are a few issues to get it build under MSVC but should not be that difficult to fix. Not so sure about jimtcl. -- Xiaofan |
|
From: Xiaofan C. <xia...@gm...> - 2014-06-02 08:26:20
|
On Mon, Jun 2, 2014 at 4:22 PM, Xiaofan Chen <xia...@gm...> wrote: > On Mon, Jun 2, 2014 at 4:53 AM, Ram Bhamidipaty <ra...@ra...> wrote: >> How hard would it be to make OpenOCD build with visual studio? Would that be >> a worthwhile goal? >> >> I am willing to do this work - but I don't know if this would be considered >> valuable by the project. >> > > If you want to do that, you may want (and need) to work on the dependencies > first. > > For libusb Windows, MSVC is 1st class citizen along with GCC so > there are no problems. > > For libusb-win32, MSVC is 1st class citizen as well so there are > no problems either. MinGW is supported only to build the Oops, sending too fast. for libusb-win32, MinGW is supported only to build the dynamic import library and the example program. MinGW-w64 will work as well to build the dynamic import library and the example programs. Both will not work for building the driver and the driver installer (using WDK). > For HIDAPI, I believe it should be okay as well since it supposedly > support WDK build (never tried it myself). > > For libftdi, last time I tried, there are a few issues to get it build > under MSVC but should not be that difficult to fix. > > Not so sure about jimtcl. > -- Xiaofan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X