WebP support in 3.3.x breaks linkage in static builds (Issue #26428)
hatelamers
hatelamers created an issue (wxWidgets/wxWidgets#26428)Build System Used
I build wxWidgets and/or my application using:
- [ x] CMake
- configure
- mingw32-make with makefile.gcc
- MSBuild (Microsoft Visual Studio solution file)
- nmake with makefile.vc
- Xcode
Description
When 3.3.x wxWidgets is configured with -DCMAKE_BUILD_TYPE=Debug -DwxBUILD_SHARED=OFF -DwxBUILD_USE_STATIC_RUNTIME=ON it builds allright, however application using it cannot be succefully linked anymore (used to work with 3.2.x versions).
First of all wxweb ignores wxBUILD_USE_STATIC_RUNTIME setting and tries to link against a dynamic RT lib, hense producing library conflicts while linking, only after supplying additional -DCMAKE_MSVC_RUNTIME_LIBRARY="MultiThreaded$<$<CONFIG:Debug>:Debug>" argument, the conflicts go away. None of other wxWidgets components behaves this way.
Secondly, webp now being per default required by core component makes find_package(wxWidgets COMPONENTS webp core) obligatory and that fails since the CMake version hasn't a clue what webp is and reports wxWidgets-NOTFOUND. None of other image support libraries in wxWidgets behaves this way.
Thirdly (and most severe), even the problems above having been patched away, it is still impossible to link statically against wxWidgets unless you recompile it with -DwxUSE_LIBWEBP=OFF, if you try otherwise you get link errors like:
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPDemuxInternal
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderOptionsInitInternal
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderNewInternal
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPDemuxDelete
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPDemuxGetFrame
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPDemuxReleaseIterator
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderDelete
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderGetInfo
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderHasMoreFrames
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderGetNext
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPAnimDecoderReset
[build] wxmsw33ud_core.lib(imagwebp.obj) : error LNK2001: unresolved external symbol WebPDemuxGetI
[build] wxwebpd.lib(picture_csp_enc.obj) : error LNK2001: unresolved external symbol SharpYuvGetConversionMatrix
[build] wxwebpd.lib(picture_csp_enc.obj) : error LNK2001: unresolved external symbol SharpYuvConvert
[build] wxwebpd.lib(picture_csp_enc.obj) : error LNK2001: unresolved external symbol SharpYuvInit
This integration of WebP ist IMHO inconsistent with the rest of wxWidgets, I would suggest following changes:
wxwebpshould obeywxBUILD_USE_STATIC_RUNTIMEwxwebpshould not be required by default, i.e.wxUSE_LIBWEBP=OFFshould be default at least in static buildswxUSE_LIBWEBP=builtinshould have the same meaning aswxUSE_LIBPNG=builtin, i.e. no external libraries should be used
Platform and version information
- wxWidgets version you are building: 3.3.2
- wxWidgets port you are building: wxMSW
- OS and its version: Windows 10 LTSC
- Compiler being used: MSVC 2022
- Non-default compiler options, if any :
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26428)Thanks for reporting the problem but I don't understand the part about using COMPONENTS webp core — surely this is not right, you don't use png or jpeg in COMPONENTS, so why should you use webp?
Static runtime issue should be fixed, of course, and I think this is still relevant for master, the only change since 3.3.2 that I see is b17a03d and it doesn't seem to fix this.
And the builtin value of the option should, of course, work as for the other libraries too.
But I don't think we should disable WebP support by default.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#26428)It seems that unlike other similar built-in 3rd party libraries, build/cmake/lib/webp.cmake for some reason does not call wx_add_builtin_library().
The function sets up many target properties (via wx_set_common_target_properties()), including MSVC_RUNTIME_LIBRARY when wxBUILD_USE_STATIC_RUNTIME is ON.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
hatelamers
hatelamers left a comment (wxWidgets/wxWidgets#26428)Thanks for reporting the problem but I don't understand the part about using
COMPONENTS webp core— surely this is not right, you don't usepngorjpeginCOMPONENTS, so why should you usewebp?
Sure thing.
Yeah, the find_package issue is most probaly caused by the version of FindwxWidgets.cmake that MS ships, it confused things a bit. I'm going to replace it with the newest one from gitlab.kitware.com and give it a try. This problem didn't look that important to me anyway, if the latest FindwxWidgets fixes that, I will edit the issue description acc.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
hatelamers
hatelamers left a comment (wxWidgets/wxWidgets#26428)The earliest version of CMake with FindwxWidgets.cmake that recognizes wxwebp is 4.2.0, I'm going to update VS LTSC and report.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
PB
PBfordev left a comment (wxWidgets/wxWidgets#26428)I believe that it is pretty clear that this is not a CMake problem (version or find-mode related) but wxWidgets problem.
As I already wrote, it seems the issue is there because when building wxWidgets, the webp libraries do not take into account wxBUILD_USE_STATIC_RUNTIME setting, they always use the dynamic CRT.
This means one cannot even build all samples with wxBUILD_USE_STATIC_RUNTIME turned on. Doing this
cmake -G "Visual Studio 18 2026" -DwxBUILD_SHARED=OFF -DwxBUILD_USE_STATIC_RUNTIME=ON -DwxBUILD_SAMPLES=SOME -S ../wxWidgets-GIT -B .
cmake --build . --config Debug
when compiling the widgets sample (the other fundamental samples are fine) results in warnings such as
LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library [D:\Dev\Desktop\Lib\w
xWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
LINK : warning LNK4286: symbol '_wassert' defined in 'libucrtd.lib(assert.obj)' is imported by 'wxsharpyuvd.lib(sharpyuv_csp.o
bj)' [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
LINK : warning LNK4286: symbol '_wassert' defined in 'libucrtd.lib(assert.obj)' is imported by 'wxsharpyuvd.lib(sharpyuv_dsp.obj)' [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
LINK : warning LNK4217: symbol '_wassert' defined in 'libucrtd.lib(assert.obj)' is imported by 'wxsharpyuvd.lib(sharpyuv_gamma.obj)' in function 'Log10f' [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
LINK : warning LNK4217: symbol '_wassert' defined in 'libucrtd.lib(assert.obj)' is imported by 'wxwebpd.lib(huffman_encode_utils.obj)' in function 'VP8LCreateHuffmanTree' [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj
and errors
wxsharpyuvd.lib(sharpyuv_gamma.obj) : error LNK2019: unresolved external symbol __imp_expf referenced in function ToLinearHlg
[D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
wxsharpyuvd.lib(sharpyuv_gamma.obj) : error LNK2019: unresolved external symbol __imp_logf referenced in function FromLinearHl
g [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\lib\vc_x64_lib\widgets.exe : fatal error LNK1120: 2 unresolved externals [D:\Dev\Desktop\Lib\wxWidgets-GIT-build-vc18_x64-staticCRT\samples\widgets.vcxproj]
Tested with CMake 4.3.2 and the latest versions of MSVS 2022 and 2026 Community.
BTW, @hatelamers, if you build wxWidgets with CMake, I believe you are better off using the CONFIG mode instead of the default module mode in your find_package(wxWidgets ...) call. This won't help you here but I will free you from depending on the findwxWidgets module shipped with CMake, which can be outdated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
hatelamers
hatelamers left a comment (wxWidgets/wxWidgets#26428)@PBfordev, you are right of course that link conflicts are not CMake related but I mixed the 2 problems into the issue description, thus I will re-formulate that there
BTW, the newest CMake available with VS 2022 17.12 LTSC is 3.29.5, VS 2022 17.14 has 3.31.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#26428)They are indeed two different problems. The first one is about CMake's FindwxWidgets not adding the libwebp libraries (webp webpdemux sharpyuv) to the list of libraries to link with.
And can be worked around by using CONFIG mode (if wxWidgets is built and installed with CMake so the config files are available), or by using a newer CMake version.
The other problem is not setting the correct properties because we use libwebp's own build system instead of wx_add_builtin_library.
Adding wx_set_builtin_target_properties(${target_name}) for all the webp targets might work. When I add it, it throws an error when linking thread libraries to it but I can work around that. It sets some, maybe unwanted, properties like the output directories.
I need to test if this causes problems.
And test all the different build variants.
And test if exporting/installing all webp targets instead of only the 3 required ones causes problems.
build/cmake/functions.cmake | 6 +++++- build/cmake/lib/webp.cmake | 9 +-------- 2 files changed, 6 insertions(+), 9 deletions(-) diff --git a/build/cmake/functions.cmake b/build/cmake/functions.cmake index 33e03516749..ed64979c3c2 100644 --- a/build/cmake/functions.cmake +++ b/build/cmake/functions.cmake @@ -274,7 +274,11 @@ function(wx_set_common_target_properties target_name) endif() if(wxUSE_THREADS) - target_link_libraries(${target_name} PRIVATE Threads::Threads) + set(LIB_VISIBILITY PRIVATE) + if (${target_name} MATCHES ".*webp.*") + set(LIB_VISIBILITY) + endif() + target_link_libraries(${target_name} ${LIB_VISIBILITY} Threads::Threads) endif() wx_set_source_groups() diff --git a/build/cmake/lib/webp.cmake b/build/cmake/lib/webp.cmake index 4ce6b0580f1..1e65e24c687 100644 --- a/build/cmake/lib/webp.cmake +++ b/build/cmake/lib/webp.cmake @@ -63,6 +63,7 @@ if(wxUSE_LIBWEBP STREQUAL "builtin") get_property(webpTargets DIRECTORY "${WEBP_ROOT}" PROPERTY BUILDSYSTEM_TARGETS) foreach(target_name IN LISTS webpTargets) + wx_set_builtin_target_properties(${target_name}) wx_set_builtin_target_ouput_name(${target_name} "wx${target_name}") set_target_properties(${target_name} PROPERTIES FOLDER "Third Party Libraries/WebP" @@ -72,12 +73,4 @@ if(wxUSE_LIBWEBP STREQUAL "builtin") set(WebP_LIBRARIES webp webpdemux sharpyuv) list(APPEND wxLIB_BUILTIN_TARGETS ${WebP_LIBRARIES}) - - if(NOT wxBUILD_SHARED) - wx_get_install_platform_dir(archive) - wx_install(TARGETS ${WebP_LIBRARIES} - EXPORT wxWidgetsTargets - ARCHIVE DESTINATION "${archive_dir}" - ) - endif() endif()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
hatelamers
hatelamers left a comment (wxWidgets/wxWidgets#26428)Description is updated. Any suggestions, additions?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Maarten
MaartenBent left a comment (wxWidgets/wxWidgets#26428)With #26456 the libwebp libraries should now have all the correct build properties.
This integration of WebP ist IMHO inconsistent with the rest of wxWidgets
It is the same as all the other built-in libraries (jpeg, png, zlib, ...), they all require linking with their static libraries. But these other libraries have been there for decades so FindwxWidgets in any CMake version will include them in the link list.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.