Stop the sulk with GPL2016 on Windows #602
Conversation
|
That's great news, I would prefer generating the MSVC 2017 project using CMake. I'm not a big fan of having for every IDE and compiler version different projects. Have you tried this ? I will review your code changes ASAP. |
|
On Fri, Jun 9, 2017 at 12:47 AM, Jerry Jacobs ***@***.***> wrote:
That's great news, I would prefer generating the MSVC 2017 project using
CMake. I'm not a big fan of having for every IDE and compiler version
different projects. Have you tried this ? I will review your code changes
ASAP.
Generating the VS2017 project files sort of works - I generated them with
"cmake .." in the build directory. They get regenerated all the time and
VS2017 seems happy with them, so the ones I committed in my fork are best
ignored. The main problem at the moment is that the libusb that gets
downloaded is built for a previous version of MSVC so you get undefined
symbols until you build libusb with VS2017 and copy the relevant files into
the build tree.
It's a work in progress to say the least. I do not expect it to be taken
in its entirety - especially the random getopt and unistd.h I had to add.
|
|
Yeah I know how it works, it costs some effort to get it working. But happily you have it sort of compiling and working. |
|
No problem we just squash them when finished. |
|
At this point, the MSVC projects generated by cmake work fine with VS2017 as long as the libusb archive has libs built with VS2017. I suspect everything would be fine on a previous version of VS as well, but haven't tried it. I downloaded the latest libusb source, built the VS2015 solution using VS2017 (works fine) and copied libusb-1.0.lib from the libusb-1.0.21\Win32\Debug\lib directory into libusb-1.0.21.7z\MS32\static using 7-Zip. Then, I cleaned out the stlink/build directory, copied the modified libusb-1.0.21.7z in to the build directory, ran cmake and build the resulting solution (Debug target). This sequence produced an st-util.exe that I put in my GNAT/2016/bin directory. Debugging under GNAT/GPS is working fine, so I'll leave this branch alone now. |
|
Actually, it's LGPL like libusb, so I thought it should be OK.
However, I agree it would be better to use a BSD licensed getopt, so I'll
make the change.
…On Sat, Jun 10, 2017 at 1:24 AM, Jerry Jacobs ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/getopt/getopt.h
<#602 (comment)>:
> +
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, write to the Free
+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307 USA. */
+
We better could use a BSD licensed getopt from e.g
https://github.com/kimgr/getopt_port
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#602 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALSmRF2Ple0g5iJDSLFC_CEKJ1NOodV7ks5sClK7gaJpZM4N08VH>
.
|
|
I copied the suggested BSD licensed files in for getopt. I also made the links to libusb dynamic for MSVC (it's no longer necessary to modify the libusb archive with this change). |
|
Great, looks good to me. A few things left:
|
|
@texane can we finally enable AppVeyor Github integration for this project repository? Just like Travis continuous integration. This makes release/artifacts for windows with MSVC/MinGW compiled much easier to maintain for me because I only own Mac and *Nix machines. I would also appreciate if you can give me full permissions on the repository so I will not bother you with trying to get it work. |
|
On Sat, Jun 10, 2017 at 1:12 PM, Jerry Jacobs ***@***.***> wrote:
Great, looks good to me. A few things left:
- Could you write a section about MSVC 2017 usage/compilation in
document https://github.com/texane/stlink/blob/master/doc/compiling.md
Will do.
- (optional, can be a hassle) Could you try to let it compile with
AppVeyor continuous integration with the MSVC 2017 image (I only own Mac
and *Nix machines), this should also be able to create builds for releases
which are reproducable.
I'll look into it - never done it before.
I actually tested it in a 64bit Windows 10 Virtual Box virtual machine
under Centos Linux! (I also tested on a 32bit Windows 7 system, so I got
reasonable coverage. I didn't, but suppose I could build it for XP if the
free VS2017 supports that; I know the full version I have at work does.
There isn't be anything that requires later than XP that I've noticed.)
- There is no way to have the executables static for windows now as
you have it pointing to the DLL folder, maybe we should find a way to have
it static compiled (which makes distribution easier).
Unfortunately, after you mentioned the GPL problems with the getopt from
libusb, I checked libusb and it's LGPL with no exclusion that I could see
for static linking. I could be wrong about that, but I switched it to
dynamic linking just in case. It actually makes the VS C runtime issues go
away, at the cost of having to distribute the libusb dll.
|
|
Thanks for looking into it! Keep me posted. |
|
The existing AppVeyor script fails: "mv: cannot move I did have success from the AppVeyor web UI. This exported appveyor.yml successfully builds the project under VS2017. There are a lot of warnings that should be reviewed, mostly signed/unsigned conversions. Log is attached. EDIT: The formatting messed it up, so I attached it as a file - rename to .yml to use it. |
|
Nice work @orinem ! Its possible the mingw32 stuff is broken. Looks good, last note: why are there two unistd.h compat files? Probably we should just keep one under src or in include. When you are finished we can merge! |
|
Two unistd.h files was an accident. I've deleted the extra. |
|
The file had "ä" and "Ä" characters in a character set encoding incompatible with UTF8. I resaved the file from vi as utf8 and the latest diff looks OK. |
|
Sorry for my late reply. All set! |
|
Cool.
Hopefully it proves useful.
…On Fri, Jun 16, 2017 at 11:05 PM, Jerry Jacobs ***@***.***> wrote:
Merged #602 <#602>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#602 (comment)>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/ALSmRM5YMNSc-Sxq6vVmujd4FPkmB3Owks5sE2y_gaJpZM4N08VH>
.
|
|
Sure, since I build and released a windows executable there are many downloads. |
Trying to use stlink with GNAT/GPL2016/GPS was an exercise in frustration on Windows (no, another OS is NOT an option). GPS would sulk trying to flash/debug. However, running st-util then flash/debug would work, but one copy of st-util would crash.
These changes result in an st-util.exe that builds in Visual Studio 2017 (don't complain, it's free for open source development) and does not exhibit the above problems. However, it is far from complete. It requires that libusb be built from source in Visual Studio 2017 and the resulting binaries copying into the build folder. It's beyond my current inclination to make cmake do that. It's likely that a previous version of Visual Studio will work fine with the libusb that is downloaded. I have no time to check that either.
The critical commit is probably f881677. The code was using the wrong function to close a socket and furthermore, subsequent code that used the correct function closed the incorrect socket.
Feel free to cherry pick from these commits (especially ignoring the VS2017 project files that are particularly messy - cmake should be able to make them now).