On Fri, 27 Oct 2017, Daniel Stenberg wrote:

> We're missing 32bit windows builds in appveyor for our CI, which leads to us
> sometimes landing changes that cause warnings/problems on such platforms.
>
> My idea is to add at least one 32 bit build to appveyor to increase our
> chances of catching such mistakes before we merge them into master.
>
> I haven't figured out how to force a 32bit x86 build, so if anyone has any
> clues or suggestions for that, do let me know.
>
> I did however manage to add a build for 32 bit ARM, which however fails to
> link: see https://github.com/curl/curl/pull/2020 - due to some weird problems
> with crypto functions? Again, I would love to get some help with this so that
> we can add this build to the CI.

The first detail to know, is that building for Windows for ARM (32 bit) is
a bit special; this is only supported when targeting the UWP/Windows
Store/Windows Phone/WinRT API subset.

Short, possibly marginally inaccurate version: When targeting this API
family/subset, you only have access to a limited part of the full win32
api, which is the only API that you're allowed to use when doing a
"Windows Store" app (or Windows Phone app, but that's going away).
Normally this is enforced by setting various
WINAPI_FAMILY=WINAPI_FAMILY_APP defines during the build, which hides all
forbidden APIs from the headers.

The msvcrt headers additionally (more or less) force you to set such a
WINAPI_FAMILY define if building for arm. If you don't, the msvcrt headers
will tell you that building for ARM for the desktop API subset isn't
supported. (There is some other define one can set to get around that but
that's also not too relevant.)

This is different from the upcoming ARM64 support though, where you're
allowed to target the full desktop ecosystem.

Now coming back to your issue, the build seems to fail because it can't
find __imp_CryptAcquireContextA (among others) when linking. This function
is defined in advapi32.lib/dll. The culprit probably is here:
https://github.com/Kitware/CMake/blob/971b8c3c80372adf6cef54313927bc462f51d7da/Modules/Platform/Windows-MSVC.cmake#L181
(or one of the lines above it)

When targeting other subsets or configurations, cmake seems to default to
linking in a whole bunch of libraries, advapi32.lib, shell32.lib and even
curiosities like winspool.lib or odbc32.lib. (In practice the binary
doesn't end up linked against them if no function from them is used
though.)

If one looks in the lib directory of a matching MSVC install, one does
find an advapi32.lib for ARM, and it does contain the necessary functions.

But when reading the reference for e.g. CryptAcquireContext at
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379886(v=vs.85).aspx,
you'll see that it says "Minimum supported client: Windows XP [desktop
apps only]", which means that this function isn't available/allowed in
store apps.

TL;DR: For testing building, you can try adding advapi32.lib manually to
the list of libraries linked. But it won't be a kosher binary that would
pass verifications for windows store (which isn't what you're interested
in at the moment, but which is enforced when targeting ARM).

Figuring out how to build for 32 bit x86 probably would be much less of a
detour into things you don't want to waste your energy on :-)

... and after typing all this, I realize that you already have support for
targeting curl towards windows store apps (which probably isn't
surprising), so setting CURL_WINDOWS_APP while building might be an even
better fix for your issue.

// Martin
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-10-27