Installing a package as a static library for Linux/mac target should not require patchelf to be installed

[LandryNorris]

Describe the bug

The current regex for excluding files does not exclude static libraries (.a files). Static libraries cannot have an rpath, and they will be rejected by patchelf since they don't start with the ELF header. Therefore, static libraries should be excluded.

This issue arose while cross-building a custom package from Windows to Linux, using a custom triplet to set the GCC compiler path. To avoid requiring patchelf on the developer's system, it's necessary to exclude static libraries. Since only a static binary is being built, patchelf isn't needed.

Currently, z_vcpkg_fixup_rpath_in_dir is always called when building for Linux, which mandates the use of patchelf even for static builds.

Environment

• OS: Windows 11
• Compiler: GCC

Expected behavior
A clear and concise description of what you expected to happen.

I would expect that .a files will not require patchelf to run, since static libraries don't have a rpath

Failure logs
-(please attached failure logs)

CMake Error at scripts/cmake/vcpkg_find_acquire_program.cmake:166 (message):
  Could not find patchelf.  Please install it via your package manager.
Call Stack (most recent call first):
  scripts/cmake/z_vcpkg_fixup_rpath.cmake:96 (vcpkg_find_acquire_program)
  scripts/ports.cmake:196 (z_vcpkg_fixup_rpath_in_dir)

Additional context
Add any other context about the problem here.

I confirmed locally that changing

list(FILTER elf_files EXCLUDE REGEX "\\\.(cpp|cc|cxx|c|hpp|h|hh|hxx|inc|json|toml|yaml|man|m4|ac|am|in|log|txt|pyi?|pyc|pyx|pxd|pc|cmake|f77|f90|f03|fi|f|cu|mod|ini|whl|cat|csv|rst|md|npy|npz|template|build)$")

to

list(FILTER elf_files EXCLUDE REGEX "\\\.(a|cpp|cc|cxx|c|hpp|h|hh|hxx|inc|json|toml|yaml|man|m4|ac|am|in|log|txt|pyi?|pyc|pyx|pxd|pc|cmake|f77|f90|f03|fi|f|cu|mod|ini|whl|cat|csv|rst|md|npy|npz|template|build)$")

resolves my issue.

[LandryNorris]

For extra reference, here is my toolchain file:

C:/path/to/toolchain/arm32-linux.cmake:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)

set(CMAKE_C_COMPILER "C:/path/to/arm-linux-gnueabi-gcc.exe")

and my triplets file is

set(VCPKG_TARGET_ARCHITECTURE arm)
set(VCPKG_CRT_LINKAGE static)
set(VCPKG_LIBRARY_LINKAGE static)
set(VCPKG_CMAKE_SYSTEM_NAME Linux)

set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE "C:/path/to/toolchain/arm32-linux.cmake")

When I exclude .a files from patching, the install succeeds, and I see my lib.a in vcpkg_installed/arm32-linux/lib

[dg0yt]

This issue arose while cross-building a custom package from Windows to Linux, using a custom triplet to set the GCC compiler path. To avoid requiring patchelf on the developer's system, it's necessary to exclude static libraries. Since only a static binary is being built, patchelf isn't needed.

Currently, z_vcpkg_fixup_rpath_in_dir is always called when building for Linux, which mandates the use of patchelf even for static builds.

It is a little bit more complicated.

• Ports may build dynamic libs even for a static triplet when this is the only supported configuration and it doesn't conflict with CRT linkage.
• Users may customize linkage per port.

OTOH there is a direct switch if you don't want to deal with patchelf. Add

set(VCPKG_FIXUP_ELF_RPATH OFF)

to your custom triplet file.

[LandryNorris]

When a port builds a dynamic library, does it typically set the extension as so, dylib, dll, etc. for the platform? Can we assume that the .a extension says it's a static library (and can be excluded)? I'll take a look at the switch, either way, since it should fix my issue and allow me to still use main on this repo.

[dg0yt]

Excluding .a is fine IMO. That's why I comment here and not on the PR.
My point is: Just don't assume a static triplet would never want patchelf.