search

the-tcpdump-group / libpcap

the LIBpcap interface to various kernel packet capture mechanism
https://www.tcpdump.org/
Other
2.67k stars 844 forks source link

CMake fails on Windows when building ARM64 on x64 host #1352

Open dmiller-nmap opened 2 weeks ago

dmiller-nmap commented 2 weeks ago

The SUITABLE_SNPRINTF check fails because the resulting ARM64 code cannot be run on the x64 host. CMAKE_CROSSCOMPILING is not set because both systems have the same CMAKE_SYSTEM_NAME ("Windows"). Not sure the best way to handle this, since a general check for identical architectures would miss the cases of ARM64 and x64 host systems targeting x86.

https://github.com/the-tcpdump-group/libpcap/blob/3bb233f54c75d10fa703c439cf7b595a8ebf42f2/CMakeLists.txt#L738-L792

infrastation commented 2 weeks ago

Could you add the steps to reproduce the problem?

mcr commented 2 weeks ago

I don't think we've ever supported cross-compiling on Windows.

But, it seems that "Windows" as a value for CMAKE_SYSTEM_NAME is wrong, if it implies x86_64, and Windows now supports building for ARM. Maybe WSL + ./configure is a better route.

dmiller-nmap commented 2 weeks ago

The CMake command I ran is in a script in Npcap's source tree. I believe the crucial part is the -A ARM64, but here is the entire command as run:

%CMAKE% -A ARM64 -DCMAKE_DISABLE_FIND_PACKAGE_OpenSSL=TRUE -DOpenSSL_FOUND=FALSE -DCMAKE_C_FLAGS_INIT="/guard:cf" -DCMAKE_SHARED_LINKER_FLAGS_INIT="/guard:cf" -DPacket_ROOT=..\%NPCAP_SDK% -DLIBRARY_NAME=wpcap -G "Visual Studio 17 2022" ..\libpcap\
guyharris commented 2 weeks ago

I believe the crucial part is the -A ARM64

According to the CMake 3.12 "cmake" command documentation (3.12 being the minimum version of CMake we require on Windows), -A "[Specifies] platform name if supported by generator." Following various links, it appears that this affects the value of the CMAKE_VS_PLATFORM_NAME variable.

Unfortunately, as you noted, CMAKE_CROSSCOMPILING is defined to mean "compiling for a different operating system", not "compiling for a different instruction set"; good luck if you're compiling for an Arm embedded Linux system on an x86 Linux system.

It appears that "cross-compiling for a different instruction set" amounts to CMAKE_SYSTEM_PROCESSOR not being equal to CMAKE_HOST_SYSTEM_PROCESSOR.

guyharris commented 2 weeks ago

See if this fixes it. (The check for a cross-compile doesn't occur in the 1.10 branch, so this doesn't need to be backported; we're not doing a check for a working snprintf() there.)

dmiller-nmap commented 2 weeks ago

It's working for me now, thanks.