while playing with qtbase on x64-uwp i found that it could not pass a
try_compile command since important variables are not correctly
forwarded. As such I concluded that the handling of try_compile in vcpkg
is completely wrong.
#35084 introduced a regression for native ARM Linux builds where the
toolchain would mistakenly try to reference a cross-compiler (e.g.
`aarch64-linux-gnu-gcc`) despite building natively because vcpkg spells
the architecture differently from what the system reports (`arm64` vs.
`aarch64`).
This fixes the issue by checking whether the
`CMAKE_HOST_SYSTEM_PROCESSOR` matches the target (in CMake's spelling of
the architecture).
---------
Co-authored-by: Kai Pastor <dg0yt@darc.de>
When cross-compiling for x86 Linux, the -m32 flag must also be passed to the linker otherwise it complains about trying to link code built for the wrong architecture.
* UWP toolchain fix and update some ports supports expressions for uwp/xbox
* Update baseline
* More ports updated for !xbox
* Update baseline
* Update support expression for ms-gdkx
* Update baseline
* ms-gdkx port should fail on ado system
* Revert change to opengl-registry since its needed for angle on UWP
* Minor github actions cr
* Refresh baseline
* Try adding xbox triplets
* Update for Gaming Command Prompt usage
* Fix directxtk12 shaders for xbox
* Add toolchain for xbox
* Fix ports for feature builds
* Code review feedback
* More code review
* Code review
* WIN32_LEAN_AND_MEAN is too aggressive for many libs
* Normalize GDK variable paths
* Need to leave oldnames.lib as many libs use POSIX names
* More code review feedback
* Remove extra file
* Use of /DEFAULTLIB fixed 41 ports
* Code review feedback
* Added basic xbox supports expression
* Updates for xbox-aware ports
* Update for CMake fixes upstream
* Minor synatx fix
* Fix up merge issues
* Need directx-headers for linux
* Missed one port revision
* Removed VCPKG_TARGET_IS_XBOX from project scope after upstream fixes
* Update baseline
* License updates per github-actions bot
* Update baseline
* Update toolchain to support try_compile for GDK headers
* Update port numbers
* Update baseline
* Don't need directx-dxc for Xbox builds
* Update baseline
* Update hashes
* Code review
* Update baseline
* Refresh hashes for upstream fixes
* Update baseline
* Add ms-gdkx stub port
* Update baseline
* updated ms-gdkx with user-friendly output
* Update baseline
* Code review for the toolchain file
* Update directxkt12 hash
* Refresh baseline
* Update MSBuild integration to select proper triplet for GDK custom platforms
* Update CMake integration to select proper xbox triplet from XBOX_CONSOLE_TARGET
* vcpkg.targets update
* Code review feedback
* Update baseline
* Refresh baseline
* Code review for MSBuild
* Code review for xbox toolchain
* vcpkg.cmake codereview
---------
Co-authored-by: walbourn <chuckw_walbourn@yahoo.com>
* [vcpkg toolchain] Fix CMAKE_CROSSCOMPILING when building on UWP
* [kfr] Set cpu arch to generic to avoid call try_run
* version
* [kfr] Re-fix cross configure issue
* version
* Revert changes about kfr, add kfr:x64-uwp to ci.baseline instead
* version
* Remove VCPKG_LINKER_FLAGS_RELEASE from debug builds, and apply other changes from windows.cmake for consistency.
Co-authored-by: JackBoosY <yuzaiyang@beyondsoft.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
This follows the pattern in the Windows toolchain with respect to
setting VCPKG_CMAKE_SYSTEM_VERSION and also how arm64 macOS can execute
x86_64 through Rosetta.
* [osx] set CMAKE_SYSTEM_PROCESSOR from VCPKG_TARGET_ARCHITECTURE on osx
* [linux] Set CMAKE_ASM_COMPILER and CMAKE_ASM-ATT_COMPILER in case of crosscompile
* [wavpack] migrate to vcpkg_cmake_install
* [wavpack] enable arm builds
* [wavpack] Add license field to vcpkg.json
* [OSX] don't default to 86_64
* [toolchain windows] set CMAKE_SYSTEM_NAME and CMAKE_SYSTEM_PROCESSOR
In specific, I did this for the cpuinfo PR - I realized the reason
that cpuinfo doesn't support arm64 windows cross compilation is because
we don't set CMAKE_SYSTEM_PROCESSOR.
* correctly set CMAKE_CROSSCOMPILING
* start fixin libraries
* more changes:
- gainput: remove line
- glog: remove try_run when cross compiling
- windows.cmake: set CMAKE_SYSTEM_VERSION
* more patches
- mapnik: set BOOST_REGEX_HAS_ICU to avoid check_cxx_source_runs
- orc: set HAS_PRE_1970 and HAS_POST_2038 for same
- seal: change out check_cxx_source_runs for check_cxx_source_compiles
* more changes
* fix x86-windows
* fix qpid-proton, glog
* build corrade-rc
* fix x64-uwp ports
* forgot to _actually_ always build corrade-rc .,.
* Replay #22831
* Dedupe CMAKE_SYSTEM_NAME settings.
* Add quotes for corrade_rc_param
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
* Update version DB.
Co-authored-by: nicole mazzuca <mazzucan@outlook.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
Co-authored-by: Jack·Boos·Yu <47264268+JackBoosY@users.noreply.github.com>
This change allows for adding a prefix to android overlay ports, which many other systems support already. The android system relies on regex matching of the triplet name to deduce the ABI, so this change just allows for that string to be anywhere in the overlay triplet string.
* Fixed android toolchain with newest NDK
ANDROID_NATIVE_API_LEVEL has been removed from NDK cmake toolchain so we now have to use ANDROID_PLATFORM
* Fix android toolchain: Maintain backward compatibility for older NDK
* compile for android including armv6.
* Update arm-android.cmake
* Update from comment in the PR
support ANDROID_NATIVE_API_LEVEL from env variable. (to be able to compile also 16 and not just 21 as default)
* Add ANDROID_ARM_NEON from env var
* Short version of update ANDROID_ARM_NEON.
* remove ANDROID_NATIVE_API_LEVEL now using vcpkg_CMAKE_SYSTEM_VERSION in triplet
Add cache to ANDROID_ARM_NEON
fix indents
* Update neon triplet
* Add arm-neon-android.cmake file.
This change tries to fix issue #13395.
Root cause:
In script mode, cmake won't populate CMAKE_SYSTEM_PROCESSOR parameter automatically. That parameter is
required by libpng to configure build parameters. To fix this issue, we need explicitly set CMAKE_SYSTEM_PROCESSOR
value.
Verify:
On arm64-linux host, run `./vcpkg install tesseract:arm64-linux`.
Co-authored-by: Nicole Mazzuca <mazzucan@outlook.com>
Co-authored-by: JackBoosY <yuzaiyang@beyondsoft.com>
Co-authored-by: Billy Robert O'Neal III <bion@microsoft.com>
* Fix for Android compilation
See https://github.com/microsoft/vcpkg/issues/5809
* Allow for custom android triplets. Fallback to Xamarin installed NDK.
* Increased Port-Version for boost-modular-build-helper
* More restrictive matching pattern for android toolchain
* [vcpkg ios] Fix detection of iOS toolchain (#6003)
Added mapping of CMAKE_SYSTEM_NAME == iOS to the bundled iOS toolchain
file.
This fixes the "Unable to determine toolchain to use for
triplet arm64-ios with CMAKE_SYSTEM_NAME iOS" error.
* [vcpkg ios] Set the CMake system processor for the simulator arches (#6003)
So it's consistent for all architectures.
* Add iOS community triplets and toolchain support
Added an iOS toolchain to enable building packages for iOS.
The toolchain is used when a triplet's VCPKG_CMAKE_SYSTEM_NAME is set
to iOS.
To configure which architecture should be built, as well as other
iOS specifics, the following triplet variables can be set:
- VCPKG_TARGET_ARCHITECTURE
- VCPKG_OSX_SYSROOT
- VCPKG_OSX_DEPLOYMENT_TARGET
- VCPKG_OSX_ARCHITECTURES
The following VCPKG_TARGET_ARCHITECTURE values are currently
supported:
- arm, arm64, x64, x86.
The following VCPKG_OSX_SYSROOT values are currently supported:
- iphoneos, iphonesimulator, or an absolute path to the device or
simulator Xcode SDK.
VCPKG_OSX_DEPLOYMENT_TARGET can be set to control the minimum iOS
delopyment target for the built libraries.
CMAKE_OSX_ARCHITECTURES is derived from VCPKG_TARGET_ARCHITECTURE,
so generally it should not be set. In case if someone needs to target
a more specific architecture (like armv7k or arm64e), it can
be set in the triplet via VCPKG_OSX_ARCHITECTURES.
Note that only certain combinations of the architecture and sysroot
will work: simulator SDKs only provide x86-based libraries, etc.
The toolchain also sets CMAKE_SYSTEM_PROCESSOR for certain
configurations, because certain packages (like libpng) depend on the
processor type.
Added 4 community iOS triplets that build static libraries:
- arm-ios, arm64-ios, x86-ios, x64-ios.
The non-arm triplets target the iOS simulator.
The triplets build static libraries because they are easiest to
integrate into an iOS project. Dynamic libraries or frameworks require
code signing on iOS, which complicates integration.
Added heuristics to try and automatically detect what iOS triplet to
use when building your own CMake project (so when a CMake project sets
CMAKE_TOOLCHAIN_FILE to buildsystems/vcpkg.cmake), if no explicit
triplet is provided (VCPKG_TARGET_TRIPLET is undefined).
The heuristic checks for the values of CMAKE_SYSTEM_NAME and
CMAKE_OSX_ARCHITECTURES. Note that for this to work,
CMAKE_OSX_ARCHITECTURES needs to be set before the first project()
call in your CMake project.
Added workaround so find_package finds vcpkg installed packages
when targeting iOS.
This is done by saving / restoring the value of CMAKE_FIND_ROOT_PATH
while also adding the vcpkg package root in the find_package override
macro.
The workaround can be removed once vcpkg upgrades to CMake 3.15.0
or higher where the issue is fixed.
Fixes: #6003
* Fix building libpng and pcre2 targetting iOS
Fixes: #6003
* Add support for building with MinGW
Tested with MSYS2 MinGW 8.3.0, gcc-mcf.lhmouse MinGW 9.2.1,
and StephanTLavavej/mingw-distro!
* Add MinGW toolchain
From your MinGW configured shell you could just use vcpkg to
configure packages.
An x64-mingw triplet would look like:
```
set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_ENV_PASSTHROUGH PATH)
set(VCPKG_CMAKE_SYSTEM_NAME MinGW)
```
* Add MinGW community tripplets
x64 tested with https://github.com/StephanTLavavej/mingw-distro
x86, arm64, arm tested with https://github.com/mstorsjo/llvm-mingw
