Bitcoin full node and query server

Apr 16, 2026

View in context in the libbitcoin Slack #general mirror.

Huddle with pmienk, eynhaender, evoskuil, Rowan Voskuil, Marnix · 275 min15:55

13 replies · evoskuil, eynhaender, pmienk · last Apr 16, 2026

evoskuil18:16

/// Map standard XCPU defines for intrinsics usage.
/// vc++: There are no native flags for SHA and SSE41.
#if defined(HAVE_XCPU)
    // -msha
    // vc++: SHANI not independently configurable (requires custom option).
    #if defined(__SHA__)
        #define HAVE_SHANI
        #define HAVE_SHA
    #endif
    // -mavx512bw
    // vc++: Advanced Vector Extensions 512 (X86/X64) (/arch:AVX512)
    #if defined(__AVX512BW__)
        #define HAVE_AVX512
        #define HAVE_512
    #endif
    // -mavx2
    // vc++: Advanced Vector Extensions 2 (X86/X64) (/arch:AVX2)
    #if defined(__AVX2__)
        #define HAVE_AVX2
        #define HAVE_256
    #endif
    // -msse4.1
    // vc++: Use Advanced Vector Extensions (X86/X64) (/arch:AVX).
    #if defined(__SSE4_1__)
        #define HAVE_SSE4
        #define HAVE_128
    #endif
#endif

/// Map standard ARM defines for intrinsics usage. 
/// SVE maximum width is not detectable (requires custom options).
#if defined(HAVE_ARM)
    // -march=armv8-a+crypto
    // Requires 64 bit build.
    #if defined(__ARM_FEATURE_CRYPTO)
        #define HAVE_CRYPTO
        #define HAVE_SHA
    #endif
    // -march=armv8-a+sve
    // Requires 64 bit build.
    #if defined(__ARM_FEATURE_SVE)
        #define HAVE_SVE
    #endif
    // -march=armv8-a (64 bit)
    // -march=armv7-a -mfpu=neon -mfloat-abi=hard (32 bit)
    #if defined(__ARM_NEON)
        #define HAVE_NEON
        #define HAVE_128
    #endif
#endif

eynhaender19:11

eynhaender19:11

this is what my macOS binary looks like

pmienk19:12

so... compiled but not supported. is it an arm or x64?

(edited)

eynhaender19:13

arm

pmienk19:13

so the compiler could compile for x64 and we turned on shani but it can't execute

pmienk20:13

Building Mixed Arm64/x64 Applications To build an application that utilizes x64 libraries on an Arm build, developers must use Visual Studio 2022 (version 17.3 or later) with the Arm64EC tools enabled. The process involves configuring the project to build specific parts as Arm64EC while keeping others as standard x64, ensuring the solution links against the correct versions of dependencies.

Configuration: In the Visual Studio Configuration Manager, create a new platform by selecting Arm64EC and copying settings from x64.

CMake Setup: For CMake projects, add a configuration in CMakePresets.json with "architecture": { "value": "arm64ec", "strategy": "external" } and set environment variables CXXFLAGS and CFLAGS to /arm64EC.

Linking: When linking, use the /machine:arm64x flag to combine the Arm64 and x64 artifacts into a single binary that can run on Arm64 devices.
Dependencies: Ensure external libraries are linked against their x64 or Arm64EC versions; if a library is only available as x64, it will run under emulation within the Arm64EC process.

evoskuil20:48

I relinked the build using the ARM64EC option but got the same link failure on boost.

evoskuil20:49

LINK : fatal error LNK1104: cannot open file 'libboost_locale-vc143-mt-s-a64-1_86.lib'

evoskuil20:53

I assume the a64 implies ARM64, and this lib doesn't exist. I'm not yet clear on where the expected path is coming from. But if I could get it to use the x64 with ARM64EC is should link.

👍🏻 1

evoskuil21:14

Boost links these files based on a single header in its base header library, called auto_link.hpp. It constructs the lib path in parts, including this:

#if defined( _M_IX86 )
#  define BOOST_LIB_ARCH_AND_MODEL_OPT "-x32"
#elif defined( _M_X64 )
#  define BOOST_LIB_ARCH_AND_MODEL_OPT "-x64"
#elif defined( _M_ARM )
#  define BOOST_LIB_ARCH_AND_MODEL_OPT "-a32"
#elif defined( _M_ARM64 )
#  define BOOST_LIB_ARCH_AND_MODEL_OPT "-a64"
#endif

...
#if defined(BOOST_LIB_NAME) \
      && defined(BOOST_LIB_PREFIX) \
      && defined(BOOST_LIB_TOOLSET) \
      && defined(BOOST_LIB_THREAD_OPT) \
      && defined(BOOST_LIB_RT_OPT) \
      && defined(BOOST_LIB_ARCH_AND_MODEL_OPT) \
      && defined(BOOST_LIB_VERSION)

So when _M_ARM64 is defined (it is) boost switches to -a64. The issue is simply that these libs are not in the NuGet package. But good to know that boost does expect and therefore build them. I could probably copy the x64 into the expected path and link with ARM64EC.

evoskuil21:16

The above is, in keeping with boost non-standardness, not consistent with NuGet targeting. For our packaging (e.g. secp256k1) we produce the paths in the targets file (as intended), using a similar naming convention.

(edited)

evoskuil21:29

The copy/renaming works to get past the link errors, but then just lots of unresolved externals.