Linker Error when building everything from scratch on Windows 10

[Arebusf21]

When building everything from scratch following the guidelines in the README.MD file, https://github.com/AOMediaCodec/libavif?tab=readme-ov-file#build-everything-from-scratch

I get a linker error in the build using the build command: cmake --build libavif/build --parallel
The Linker error is:
LINK : warning LNK4044: unrecognized option '/static'; ignored [E:\Dev\libavif\build\avifdec.vcxproj]
LINK : fatal error LNK1104: cannot open file 'libjpeg\src\libjpeg-build\jpeg-static.lib' [E:\Dev\libavif\build\avifdec.
vcxproj]
LINK : warning LNK4044: unrecognized option '/static'; ignored [E:\Dev\libavif\build\avifenc.vcxproj]
LINK : fatal error LNK1104: cannot open file 'libjpeg\src\libjpeg-build\jpeg-static.lib' [E:\Dev\libavif\build\avifenc.
vcxproj]

the build process is looking in the libjpeg\src\libjpeg-build folder instead of the libjpeg\src\libjpeg-build\debug folder.

There are a number of CMake errors, one possibly related to the Linker error is:
-- Could NOT find JPEG (missing: JPEG_LIBRARY)

I have Windows 10 and Visual Studio 2022 installed.

session log:
session-log.txt

[jzern]

Thanks for the report. Try changing line 18 in cmake/Modules/LocalJpeg.cmake to:

        set(LIB_FILENAME "${LIB_DIR}/${CMAKE_BUILD_TYPE}/${CMAKE_STATIC_LIBRARY_PREFIX}jpeg-static${CMAKE_STATIC_LIBRARY_SUFFIX}")

The issue is that jpeg-static.lib is built to a subdirectory like Debug or Release. This may not be appropriate for all generators, but should work with the Visual Studio one.

You can also add --config=Release to your cmake --build command line to get an optimized build.

[jzern]

That didn't quite work with a clean build, add -DCMAKE_BUILD_TYPE=Release to the cmake command line as a workaround and use --config=Release with cmake --build.

[Arebusf21]

Do you still want me to make the change to LocalJpeg.cmake.txt?
my version does not have a line 63, see:
LocalJpeg.cmake.txt
the line you are asking me to change is line 18 in my version for MSVC

[jzern]

I'm sorry for the confusion, I'm not sure where I got line 63 from. Yes, please try line 18.

[Arebusf21]

substituted:
set(LIB_FILENAME "${LIB_DIR}/${CMAKE_BUILD_TYPE}/${CMAKE_STATIC_LIBRARY_PREFIX}jpeg-static${CMAKE_STATIC_LIBRARY_SUFFIX}")
for:
set(LIB_FILENAME "${LIB_DIR}/${CMAKE_STATIC_LIBRARY_PREFIX}jpeg-static${CMAKE_STATIC_LIBRARY_SUFFIX}")
in LocalJpeg.cmake

added -DCMAKE_BUILD_TYPE=Release
to:
cmake -S libavif -B libavif/build -DBUILD_SHARED_LIBS=OFF -DAVIF_CODEC_AOM=LOCAL -DAVIF_LIBYUV=LOCAL -DAVIF_LIBSHARPYUV=LOCAL -DAVIF_JPEG=LOCAL -DAVIF_ZLIBPNG=LOCAL -DAVIF_BUILD_APPS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS_RELEASE="-static" -DCMAKE_EXE_LINKER_FLAGS="-static"

added:
--config=Release
to the build command:
cmake --build libavif/build --parallel --config=Release

Result:
avifdec.exe and avifenc.exe were built but I have to test them.

session log:
sessionLog_Oct16.txt

[jzern]

Thanks for trying it out. I don't think this on its own is a good fix for multi-config generators like Visual Studio and Ninja Multi-Config given the reliance on CMAKE_BUILD_TYPE.

@vrabaud any thoughts? I tried using $ in various places, but BUILD_BYPRODUCTS in ExternalProject_Add didn't seem to pick up on it, though with >=3.20 add_custom_command sounds like it should support some generators.

[Arebusf21]

The resulting executables; avifenc.exe and avifdec.exe both seem to work ok but my testing was not exhaustive.
It would inspire more confidence if I could see it run with fewer "not found" errors, missing files and less failed tests.

Oct 17> Tested for debug and it also linked ok, in fact there were fewer errors.

[jzern]

It would inspire more confidence if I could see it run with fewer "not found" errors, missing files and less failed tests.

What "not found" errors are you referring to?

For the tests, if I configure with -DAVIF_GTEST=LOCAL -DAVIF_BUILD_TESTS=1 all of the unit tests will pass using ctest -C Release . from the build directory. The failing tests are shell scripts and make an assumption about binary location. Are you seeing failures elsewhere?

> ctest -C Release .
...

84% tests passed, 8 tests failed out of 49

Total Test time (real) =  53.23 sec

The following tests FAILED:
         42 - test_cmd (Failed)
         43 - test_cmd_animation (Failed)
         44 - test_cmd_grid (Failed)
         45 - test_cmd_icc_profile (Failed)
         46 - test_cmd_lossless (Failed)
         47 - test_cmd_metadata (Failed)
         48 - test_cmd_progressive (Failed)
         49 - test_cmd_targetsize (Failed)

[Arebusf21]

In my comment, I am referring back to the build process itself. Take a look at the session log from Oct16.
As far as the encode and decode functions themselves I cannot find any issues so far, so all looks good from that perspective.
It would take some effort to investigate the output from the build in detail, not being familiar with the code, but I am learning.

[jzern]

In the build log, many of the 'not found' messages are related to tests that cmake is doing related to build and platform detection.

Things like the following are to be expected during the configuration steps and can be ignored unless cmake exits with an error. Some of this output could likely be hidden, but in the case of failures it is helpful to have the configuration steps in the log.

-- Looking for fseeko
-- Looking for fseeko - not found
...
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
...
-- Looking for include file unistd.h
-- Looking for include file unistd.h - not found
...

[Arebusf21]

Ok, thanks, that's good to know, everything looks good from my end. Thanks for the help.

[jzern]

Thanks for raising the issue and working through it. I think there still would be some benefit to fixing some of the paths mentioned in the report when using the Visual Studio generator or Ninja Multi-Config.

[gitoss]

Thanks for raising the issue and working through it. I think there still would be some benefit to fixing some of the paths mentioned in the report when using the Visual Studio generator or Ninja Multi-Config.

+1 for finding a proper fix.

SVT-AV1 built with Visual Studio & LLVM is significantly faster than with MSYS2 & LLVM (i.e. media autobuild suite), and for avif encoding this is important, too...

[jzern]

Reopening this for visibility.

[gitoss]

set(LIB_FILENAME "${LIB_DIR}/${CMAKE_BUILD_TYPE}/${CMAKE_STATIC_LIBRARY_PREFIX}jpeg-static${CMAKE_STATIC_LIBRARY_SUFFIX}")

Replacing these 2 lines works.

@jzern could LocalJpeg.cmake not only check for if(MSVC), but for CMAKE_BUILD_TYPE being set, too - and set(LIB_FILENAME... to either the location with or without CMAKE_BUILD_TYPE?

If not, simply changing these two lines by default probably works, too - if CMAKE_BUILD_TYPE isn't set, then the path to the lib would just contain a double / instead of single /

libavif-fix.patch

[jzern]

Checking for both MSVC and CMAKE_BUILD_TYPE might work. I didn't give this too much thought at the time.