cross-compilation: failure to cross compile on Ubunto for Windows

[vtorri]

commands to compile:

cmake \
    -DCMAKE_TOOLCHAIN_FILE=../cross_toolchain.txt \
    -DCMAKE_INSTALL_PREFIX=$prefix_unix \
    -DCMAKE_BUILD_TYPE=Release \
    -DBUILD_SHARED_LIBS=TRUE \
    -DAVIF_CODEC_AOM=SYSTEM \
    -DAVIF_CODEC_DAV1D=SYSTEM \
    -DAVIF_BUILD_APPS:BOOL=OFF \
    -G Ninja \
    .. 

cross compilation file:

set(CMAKE_SYSTEM_PROCESSOR @proc@)

# binaries
set(CMAKE_C_COMPILER @host@-gcc)
set(CMAKE_CXX_COMPILER @host@-g++)
set(CMAKE_LINKER @host@-ld)
set(CMAKE_STRIP @host@-strip)
set(CMAKE_RC_COMPILER @host@-windres)

set(CMAKE_FIND_ROOT_PATH @prefix@)

# flags
set(CMAKE_C_FLAGS "-I@prefix@/include -D__USE_MINGW_ANSI_STDIO=0 -D_WIN32_WINNT=@winver@")
set(CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS}")

set(CMAKE_C_FLAGS_DEBUG "-Og -g3 -ggdb3")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG}")

set(CMAKE_C_FLAGS_RELEASE "-O2 -pipe -march=native")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE}")

set(CMAKE_SHARED_LINKER_FLAGS "-L@prefix@/lib")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_SHARED_LINKER}")

output:

[2/26] Building C object CMakeFiles/avif_obj.dir/src/mem.c.obj
[3/26] Building C object CMakeFiles/avif_obj.dir/src/properties.c.obj
[4/26] Building C object CMakeFiles/avif_obj.dir/src/rawdata.c.obj
[5/26] Building C object CMakeFiles/avif_obj.dir/src/io.c.obj
[6/26] Building C object CMakeFiles/avif_obj.dir/src/reformat_libsharpyuv.c.obj
[7/26] Building C object CMakeFiles/avif_obj.dir/src/exif.c.obj
[8/26] Building C object CMakeFiles/avif_obj.dir/src/colrconvert.c.obj
[9/26] Building C object CMakeFiles/avif_obj.dir/src/obu.c.obj
[10/26] Building C object CMakeFiles/avif_obj.dir/src/scale.c.obj
[11/26] Building C object CMakeFiles/avif_obj.dir/src/utils.c.obj
[12/26] Building C object CMakeFiles/avif_obj.dir/src/codec_dav1d.c.obj
[13/26] Building C object CMakeFiles/avif_obj.dir/src/colr.c.obj
[14/26] Building C object CMakeFiles/avif_obj.dir/src/alpha.c.obj
[15/26] Building C object CMakeFiles/avif_obj.dir/src/reformat_libyuv.c.obj
[16/26] Building C object CMakeFiles/avif_obj.dir/src/sampletransform.c.obj
[17/26] Building C object CMakeFiles/avif_obj.dir/src/stream.c.obj
[18/26] Building C object CMakeFiles/avif_obj.dir/src/codec_aom.c.obj
[19/26] Building C object CMakeFiles/avif_obj.dir/src/gainmap.c.obj
[20/26] Building C object CMakeFiles/avif_obj.dir/src/avif.c.obj
[21/26] Building C object CMakeFiles/avif_obj.dir/src/write.c.obj
[22/26] Building C object CMakeFiles/avif_obj.dir/src/reformat.c.obj
[23/26] Building C object CMakeFiles/avif_obj.dir/src/read.c.obj
[24/26] Linking C static library libavif_internal.a
[25/26] Linking CXX shared library libavif.dll
FAILED: libavif.dll libavif.dll.a 
: && /usr/bin/x86_64-w64-mingw32-g++ -I/home/vtorri/ewpi_64/include -D__USE_MINGW_ANSI_STDIO=0 -D_WIN32_WINNT=0x0A00 -O2 -pipe -march=native  -L/home/vtorri/ewpi_64/lib -shared -o libavif.dll -Wl,--out-implib,libavif.dll.a -Wl,--major-image-version,16,--minor-image-version,4 CMakeFiles/avif_obj.dir/src/alpha.c.obj CMakeFiles/avif_obj.dir/src/avif.c.obj CMakeFiles/avif_obj.dir/src/colr.c.obj CMakeFiles/avif_obj.dir/src/colrconvert.c.obj CMakeFiles/avif_obj.dir/src/diag.c.obj CMakeFiles/avif_obj.dir/src/exif.c.obj CMakeFiles/avif_obj.dir/src/gainmap.c.obj CMakeFiles/avif_obj.dir/src/io.c.obj CMakeFiles/avif_obj.dir/src/mem.c.obj CMakeFiles/avif_obj.dir/src/obu.c.obj CMakeFiles/avif_obj.dir/src/properties.c.obj CMakeFiles/avif_obj.dir/src/rawdata.c.obj CMakeFiles/avif_obj.dir/src/read.c.obj CMakeFiles/avif_obj.dir/src/reformat.c.obj CMakeFiles/avif_obj.dir/src/reformat_libsharpyuv.c.obj CMakeFiles/avif_obj.dir/src/reformat_libyuv.c.obj CMakeFiles/avif_obj.dir/src/sampletransform.c.obj CMakeFiles/avif_obj.dir/src/scale.c.obj CMakeFiles/avif_obj.dir/src/stream.c.obj CMakeFiles/avif_obj.dir/src/utils.c.obj CMakeFiles/avif_obj.dir/src/write.c.obj CMakeFiles/avif_obj.dir/src/codec_dav1d.c.obj CMakeFiles/avif_obj.dir/src/codec_aom.c.obj  /home/vtorri/ewpi_64/lib/libyuv.dll.a  /home/vtorri/ewpi_64/lib/libdav1d.dll.a  /home/vtorri/ewpi_64/lib/libaom.dll.a  -l_aom_dep_lib_m-NOTFOUND  -l_aom_dep_lib_pthread-NOTFOUND  /home/vtorri/ewpi_64/lib/libvmaf.dll.a  -l_aom_dep_lib_m-NOTFOUND  -l_aom_dep_lib_pthread-NOTFOUND  /home/vtorri/ewpi_64/lib/libvmaf.dll.a  -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && :
/usr/bin/x86_64-w64-mingw32-ld : ne peut pas trouver -l_aom_dep_lib_m-NOTFOUND : Aucun fichier ou dossier de ce nom
/usr/bin/x86_64-w64-mingw32-ld : ne peut pas trouver -l_aom_dep_lib_pthread-NOTFOUND : Aucun fichier ou dossier de ce nom
/usr/bin/x86_64-w64-mingw32-ld : ne peut pas trouver -l_aom_dep_lib_m-NOTFOUND : Aucun fichier ou dossier de ce nom
/usr/bin/x86_64-w64-mingw32-ld : ne peut pas trouver -l_aom_dep_lib_pthread-NOTFOUND : Aucun fichier ou dossier de ce nom
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

no problem on Windows with msys2

[wantehchang]

Hi vtorri,

I will write a pull request to deal with the math library (-lm).

The pthread part of this issue seems related to issue #3262, which I just responded to and closed.

The build failure seems to suggest that Threads::Threads is pthread for mingw32. But for libavif we want to use Win32 threads on Windows. I wonder if we should delete the following line:

    set(THREADS_PREFER_PTHREAD_FLAG ON)

Could you please try that?

[kmilos]

IMHO it shouldn't be even trying to link dependencies of aom in a shared build?

So this could be an aom exported configuration problem instead?

Indeed, on MSYS2 and aom 3.13.3 I see this in AOMTargets.cmake:

# Create imported target AOM::aom
add_library(AOM::aom SHARED IMPORTED)

set_target_properties(AOM::aom PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "Threads::Threads"
)

# Create imported target AOM::aom_static
add_library(AOM::aom_static STATIC IMPORTED)

set_target_properties(AOM::aom_static PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "Threads::Threads"
)

Unless pthreads symbols are actually exposed by aom (which I don't think is the case), INTERFACE_LINK_LIBRARIES "Threads::Threads" should only figure for the aom_static target, but not for the shared aom one (overlinking).

[kmilos]

Yep:

https://aomedia.googlesource.com/aom/+/refs/tags/v3.14.1/CMakeLists.txt#858

https://aomedia.googlesource.com/aom/+/refs/tags/v3.14.1/cmake/aom_configure.cmake#439

[wantehchang]

Miloš: Thanks for your comment. Did I misunderstand this bug? I thought the -l_aom_dep_lib_m-NOTFOUND and -l_aom_dep_lib_pthread-NOTFOUND in the build log come from libavif's own dependencies. In libavif commit cbeb4d8, CMakeLists.txt, we have:

if(UNIX OR MINGW)
    # Find out if we have threading available
    set(THREADS_PREFER_PTHREAD_FLAG ON)
    find_package(Threads)
    target_link_libraries(avif_obj PRIVATE m Threads::Threads)
endif()

But indeed that cannot explain the _aom_dep_lib_ part of -l_aom_dep_lib_m-NOTFOUND and -l_aom_dep_lib_pthread-NOTFOUND.

[wantehchang]

Miloš: I wrote https://aomedia-review.googlesource.com/c/aom/+/214001 to fix the AOMTargets.cmake bug you reported in #3263 (comment). Please take a look.

Also, the aom.pc file generated on Linux has the following:

Libs: -L${libdir} -laom
Libs.private: -lm

Is it okay to have -lm in Libs.private?

[kmilos]

@wantehchang That should work... Have you checked the resulting AOMTargets.cmake?

Is it okay to have -lm in Libs.private?

That's what you want, and that only gets added when one does static linking. Compare pkgconf --libs aom vs pkgconf --static --libs aom.

[wantehchang]

Miloš: Yes, I checked the resulting AOMTargets.cmake on Linux. If the libaom changelist https://aomedia-review.googlesource.com/c/aom/+/214001 looks good to you, I can create a libaom v3.14.2 release with the bug fix.

Here are the diffs between the AOMTargets.cmake generated on Linux before and after the libaom changelist:

$ diff -u9 CMakeFiles/Export/1d4b5ee603978b91751e4a9c440422b3/AOMTargets.cmake ../AOMTargets.cmake
--- CMakeFiles/Export/1d4b5ee603978b91751e4a9c440422b3/AOMTargets.cmake	2026-06-18 11:15:49.173856207 -0700
+++ ../AOMTargets.cmake	2026-06-18 11:06:58.032605013 -0700
@@ -54,19 +54,18 @@
 if(_IMPORT_PREFIX STREQUAL "/")
   set(_IMPORT_PREFIX "")
 endif()
 
 # Create imported target AOM::aom
 add_library(AOM::aom SHARED IMPORTED)
 
 set_target_properties(AOM::aom PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
-  INTERFACE_LINK_LIBRARIES "m;Threads::Threads"
 )
 
 # Create imported target AOM::aom_static
 add_library(AOM::aom_static STATIC IMPORTED)
 
 set_target_properties(AOM::aom_static PROPERTIES
   INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
   INTERFACE_LINK_LIBRARIES "m;Threads::Threads"
 )

[kmilos]

Looks good, thanks!

[wantehchang]

Hi vtorri,

Based on Miloš's analysis, this bug is caused by the aom shared library overlinking its library dependencies. To fix this bug, I will create a libaom v3.14.2 release with the bug fix. Then the maintainer of the aom package in MinGW needs to update the aom package to v3.14.2.

[wantehchang]

Hi vtorri,

To simulate the upcoming libaom v3.14.2 release, could you find the AOMTargets.cmake file in your libaom installation?

Please edit the AOMTargets.cmake file and locate the following in the file:

# Create imported target AOM::aom
add_library(AOM::aom SHARED IMPORTED)

set_target_properties(AOM::aom PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
  INTERFACE_LINK_LIBRARIES "Threads::Threads"
)

Then comment out the line INTERFACE_LINK_LIBRARIES "Threads::Threads"

Does this fix the cross-compilation error?

[vtorri]

For your information, I compile libaom myself, so I don't use msys2/mingw aom package.

In this file, I have:

# Create imported target AOM::aom
add_library(AOM::aom SHARED IMPORTED)

set_target_properties(AOM::aom PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
)

nothing related to threads

it seems that in aom, you also use native Windows threads, so there should be no link to pthread at all in libavif linking