Сборка библиотеки DLL на ARM для использования в UWP / Windows 10. Не работает на мобильных устройствах. По-прежнему имеет зависимости от kernel32.lib

Я пытаюсь создать приложение UWP. Мне нужно включить в приложение ряд существующих (неуправляемых кодов) библиотек C ++. Насколько я понимаю, лучший способ сделать это — обернуть все это в компонент времени выполнения Windows.

После некоторых трудностей мне удалось получить приложение для сборки, связанное со всем существующим кодом C ++ через компонент времени выполнения Windows. Некоторые из этих библиотек зависят от предварительно скомпилированных Win32 .dll. Поэтому я также перекомпилировал их из исходного кода в Visual Studio 2015 для архитектуры ARM.

При развертывании на платформе Windows Mobile я получаю следующее исключение:

'System.IO.FileNotFoundException' in System.Private.Interop.dll; Unhandled exception at 0x77A3DF95 (combase.dll)

Это не очень помогает. Но на основании этого ТАКОГО вопроса: System.IO.FileNotFoundException: не удалось загрузить файл или сборку «X» или одну из ее зависимостей при развертывании приложения, Моя гипотеза состоит в том, что, несмотря на создание dll для ARM, один из них все еще имеет зависимость где-то от dll Win32, который, как и ожидалось, не может быть найден (следовательно, FileNotFoundException).

Когда я загружаю каждый из dll, созданных для ARM в Зависимость Уокер, Я не вижу никаких зависимостей от Win32, с исключением icuuc56.dll одного из dll, который я создал для ARM из источника, который, как я вижу, имеет ядро32 (advapi32) в качестве зависимости. Насколько я понимаю, Windows Mobile не будет предоставлять эти зависимости ОС (следовательно, FileNotFoundException?). И что динамическая загрузка этой конкретной зависимости Win32 вызывает сбой приложения.

Я хочу построить версию ARM icuuc56.dll без это ссылка на библиотеки Win32. По крайней мере, так я могу определить, какие части ICU4C полагаются на вызовы функций Win32. Но, как ни странно, при сборке для ARM я не могу запретить компоновщику связываться с% (AdditionalDependencies), который включает в себя библиотеки Win32.

Правильно ли я истолковал проблему? Если так, мои вопросы:

1. Почему ICU4C при нацеливании на ARM строится в первую очередь, если это зависит от Win32 dll?

2. Как я могу предотвратить соединение с Kernel32 во время сборки, чтобы я мог определить, какие части ICU4C выполняют вызовы функций, которые не могут быть выполнены в ARM.

3. Есть ли предоставляемый ОС эквивалент ICU4C, который можно использовать вместо этого в UWP?

ОБНОВИТЬ:
Как #ifdef WIN32 решает до истины, platform.h из набора ICU4C это следующее

#define     U_PLATFORM_USES_ONLY_WIN32_API   1
#define     U_PLATFORM_HAS_WIN32_API   1

Если я попытаюсь поиграться с определениями препроцессора платформы, лучшее, что я смогу получить, — это использовать, например, tzset вместо _tzset. Который также не будет доступен (я полагаю).

Есть ли какой-нибудь способ, которым ICU4C может быть построен для UWP, не переписывая его полностью? В конце концов, его можно скомпилировать для iOS и Android. Я посмотрю глубже https://sourceforge.net/p/icu/mailman/icu-support/thread/[email protected]/ но это выглядит немного другой проблемой.