AOMediaCodec / libavif

libavif - Library for encoding and decoding .avif files
Other
1.55k stars 200 forks source link

Linker Error when building everything from scratch on Windows 10 #2477

Open Arebusf21 opened 3 days ago

Arebusf21 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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 commented 3 days ago

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

Arebusf21 commented 3 days ago

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 commented 2 days ago

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 commented 2 days ago

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 commented 1 day ago

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 commented 1 day ago

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.