curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: Windows Aarch64 build

From: Michał Janiszewski via curl-library <>
Date: Sat, 19 Oct 2019 21:18:15 +0200

I think I have addressed most of your suggestions.

I moved the files to their own repo: where I have added some
basic readme and the license file copied from upstream. The files are
properly tagged (using the same format as upstream), so you can get
GitHub's automated archive via

I have also submitted a set of pull requests so that the builds are
done by your appveyor setup instead:
   appveyor: publish artifacts on appveyor
   appveyor: Add MSVC ARM64 build

Other than the PR building a static version (which I simply forgot to
do) it is pretty much exactly how I came up with the builds in the
first place, albeit on a local machine.

I'm *not* particularly interested in maintaining those builds by
myself in the long run, but I sometimes do check up how well projects
support MSVC+ARM (cf., I was
simply in need of Aarch64 curl binary. I will likely occasionally
update this new repository with new builds, provided the PRs I've sent
get merged. If that's a blocker for linking to my builds, I'm fine
with that.

Best regards,

On Fri, 18 Oct 2019 at 13:09, Daniel Stenberg <> wrote:
> On Fri, 18 Oct 2019, Michał Janiszewski via curl-library wrote:
> > I've prepared Windows Aarch64 build that you can find here:
> >
> > It is 7.66 release, built with WinSSL, using MSVC2019 and the CMake project.
> > Is there any interest in linking to it from
> > Should I do anything else
> > regarding how the package is compiled or distributed?
> Thanks for your consideration!
> I think you could do a few things to improve what you're offering:
> 1 - package the binary in a zip or similar and bundle some basic information
> about it - like what SSL (version) it is built to use, other
> dependencies, perhaps some basic docs and the license etc.
> 2 - make sure that the version number is clearly visible on the web page and
> in the download file itself. Our download page works best when our
> automated bot can poll the download pages itself and figure out what
> version you're offering - as I assume you want to keep the download
> package up to date going forward.
> 3 - that page is a github gist, which has a rather user hostile URL. Are you
> going to keep that as the fixed URL for your curl packages also going
> forward?
> 4 - make sure you can produce your packages with a script so that it gets
> easier to do subsequent packages. We release a new curl every eight weeks
> after all!
> --
> / | Get the best commercial curl support there is - from me
> | Private help, bug fixes, support, ports, new features
> |

Michal Janiszewski
Received on 2019-10-19