microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
22k stars 6.12k forks source link

[android] vcpkg_configure_make correct set flags for android build #15605

Closed xandox closed 2 years ago

xandox commented 3 years ago

vcpkg_configure_make properly set CFLAGS, CXXFLAGS, LDFLAG, CC and CXX env variables now for android cross compilation.

JackBoosY commented 3 years ago

Regression when building mlpack:x86-windows:

armadillo.lib(wrapper2.cpp.obj) : error LNK2019: unresolved external symbol _sgetrf_ referenced in function _wrapper2_sgetrf_
armadillo.lib(wrapper2.cpp.obj) : error LNK2019: unresolved external symbol _dgetrf_ referenced in function _wrapper2_dgetrf_
armadillo.lib(wrapper2.cpp.obj) : error LNK2019: unresolved external symbol _cgetrf_ referenced in function _wrapper2_cgetrf_
armadillo.lib(wrapper2.cpp.obj) : error LNK2019: unresolved external symbol _zgetrf_ referenced in function _wrapper2_zgetrf_
JackBoosY commented 3 years ago

Regression is gone.

JackBoosY commented 3 years ago

@Neumann-A Can you please review again?

Thanks.

JackBoosY commented 3 years ago

Fixes #15255.

JackBoosY commented 3 years ago

Seems have many regressions when building x64-osx, please get failure logs here.

venabled commented 3 years ago

@xandox Thanks for the contribution. I've been playing around with this PR to try and build 'libiconv' the past two days, and I've found a few things that have prevented that port from building.

I think most of it was that --gcc-toolchain' and '--sysroot' are getting pulled into theVCPKG_DETECTED_CMAKE_CFLAGS` variables.

And according to @DanAlbert post in the NDK repo and the NDK integration with other build systems documentation those really shouldn't be in there.

I guess this isn't really a problem with vcpkg_configure_make as it's an issue in Meson ports too. These aren't set as C/CPP flags in the Android toolchain CMake file, so Ill have to keep digging.

xandox commented 3 years ago

@venabled hi. I am not sure what you mean. I am able to build libiconv with 21d and 22 ndk. What is you problem?

According to the article you provided - yes, looks like --sysroot and --gcc-toolchain not necessary here, but they are not a problem. They came from android.toolchain.cmake and have correct paths.

venabled commented 3 years ago

I guess I should have been more specific, I had to modify 'libiconv' port as the current port only builds from source if you're on Windows.

xandox commented 3 years ago

Yes, sure. See #15606.

DanAlbert commented 3 years ago

@venabled hi. I am not sure what you mean. I am able to build libiconv with 21d and 22 ndk. What is you problem?

According to the article you provided - yes, looks like --sysroot and --gcc-toolchain not necessary here, but they are not a problem. They came from android.toolchain.cmake and have correct paths.

Possibly superfluous context here, but in case it's helpful:

While they're not necessary to build correctly, as long as they are set to the appropriate values they shouldn't harm anything. The toolchain file still configures them because (iirc), CMake's find_* behaviors depend on CMAKE_SYSROOT. There were also old versions of our gradle plugin that depended on that value being present.

-gcc-toolchain I think has done nothing useful since r19 :)

The problem in the NDK bug linked was that folks had set --sysroot's value to the wrong path, and that can definitely break things.

venabled commented 3 years ago

Thanks for the discussion @xandox and @DanAlbert. For whatever reason I couldn't get the mods from this PR to build libiconv for arm-android.

Modified portfile.cmake:

# if(NOT VCPKG_TARGET_IS_WINDOWS)
#     # set(VCPKG_POLICY_EMPTY_PACKAGE enabled)
#     file(MAKE_DIRECTORY ${CURRENT_PACKAGES_DIR}/share/Iconv)
#     file(COPY ${CMAKE_CURRENT_LIST_DIR}/vcpkg-cmake-wrapper.cmake DESTINATION ${CURRENT_PACKAGES_DIR}/share/iconv)
#     return()
# endif()

set(LIBICONV_VERSION 1.16)

vcpkg_download_distfile(ARCHIVE
    URLS "https://ftp.gnu.org/gnu/libiconv/libiconv-${LIBICONV_VERSION}.tar.gz" "https://www.mirrorservice.org/sites/ftp.gnu.org/gnu/libiconv/libiconv-${LIBICONV_VERSION}.tar.gz"
    FILENAME "libiconv-${LIBICONV_VERSION}.tar.gz"
    SHA512 365dac0b34b4255a0066e8033a8b3db4bdb94b9b57a9dca17ebf2d779139fe935caf51a465d17fd8ae229ec4b926f3f7025264f37243432075e5583925bb77b7
)

vcpkg_extract_source_archive_ex(
    OUT_SOURCE_PATH SOURCE_PATH
    ARCHIVE ${ARCHIVE}
)

vcpkg_configure_make(SOURCE_PATH ${SOURCE_PATH}
                     DETERMINE_BUILD_TRIPLET
                     USE_WRAPPERS
                    ${OPTIONS}
                    )

vcpkg_build_make()

vcpkg_install_make()

vcpkg_copy_pdbs()
vcpkg_copy_tool_dependencies(${CURRENT_PACKAGES_DIR}/tools/${PORT}/bin)
vcpkg_copy_tool_dependencies(${CURRENT_PACKAGES_DIR}/tools/${PORT}/debug/bin)

file(COPY ${CMAKE_CURRENT_LIST_DIR}/vcpkg-cmake-wrapper.cmake DESTINATION ${CURRENT_PACKAGES_DIR}/share/iconv)

file(INSTALL ${SOURCE_PATH}/COPYING.LIB DESTINATION ${CURRENT_PACKAGES_DIR}/share/${PORT} RENAME copyright)

file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")
set(VCPKG_POLICY_ALLOW_RESTRICTED_HEADERS enabled)

Using this script I get linking errors for crti.o, crtbeginS.o, crtendS.o, crtn.o and some other libs:

/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot open crti.o: No such file or directory
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot open crtbeginS.o: No such file or directory
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot open crtendS.o: No such file or directory
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot open crtn.o: No such file or directory
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot find -lcompiler_rt-extras
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot find -lgcc_s
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot find -lc
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot find -lcompiler_rt-extras
/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x/../../../../x86_64-linux-android/bin/ld: error: cannot find -lgcc_s

Configure command:

  $ ./../src/libiconv-1-b9f06978f2.clean/configure --host=arm-linux-android --build=x86_64-linux-gnu --enable-relocatable --enable-extra-encodings --without-libiconv-prefix --without-libintl-prefix --disable-silent-rules --verbose --enable-shared --disable-static --prefix=/data/vcpkg/installed/arm-android --bindir=${prefix}/tools/libiconv/bin --sbindir=${prefix}/tools/libiconv/sbin --mandir=${prefix}/share/libiconv --docdir=${prefix}/share/libiconv --datarootdir=${prefix}/share/libiconv

And then CMake detected vars:

set(VCPKG_DETECTED_CMAKE_CROSSCOMPILING "TRUE")
set(VCPKG_DETECTED_CMAKE_SYSTEM_NAME "Android")
set(VCPKG_DETECTED_CMAKE_HOST_SYSTEM_NAME "Linux")
set(VCPKG_DETECTED_CMAKE_SYSTEM_PROCESSOR "armv7-a")
set(VCPKG_DETECTED_CMAKE_HOST_SYSTEM_PROCESSOR "x86_64")
set(VCPKG_DETECTED_CMAKE_AR "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ar")
set(VCPKG_DETECTED_CMAKE_RANLIB "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ranlib")
set(VCPKG_DETECTED_CMAKE_STRIP "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-strip")
set(VCPKG_DETECTED_CMAKE_NM "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-nm")
set(VCPKG_DETECTED_CMAKE_OBJDUMP "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-objdump")
set(VCPKG_DETECTED_CMAKE_DLLTOOL "CMAKE_DLLTOOL-NOTFOUND")
set(VCPKG_DETECTED_CMAKE_MT "")
set(VCPKG_DETECTED_CMAKE_LINKER "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/arm-linux-androideabi-ld")
set(VCPKG_DETECTED_CMAKE_AS "")
set(VCPKG_DETECTED_CMAKE_C_COMPILER "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang")
set(VCPKG_DETECTED_CMAKE_CXX_COMPILER "/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/bin/clang++")
set(VCPKG_DETECTED_CMAKE_RC_COMPILER "")
set(VCPKG_DETECTED_CMAKE_C_STANDARD_INCLUDE_DIRECTORIES "")
set(VCPKG_DETECTED_CMAKE_C_STANDARD_LIBRARIES "-latomic -lm")
set(VCPKG_DETECTED_CMAKE_C_STANDARD "")
set(VCPKG_DETECTED_CMAKE_C_COMPILE_FEATURES "c_std_90;c_function_prototypes;c_std_99;c_restrict;c_variadic_macros;c_std_11;c_static_assert")
set(VCPKG_DETECTED_CMAKE_C_EXTENSION "")
set(VCPKG_DETECTED_CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES "")
set(VCPKG_DETECTED_CMAKE_CXX_STANDARD_LIBRARIES "-latomic -lm")
set(VCPKG_DETECTED_CMAKE_CXX_STANDARD "")
set(VCPKG_DETECTED_CMAKE_CXX_COMPILE_FEATURES "cxx_std_98;cxx_template_template_parameters;cxx_std_11;cxx_alias_templates;cxx_alignas;cxx_alignof;cxx_attributes;cxx_auto_type;cxx_constexpr;cxx_decltype;cxx_decltype_incomplete_return_types;cxx_default_function_template_args;cxx_defaulted_functions;cxx_defaulted_move_initializers;cxx_delegating_constructors;cxx_deleted_functions;cxx_enum_forward_declarations;cxx_explicit_conversions;cxx_extended_friend_declarations;cxx_extern_templates;cxx_final;cxx_func_identifier;cxx_generalized_initializers;cxx_inheriting_constructors;cxx_inline_namespaces;cxx_lambdas;cxx_local_type_template_args;cxx_long_long_type;cxx_noexcept;cxx_nonstatic_member_init;cxx_nullptr;cxx_override;cxx_range_for;cxx_raw_string_literals;cxx_reference_qualified_functions;cxx_right_angle_brackets;cxx_rvalue_references;cxx_sizeof_member;cxx_static_assert;cxx_strong_enums;cxx_thread_local;cxx_trailing_return_types;cxx_unicode_literals;cxx_uniform_initialization;cxx_unrestricted_unions;cxx_user_literals;cxx_variadic_macros;cxx_variadic_templates;cxx_std_14;cxx_aggregate_default_initializers;cxx_attribute_deprecated;cxx_binary_literals;cxx_contextual_conversions;cxx_decltype_auto;cxx_digit_separators;cxx_generic_lambdas;cxx_lambda_init_captures;cxx_relaxed_constexpr;cxx_return_type_deduction;cxx_variable_templates;cxx_std_17;cxx_std_20")
set(VCPKG_DETECTED_CMAKE_CXX_EXTENSION "")
set(VCPKG_DETECTED_ENV_PATH "/home/venabled/install/bin:/home/venabled/.local/bin:/home/venabled/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/data/vcpkg/downloads/tools/ninja-1.10.1-linux")
set(VCPKG_DETECTED_ENV_INCLUDE "")
set(VCPKG_DETECTED_ENV_C_INCLUDE_PATH "")
set(VCPKG_DETECTED_ENV_CPLUS_INCLUDE_PATH "")
set(VCPKG_DETECTED_ENV_LIB "")
set(VCPKG_DETECTED_ENV_LIBPATH "")
set(VCPKG_DETECTED_ENV_LIBRARY_PATH "")
set(VCPKG_DETECTED_ENV_LD_LIBRARY_PATH "/home/venabled/navlib/lib:/home/venabled/install/lib:")
set(VCPKG_DETECTED_RAW_CMAKE_C_FLAGS " -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security  -fPIC   --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_C_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_C_FLAGS_DEBUG "-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security  -fPIC   --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot -O0 -fno-limit-debug-info")
set(VCPKG_DETECTED_RAW_CMAKE_CXX_FLAGS " -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_CXX_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_CXX_FLAGS_DEBUG "-g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -frtti -fexceptions  -fPIC   --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot -O0 -fno-limit-debug-info")
set(VCPKG_DETECTED_RAW_CMAKE_RC_FLAGS " ")
set(VCPKG_DETECTED_RAW_CMAKE_RC_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_RC_FLAGS_DEBUG "")
set(VCPKG_DETECTED_RAW_CMAKE_SHARED_LINKER_FLAGS " -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libgcc_real.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--fatal-warnings -Wl,--exclude-libs,libunwind.a -Wl,--no-undefined -Qunused-arguments    --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_SHARED_LINKER_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_SHARED_LINKER_FLAGS_DEBUG "-Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libgcc_real.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--fatal-warnings -Wl,--exclude-libs,libunwind.a -Wl,--no-undefined -Qunused-arguments    --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_STATIC_LINKER_FLAGS " --target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_STATIC_LINKER_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_STATIC_LINKER_FLAGS_DEBUG "--target=armv7-none-linux-androideabi21 --gcc-toolchain=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64 --sysroot=/home/venabled/android-ndk-r21d/toolchains/llvm/prebuilt/linux-x86_64/sysroot")
set(VCPKG_DETECTED_RAW_CMAKE_EXE_LINKER_FLAGS " -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libgcc_real.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--fatal-warnings -Wl,--exclude-libs,libunwind.a -Wl,--no-undefined -Qunused-arguments -Wl,--gc-sections")
set(VCPKG_DETECTED_RAW_CMAKE_EXE_LINKER_FLAGS_DEBUG "")
set(VCPKG_DETECTED_CMAKE_EXE_LINKER_FLAGS_DEBUG "-Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libgcc_real.a -Wl,--exclude-libs,libatomic.a -Wl,--build-id -Wl,--fatal-warnings -Wl,--exclude-libs,libunwind.a -Wl,--no-undefined -Qunused-arguments -Wl,--gc-sections")

I'm a bit out of my league here. I worked around it and got it to build by writing a configure script in the vein of ndkports or the custom CMake ExternalProject build that I was rocking before, which:

And that seems to build.

Neumann-A commented 3 years ago

CPPFLAGS

CXXFLAGS is the right variable. CPPFLAGS is the preprocessor flags.

so doing set(ENV{CPPFLAGS} "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG}") is wrong.

venabled commented 3 years ago

CPPFLAGS

CXXFLAGS is the right variable. CPPFLAGS is the preprocessor flags.

so doing set(ENV{CPPFLAGS} "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG}") is wrong.

Nice catch, thanks. Ill fix that going forward. Granted in NDKPorts / my custom scripts I don't even set C*Flags unless the configure script is relatively botched.

jwtowner commented 3 years ago

Hey thanks for your effort. I can confirm that vcpkg_configure_meson also suffers from the same problem when cross-compiling for Android NDK. Unable to build harfbuzz which uses it. Dropping in the changes to scripts/get_cmake_vars/CMakeLists.txt appears to be a big step in the right direction.

However, an immediate problem occurs when the Android NDK is installed under a directory containing a space character, which is often the case with Xamarin included with MSVS.

..\src\f4d3aa1127-a820a32874.clean\meson.build:1:0: ERROR: Unable to detect linker for compiler "C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe -Wl,--version -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -fPIC -fasynchronous-unwind-tables -ffunction-sections -fdata-sections -fstack-protector-strong -fstrict-aliasing -fthreadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_REENTERANT --target=armv7-none-linux-androideabi19 --gcc-toolchain=C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64 --sysroot=C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/sysroot -Oz -DNDEBUG -Os -g2 -gdwarf-2 -fomit-frame-pointer -DNDEBUG -flto=thin -I"D:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/arm-android-sgi-shipping/include""
stdout:
stderr: clang: error: no such file or directory: 'Files'
clang: error: no such file or directory: '(x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64'
clang: error: no such file or directory: 'Files'
clang: error: no such file or directory: '(x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/sysroot'

Wrapping the gcc-toolchain and sysroot paths in double-quotations by changing the relevant portions of scripts/get_cmake_vars/CMakeLists.txt appears to fix the problem. Note the escaped back-slash and double-quote.

if(CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN AND CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN)
    if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
        string(APPEND CMAKE_CXX_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}\\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_C_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}\\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_STATIC_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}\\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_SHARED_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN}\\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
    else()
        string(APPEND CMAKE_CXX_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN} \\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_C_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN} \\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_STATIC_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN} \\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
        string(APPEND CMAKE_SHARED_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_EXTERNAL_TOOLCHAIN} \\\"${CMAKE_CXX_COMPILER_EXTERNAL_TOOLCHAIN}\\\"")
    endif()
endif()

if(CMAKE_SYSROOT AND CMAKE_CXX_COMPILE_OPTIONS_SYSROOT)
    string(APPEND CMAKE_CXX_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}\\\"${CMAKE_SYSROOT}\\\"")
    string(APPEND CMAKE_C_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}\\\"${CMAKE_SYSROOT}\\\"")
    string(APPEND CMAKE_STATIC_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}\\\"${CMAKE_SYSROOT}\\\"")
    string(APPEND CMAKE_SHARED_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}\\\"${CMAKE_SYSROOT}\\\"")
endif()

However, I'm getting a different issue now and I believe that is we're still missing some paths needed for C++ due to how libc++ overlays on top of Bionic libc, as it's unable to find some of the header files:

"C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/bin/clang++.exe" "-Isrc\libharfbuzz.a.p" "-Isrc" "-I..\src\f4d3aa1127-a820a32874.clean\src" "-I." "-I..\src\f4d3aa1127-a820a32874.clean" "-ID:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/arm-android-sgi-shipping/include" "-ID:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/arm-android-sgi-shipping/include/libpng16" "-ID:/Devel/Monster/Dev/External/Android/support_libcxx/include" "-I\"D:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/arm-android-sgi-shipping/include\"" "-Xclang" "-fcolor-diagnostics" "-pipe" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-Wnon-virtual-dtor" "-std=c++11" "-fno-exceptions" "-fno-rtti" "-fno-exceptions" "-fno-rtti" "-fno-threadsafe-statics" "-fvisibility-inlines-hidden" "-DHAVE_CONFIG_H" "-g" "-DANDROID" "-fdata-sections" "-ffunction-sections" "-funwind-tables" "-fstack-protector-strong" "-no-canonical-prefixes" "-march=armv7-a" "-mthumb" "-Wformat" "-Werror=format-security" "-frtti" "-fexceptions" "-fPIC" "-fasynchronous-unwind-tables" "-fno-exceptions" "-fno-rtti" "-ffunction-sections" "-fdata-sections" "-fstack-protector-strong" "-fstrict-aliasing" "-fthreadsafe-statics" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-U_FORTIFY_SOURCE" "-D_FORTIFY_SOURCE=2" "-D_REENTERANT" "--target=armv7-none-linux-androideabi19" "--gcc-toolchain=\"C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64\"" "--sysroot=\"C:/Program Files (x86)/Android/android-sdk/ndk/22.0.7026061/toolchains/llvm/prebuilt/windows-x86_64/sysroot\"" "-Oz" "-Os" "-g2" "-gdwarf-2" "-fomit-frame-pointer" "-DNDEBUG" "-flto=thin" "-fPIC" "-pthread" "-Wno-non-virtual-dtor" -MD -MQ src/libharfbuzz.a.p/hb-ot-face.cc.o -MF "src\libharfbuzz.a.p\hb-ot-face.cc.o.d" -o src/libharfbuzz.a.p/hb-ot-face.cc.o "-c" ../src/f4d3aa1127-a820a32874.clean/src/hb-ot-face.cc
In file included from ../src/f4d3aa1127-a820a32874.clean/src/hb-ot-face.cc:27:
In file included from ..\src\f4d3aa1127-a820a32874.clean\src/hb-ot-face.hh:32:
..\src\f4d3aa1127-a820a32874.clean\src/hb.hh:179:10: fatal error: 'math.h' file not found
#include <math.h>
         ^~~~~~~~

I will investigate and report back.

jwtowner commented 3 years ago

Okay, so I modified scripts/get_cmake_vars/CMakeLists.txt to add the system include paths needed for C++ compilation and I added them inside of the existing block that deals with CMAKE_SYSROOT like so:

if(CMAKE_SYSROOT AND CMAKE_CXX_COMPILE_OPTIONS_SYSROOT)
    string(APPEND CMAKE_CXX_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}${CMAKE_SYSROOT}")
    string(APPEND CMAKE_C_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}${CMAKE_SYSROOT}")
    string(APPEND CMAKE_STATIC_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}${CMAKE_SYSROOT}")
    string(APPEND CMAKE_SHARED_LINKER_FLAGS " ${CMAKE_CXX_COMPILE_OPTIONS_SYSROOT}${CMAKE_SYSROOT}")
    if (CMAKE_SYSTEM_NAME MATCHES "Android")
        if(CMAKE_LIBRARY_ARCHITECTURE AND EXISTS "${CMAKE_SYSROOT}/usr/include/${CMAKE_LIBRARY_ARCHITECTURE}")
            string(APPEND CMAKE_CXX_FLAGS " -isystem ${CMAKE_SYSROOT}/usr/include/${CMAKE_LIBRARY_ARCHITECTURE}")
        endif()
        string(APPEND CMAKE_CXX_FLAGS " -isystem ${CMAKE_SYSROOT}/usr/include")
    endif()
endif()

I'm not sure if there's a CMAKE variable we can use for -isystem or if there's a better way to structure the above that you may want to use that's more generalized for other platforms, but with that, everything compiles.

Unfortunately, I could not get it to work when the Android NDK's filesystem path contained a space, even with double-quotation escapes. I think it has something to do with how the various CXXFLAGS arguments, delimited by spaces, are themselves again double-quoted before being passed to Meson, and because isystem in particular doesn't support a form that doesn't already use a space. This results in "-isystem" "\"C:/Program Files (x86)/.../sysroot\"" instead of "-isystem \"C:/Program Files (x86)/.../sysroot\"" being passed on the command line to Meson. Not sure if there's an easy fix for this we can use in scripts/get_cmake_vars/CMakeLists.txt. My current workaround is just to setup a directory symlink for the Android NDK in my wrapper scripts before invoking vcpkg, so regardless it's not a blocker anymore.

jwtowner commented 3 years ago

I may have spoke too soon. Everything builds fine for Android arm and arm64, but the x86 and x64 target architectures fail. Seems like the --target and --sysroot parameters are already added, but contain a space between the double hypens, resulting in unknown argument errors.

For example, building harfbuzz:x64-android gives me this:

Build started at 2021-02-16T15:08:56.556844
Main binary: D:\Devel\vcpkg\downloads\tools\python\python-3.9.0-x64\python.exe
Build Options: -Dicu=disabled -Dgraphite=disabled -Dglib=disabled -Dfreetype=enabled -Dgobject=disabled -Dcairo=disabled -Dfontconfig=disabled -Dintrospection=disabled -Ddocs=disabled -Dtests=disabled -Dbenchmark=disabled -Ddebug=false '-Dcmake_prefix_path=['"'"'D:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/x64-android-sgi-shipping'"'"','"'"'D:/Devel/Monster/Dev/External/vcpkg/vcpkg/installed/x64-android-sgi-shipping/debug'"'"']' -Dprefix=D:/Devel/Monster/Dev/External/vcpkg/vcpkg/packages/harfbuzz_x64-android-sgi-shipping -Dlibdir=lib -Dbackend=ninja -Dbuildtype=plain -Ddefault_library=static -Dwrap_mode=nodownload '--native-file D:/Devel/Monster/Dev/External/vcpkg/vcpkg/buildtrees/harfbuzz/meson-nativ-x64-android-sgi-shipping.log' '--native-file D:/Devel/Monster/Dev/External/vcpkg/vcpkg/buildtrees/harfbuzz/meson-nativ-x64-android-release.log'
Python system: Windows
The Meson build system
Version: 0.56.99
Source dir: D:\Devel\vcpkg\buildtrees\harfbuzz\src\f4d3aa1127-a820a32874.clean
Build dir: D:\Devel\vcpkg\buildtrees\harfbuzz\x64-android-rel
Build type: native build
Project name: harfbuzz
Project version: 2.7.4
None of 'CFLAGS' are defined in the environment, not changing global flags.
None of 'LDFLAGS' are defined in the environment, not changing global flags.
None of 'CPPFLAGS' are defined in the environment, not changing global flags.
None of 'CC_LD' are defined in the environment, not changing global flags.
Sanity testing C compiler: C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe
Is cross compiler: False.
None of 'CC_LD' are defined in the environment, not changing global flags.
Sanity check compiler command line: C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe D:\Devel\vcpkg\buildtrees\harfbuzz\x64-android-rel\meson-private\sanitycheckc.c -o D:\Devel\vcpkg\buildtrees\harfbuzz\x64-android-rel\meson-private\sanitycheckc.exe -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fPIC -fasynchronous-unwind-tables -ffunction-sections -fdata-sections -fstack-protector-strong -fstrict-aliasing -fthreadsafe-statics -fvisibility=hidden -fvisibility-inlines-hidden -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_REENTERANT --target=x86_64-none-linux-android21 --gcc-toolchain=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64 --sysroot=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot -isystem C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include/x86_64-linux-android -isystem C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include -O2 -DNDEBUG -Os -g2 -gdwarf-2 -fomit-frame-pointer -DNDEBUG -flto=thin -ID:/Devel/vcpkg/vcpkg/installed/x64-android-sgi-shipping/include -pipe -D_FILE_OFFSET_BITS=64 - -target=x86_64-none-linux-android21 - -gcc-toolchain=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64 - -sysroot=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot -LD:/Devel/vcpkg/installed/x64-android-sgi-shipping/lib
Sanity check compile stdout:

-----
Sanity check compile stderr:
clang: error: unknown argument '-target=x86_64-none-linux-android21'; did you mean '--target=x86_64-none-linux-android21'?
clang: error: unknown argument '-gcc-toolchain=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64'; did you mean '--gcc-toolchain=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64'?
clang: error: unknown argument '-sysroot=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot'; did you mean '--sysroot=C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/sysroot'?
clang: error: -E or -x required when input is from standard input
clang: error: -E or -x required when input is from standard input
clang: error: -E or -x required when input is from standard input

-----

..\src\f4d3aa1127-a820a32874.clean\meson.build:1:0: ERROR: Compiler C:/Windows/Temp/2CB702BC-7649-4C41-B9AE-C2F75D8AC52A/toolchains/llvm/prebuilt/windows-x86_64/bin/clang.exe can not compile programs.
Neumann-A commented 3 years ago

@jwtowner merge with master. The regex for meson should be fixed.

jwtowner commented 3 years ago

@Neumann-A

@jwtowner merge with master. The regex for meson should be fixed.

Hi, I've been working out of master and testing this on our build machines which simply clone from microsoft:master. Is there a specific PR or commit where some of this was fixed?

EDIT: I think I found it #15867

It's possible I wasn't using this and may have been using a stale snapshot from before the weekend, I will try it again with -isystem.

Neumann-A commented 3 years ago

should be #15867

jwtowner commented 3 years ago

@Neumann-A Sadly, every combination of quotes and escapes that I've tried does not appear to work. Looking in the generated cmake-vars-***.cmake.log file shows that none of them result in the desired value.

What I've tried so far:

string(APPEND CMAKE_CXX_FLAGS " -isystem \"${CMAKE_SYSROOT}/usr/include\"")
string(APPEND CMAKE_CXX_FLAGS " -isystem \\\"${CMAKE_SYSROOT}/usr/include\\\"")
string(APPEND CMAKE_CXX_FLAGS " -isystem\\ \"${CMAKE_SYSROOT}/usr/include\"")
string(APPEND CMAKE_CXX_FLAGS " \"-isystem \\\"${CMAKE_SYSROOT}/usr/include\\\"\"")
string(APPEND CMAKE_CXX_FLAGS " \\\"-isystem \\\"${CMAKE_SYSROOT}/usr/include\\\"\\\"")
string(APPEND CMAKE_CXX_FLAGS " '-isystem \"${CMAKE_SYSROOT}/usr/include\"'")
string(APPEND CMAKE_CXX_FLAGS " '-isystem \\\"${CMAKE_SYSROOT}/usr/include\\\"'")
string(APPEND CMAKE_CXX_FLAGS " \"-isystem '${CMAKE_SYSROOT}/usr/include'\"")
string(APPEND CMAKE_CXX_FLAGS " -isystem\\ \\\"${CMAKE_SYSROOT}/usr/include\\\"")
string(APPEND CMAKE_CXX_FLAGS " -isystem\\ '${CMAKE_SYSROOT}/usr/include'")
jwtowner commented 3 years ago

I've created PR #16260 that fixes two independent issues in scripts/cmake/vcpkg_configure_meson.cmake I ran into above when trying to build harfbuzz for android, working off of the changes in this PR and the changes in my post here.

The only problem left still is with spaces in the Android NDK filesystem path, haven't gotten further than the progress in the above post, but as I've mentioned, current work around is to set up a symbolic link or directory junction using mklink on Windows.

xandox commented 3 years ago

@jwtowner Thank you very match, I will apply your changes to scripts/get_cmake_vars/CMakeLists.txt quite letter.

Neumann-A commented 3 years ago

@jwtowner do you know the result you want to have in cmake-vars-***.cmake.log. But it is very likely that libtool will fail anyway however you quote the paths.

jwtowner commented 3 years ago

@Neumann-A

@jwtowner do you know the result you want to have in cmake-vars-***.cmake.log. But it is very likely that libtool will fail anyway however you quote the paths.

Yeah, I think the issue is in libtool and possibly in Meson or elsewhere now as well. As a test, I manually modified vcpkg_configure_meson.cmake to format the CFLAGS/CXXFLAGS as desired, and despite showing up correctly in the cmake-vars logs, they still were being passed incorrectly to Meson. And for what it's worth, I just ran into the same issue with libvpx on Android, which uses a custom configure/make based build process. So even if we somehow fix it for Meson, I'd still going to need to rely on the directory symlink to remove spaces from the directory path, and therefore fixing it probably isn't a high priority issue.

jwtowner commented 3 years ago

@xandox So, great news. I've managed to get this working on iOS as well and have found CMake variables for the -isystem flags for general use. For iOS and macOS, there are completely different variables we have to look at for SYSROOT and such. CMAKE_OSX_SYSROOT instead of CMAKE_SYSROOT, and so on.

It also turns out that all of the extra system include directories are already added to CMAKE_C_IMPLICIT_INCLUDE_DIRECTORIES and CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES by the underlying toolchain configurations, so I've changed the code to enumerate those lists and add each of them to the CFLAGS and CXXFLAGS.

Here's the full updated scripts/get_cmake_vars/CMakeLists.txt that I'm using.

One thing the above does not do for iOS & macOS is setup the frameworks for CFLAGS/CXXFLAGS. I think this is more involved in that we have to enumerate the framework directories on the filesystem in each of parent directories listed in the CMAKE_${lang}_FRAMEWORK_SEARCH_PATH and CMAKE_${lang}_OSX_SYSTEMFRAMEWORK_SEARCH_PATH lists, determine the type of framework and set up the arguments appropriately. It's not needed for packages that don't use Apple's frameworks, such as harfbuzz with CoreText disabled, but turning on the CoreText feature would require them.

xandox commented 3 years ago

I'd strongly prefer the port changes be pulled out before the final merge and made into separate PRs. Changes to the core scripts helpers must maintain backwards compatibility with older versions, so it should never be necessary to simultaneously change ports with the script changes.

I am not sure I know how to organize this. If port fails to build during checks, I should fix it, check again, and then make separated PR for it? But what if fixes will be incompatible with old scripts versions? I even do not say it gone take forever.

xandox commented 3 years ago

I made PRs for current ports.

xandox commented 3 years ago

Hello, Can someone fix osx builder. It seems that it out of disk space.

JackBoosY commented 3 years ago

@xandox We'll fix this tomorrow.

JackBoosY commented 3 years ago

Should wait for https://github.com/microsoft/vcpkg/pull/17227 or #17376 merge.

dg0yt commented 3 years ago

Instead of proliferating _vcpkg_determine_autotools_target_arch_..., wouldn't it make sense to move the responsibility to provide matching variables from the triplet files? The triplet files can be customized by the user, in particular when new targets appear. And the values would become available to ports which don't use vcpkg_configure_make. (This is a general question, not a direct request to change this PR.)

xandox commented 3 years ago

@dg0yt _vcpkg_determine_autotools_target_cpu creates output based on VCPKG_TARGET_ARCHITECTURE which comes directly from triplet file. _vcpkg_determine_autotools_target_os creates output based on VCPKG_DETECTED_CMAKE_SYSTEM_NAME which comes from android toolchain file or directly from current host os. Why do not use value from triplet file see comment https://github.com/microsoft/vcpkg/pull/15605#discussion_r597963125

dg0yt commented 3 years ago

_vcpkg_determine_autotools_target_cpu creates output based on VCPKG_TARGET_ARCHITECTURE which comes directly from triplet file. _vcpkg_determine_autotools_target_os creates output based on VCPKG_DETECTED_CMAKE_SYSTEM_NAME which comes from android toolchain file or directly from current host os. Why do not use value from triplet file see comment #15605 (comment)

Maybe I failed to make my point. I want to try in another way: When users want to target autotools' x86_64-w64-mingw32 [!] or arm2025-linux-androidNT, it would be easy if they could put this literally in a variable in the triplet file. (You might still use these functions when the variable is not set.) On the other hand I have the impression that there is no function to get variables from the triplet file matching the host, at the moment.

xandox commented 3 years ago

When users want to target autotools' x86_64-w64-mingw32 [!] or arm2025-linux-androidNT, it would be easy if they could put this literally in a variable in the triplet file.

Not sure this is a good idea at all. However it could be done letter when somebody really will need it.

xandox commented 3 years ago

On the other hand I have the impression that there is no function to get variables from the triplet file matching the host, at the moment.

Not sure I got what you mean.

dg0yt commented 3 years ago

On the other hand I have the impression that there is no function to get variables from the triplet file matching the host, at the moment.

Not sure I got what you mean.

I suggested to get the autoconf triplet from a variable in vcpkg's triplet files. For cross compiling, autoconf triplets are needed for the target and for the host. However, scripts/port.cmake only loads vcpkg's triplet file for the target, so there is no way get the proposed variable for the host.

ras0219-msft commented 3 years ago

In order to work broadly across all C++ buildsystems, we don't want to specialize vcpkg heavily for those which build simultaneously for host and target (or in autotools parlance: build and host). This also has additional advantages as it means we can separately package and reuse tool builds from different targets as long as the host is the same.

Our current desired behavior is to:

  1. Run a native build (possibly full, possibly reduced to just built-time tools) which is packaged in a reusable way
  2. Run a target build, without rebuilding the build-time tools -- use them from the previous native build.

This also ensures that our triplets stay completely orthogonalized and users don't need to produce the cross-product of all possible native+targets. It is possible in the future that we can add specializations for autotools/meson/etc that start leaking information between these boundaries (such as perhaps a 'port' that actually just generates a 'host compiler info' file), but this is our current approach.

dg0yt commented 3 years ago

@ras0219-msft I'm not sure if the last post in response to my question. If yes, I'm still misunderstood. We agree on the orthogonality of native and target builds.

What I proposed is that the autoconf triplets shall be declared in vcpkg triplet files, instead of being constructed in a procedural way. I admit that declaring the autoconfig triplet in the vcpkg triplet file can be seen as leaking buildsystem details into more general vcpkg files. But it is a single variable, and it is a welcome hook for users with different CPUs or OS, Probably it is is also useful for some portfiles (cf. git grep '[-]-host).

Examples:

At least for mingw, the triplet would also guide compiler lookup in scripts/toolchains/mingw.cmake.

Neumann-A commented 3 years ago

you know there is VCPKG_MAKE_BUILD_TRIPLET which is totally undocumented but exists ;)

dg0yt commented 3 years ago

you know there is VCPKG_MAKE_BUILD_TRIPLET which is totally undocumented but exists ;)

I see, it is somewhat hidden, documented with BUILD_TRIPLET parameter for vcpkg_configure_make, but not in the general triplet files documentation. In this state, it is clear why it is not used in other scripts.

Good to learn about it now: If it is really meant to stay, we may have to watch out for it in #17438....

JackBoosY commented 3 years ago

Depends on https://github.com/microsoft/vcpkg/pull/17983.

JackBoosY commented 3 years ago

Ping @ras0219 @ras0219-msft for reply.

xandox commented 3 years ago

up

m-kuhn commented 3 years ago

Thanks for this, it fixes building libpq :+1:

It still fails with fontconfig

$ cat buildtrees/fontconfig/build-arm64-android-dbg-err.log

gcc: error: unrecognized command line option '--target=aarch64-none-linux-android21'
gcc: error: unrecognized command line option '--gcc-toolchain=/opt/android-sdk/ndk/21.3.6528147/toolchains/llvm/prebuilt/linux-x86_64'
gcc: error: unrecognized command line option '-fno-limit-debug-info'
make[4]: *** [Makefile:667: fc-case] Error 1
make[3]: *** [Makefile:670: fccase.h] Error 1
make[2]: *** [Makefile:415: all] Error 2
make[1]: *** [Makefile:602: all-recursive] Error 1
make: *** [Makefile:486: all] Error 2
xandox commented 3 years ago

@m-kuhn can you provide full logs (configure log, build stdout log and build stderr log)

m-kuhn commented 3 years ago

@xandox here is the complete list of logs

https://gist.github.com/m-kuhn/0fec06b59597d3a20581bdb0f20f13a8

xandox commented 3 years ago

@m-kuhn thank you. It's looks like there are problem with tool which must be build for host machine and not for target. This package needs be pached. There a lot of packages with same problem and it's out of scope current pr.

dg0yt commented 3 years ago

@mkuhn @xandox Looks like a draft PR for cross-builds was closed (not merged) just a few days ago, #15869.

m-kuhn commented 3 years ago

Thank you for looking into it and sharing the findings @xandox and thanks for the additional pointer @dg0yt

Would be great to see vcpkg_configure_make fixed soon so the path to follow up issues is cleared

m-kuhn commented 3 years ago

For the record, the build also fails when removing the fc-cache call from the port file. https://gist.github.com/m-kuhn/f3e63be2f72fd4830012505f88a4881e