[question] Defining shared libraries windows

[chfuerst]

What is your question?

Hi! I have a question regarding definition of a conan recipe for a shared library.

We've purchased a third party library, where we only get delivered a *.dll File in windows.

Is my understanding correct, that when defining package info

self.cpp_info.components["compname"].libs = ["name"]

Conanv2 assumes that in the "lib" directory there is a file named "name.lib" and in the "bin" directory there is "name.dll" in windows? If so, what is the appropriate way of defining "only" the shared library "name.dll" ? Might also related to https://github.com/conan-io/conan/issues/16926

BR, Christoph

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @chfuerst

Thanks for your question.

self.cpp_info.components["compname"].libs = ["name"]

Indeed, this serves to define "linkable" libraries. In windows it means that it should have a "import" library such as mylib.lib. For runtime only components, it would be something like:

• Leave the .libs field empty
• Make sure to define the .bindirs = ["mybindir"] (the default is bin, if you put that .dll in the "bin" dir, that would be enough)
• If there are no headers, invalidate include dirs with .includedirs = []
• If this library is not intended to be located by CMake (generally the case), you can define self.cpp_info.set_property("cmake_find_mode", "none")
• The package_type should probably be package_type = "shared-library"

Please try that and let us know.

[chfuerst]

Thank you @memsharded for your quick feedback. I am working on the topic; I indeed need the CMake interface, and i am in the process of analyzing the generated FindFiles; If the dll files are only needed at runtime, but not at linking time, i will need to create a cmake build module with the necessary install commands.

Working on this, give the final feedback by begin / mid of next week.

BR, Christoph

[chfuerst]

Hello again -

During my analysis, i found, that i have a certain include directory, and there are some functions implemented in the header and that the shared libraries were not actually used for linking but are dynamically loaded (with dlopen / LoadLibrary) at runtime.

My solution to problem was that i implemented a cmake_build_module that installs the so-files that are needed at runtime but not for linking.

The cmake_build_module is on global scope available,

self.cpp_info.set_properties("cmake_build_modules", ["custom_script1.cmake", "custom_script2.cmake"])

but are not available on component level. Is this intended?

BR, Christoph

PS.: Ticket can be closed.

[memsharded]

My solution to problem was that i implemented a cmake_build_module that installs the so-files that are needed at runtime but not for linking.

Just in case, there are some tools that can help to gather or locate things for runtime:

• The VirtualRunEnv generator will create a environment script that can be sourced or activated with paths to locate the dlls. In the case of Windows, it will define the PATH env-var
• The deployers can do copies from inside conan packages to the user folders, for final deployment outside of Conan.

self.cpp_info.set_properties("cmake_build_modules", ["custom_script1.cmake", "custom_script2.cmake"])

Yes, the cmake_build_modules only work at the package level, not at the component level, because this works by doing an include() from the pkg-config.cmake, and this cannot be done conditionally to components.

I am closing the ticket as you suggested, but don't hesitate to re-open or create new tickets for any further question or issue. Thanks very much for your feedback!