vcpkg (silently) links wrong libraries

[Neumann-A]

There are at least two cases where vcpkg (silently) links the wrong libraries:

a) Due to VcpkgAutoLink
related issue: #5485 (comment)

b) Due to CMakeToolchain vcpkg.cmake
cmake find_package links debug libraries instead of release libraries in release mode.
related issue: #4606
I encountered b) while using find_package with LAPACK and OpenBLAS (This one is extremely nasty for consuming packages. Performance of release builds is thus probably bad)

(Issue opened for better search result and hopefully fixing ASAP ;) )

for b) it is probably wise to replace <PackageName>_LIBRARIES with a general generator expression something like:

        if(${${name}_LIBRARIES})
            set(${name}_LIBRARIES_DEBUG ${${name}_LIBRARIES})
            STRING(REPLACE "debug/" "" ${name}_LIBRARIES_RELEASE "${${name}_LIBRARIES}")
            set(${name}_LIBRARIES "$<$<CONFIG:Debug>:${${name}_LIBRARIES_DEBUG}>;$<$<CONFIG:RELEASE>:${${name}_LIBRARIES_RELEASE}>")
        endif()

added to vcpkg.cmake @ 254ff (in the else block of the find_package macro)

(same for _INCLUDES/_INCLUDE_DIR and others.... )

[matra774]

I can reproduce this problem with libdb38.lib, which uses the same library name for debug and release version

[Neumann-A]

closed by #5543. Wrong library linkage will throw an error

[hajokirchhoff]

I agree with other posters here that the current way of VcpkgAutoLink under MSBuild is very problematic. VcpkgAutoLink adds each and every one lib in the vcpkg-triplet lib directory as a dependency to the linker. I just spent over two hours debugging a very hard to find runtime problem.

Our application uses python 2.7 and links against python27.lib. This lib is explicitly given in our Visual Studio solution project. I recently added vcpkg boost to my system. As a result, the application suddenly tries to load python38.dll instead of python27.dll.

The reason is that the boost library has a submodule boost-python, which has python 3.7 as a dependency. As a result, vcpkg builds python and creates a python37.lib in its lib directory. Our application does not even use boost-python, there is absolutely no dependency to python 3.7 anywhere. But simply because python37 is part of the boost vcpkg package, it is force linked to our application.

Basically what VcpkgAutoLink does is change our linker command from

link someobj.obj python27.lib

to

link someobj.obj vcpkg*.lib python27.lib

That is, IMHO, a really, really bad idea. Boost is a very large collection of (very good) libraries. I use them all the time. But I usually have no idea and don't care, what other libs they depend on. VcpkgAutoLink forces all other libs on me, even if I don't use the corresponding boost library.

Or consider openssl. My application might use the latest openssl library and link against the most recent libssl.lib with security fixes. Simply introducing any vcpkg package that also uses openssl will link an older library and I will not even notice.

OTOH I cannot simply deactivate VcpkgAutoLink, because then I have to manually link all libraries I use. Which is a hassle in a very large application.

Any ideas?

Regards
Hajo

[JackBoosY]

Is this still exist?

[Neumann-A]

Is this still exist?

Probably. Need to grep through all (-dbg|-rel) logs if some port is still linking (prefix/lib|prefix/debug/lib). The -dbg linkage with prefix/lib is more common than the other way around. You could run a dummy ci check by globbing all -dbg logs and checking for that string

[MonicaLiu0311]

This question should be outdated, I will close it.

[Neumann-A]

This can still happen....

[MonicaLiu0311]

Okay, will remain open.