I want to use the ctfconvert and ctfmerge in CMake. I went through couple of links below.
https://java.net/projects/solaris/sources/on-src/content/usr/src/tools/scripts/nightly.sh
http://lethargy.org/~jesus/writes/mdb-ctf-dwarf-and-other-angelic-things/#.V-JUFPl97X4
The source in links states that we need to create object file of the source and then apply ctfmerge and ctfconvert over that. I came to know that there is a facility to create OBJECT library in CMake. But I am not getting how to apply these ctfconvert and ctfmerge on OBJECT libraries as $<"TARGET_OBJECTS:objlib> can only be used in add_library() or add_executable().
How to solve this issue?
We need to install onbld package on Solaris 11 or need to build Solaris 10 source code to get onbld package to install ctf binaries.
Then ultimately need to call ctf binaries in CMakeList.txt to run. We need to create a object file from ctfconvert binary and then need to use ctfmerge when we create an executable/shared library to merge the obhect file containing ctf header information to newly created executable/shared library.
If we need to create static library, we just need to use ctfconvert over the file to create the object file containing ctf header which will put those files in archive. When we use this static library in creation of executable/shared library, at that time, we need to use ctfmerge over each object file from static library.
Related
I am creating a cmake package config file (a Foo-config.cmake) for a pre-existing .dll not created by cmake.
The annoying thing is that the .dll depends on some data files.
When a user consumes my package in his own cmake project, I want the INSTALL target to install both the .dll and data files to his specified install location. I don't want him to have to write extra install() rules to do that.
Is it good practice to write the install() rules directly in my Foo-config.cmake? Or is there a better way to do this, maybe with set_target_properties()? I just couldn't find the appropriate property for associating arbitrary file dependencies to a target.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake, or is there something in cmake that can automatically generate it for me to achieve the same thing?
FWIW the .dll is an internal legacy library and is normally built by Visual Studio and uploaded in a .zip file to our internal artifactory. I want us to migrate away from manually pulling down .zip files from artifactory and manually integrating the files into Visual Studio projects.
I've since found that there are a couple different ways to do this:
In the config file, simply create one or more variables for the files/dirs you want to install. Then install those using install(FILES) and/or install(DIRECTORY). More info: https://stackoverflow.com/a/46361538/189341
Use file(GET_RUNTIME_DEPENDENCIES). More info:
https://discourse.cmake.org/t/installing-a-pre-built-module-and-its-various-dependencies/5227
How to use cmake file( GET_RUNTIME_DEPENDENCIES in an install statement?
Is it good practice to write the install() rules directly in my Foo-config.cmake?
No.
From 480 *-config.cmake and *Config.cmake files on my system none calls install().
Or is there a better way to do this, maybe with set_target_properties()?
No.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake
No. This is unrelated to if you create a .dll or not. If .dll exists, there is no need to create Foo-config.cmake anyway. It is your choice that you want to (or make users to) use find_package.
is there something in cmake that can automatically generate it for me
No.
If you don't intent to support find_package features - VERSION OPTIONAL_COMPONENTS PATHS HINTS CONFIGS etc. - then just go with include(). find_package is just include() with some extra options.
If you want to have install() in your find_package, then just protect it with a variable, like if (FOO_DO_INSTALL) install(....) endif().
I am trying to integrate the Refinitiv Real-Time SDK into my own application.
I have downloaded the source code and built the libraries.
Typically you would then expect there to be an INSTALL target, which would install the libraries and headers into some location, and then, if we're lucky, a find_package module which we can later use to import the library targets into our own project.
Unfortunately, neither of these are provided.
How then, to import the libraries and their header files into my project?
ExternalProject_Add
I do not want to use the standard ExternalProject_Add to download and build the source code every time I reconfigure my project. (In particular because our CI server will have to do this for every single build.) Rather I want to build it once (and make it part of the CI server's docker image), and then link against the libraries / include the header files directly from where I've copied the source.
add_library INTERFACE
I know that I can create a new INTERFACE library target
find_library(LIB_EMA ema ${REFINITIV_BINARY_DIR})
find_library(LIB_ETA eta ${REFINITIV_BINARY_DIR})
# etc.. for all the refinitiv libraries
add_library(refinitiv INTERFACE)
target_link_libraries(refinitiv INTERFACE
${LIB_EMA}
${LIB_ETA}
# etc...
)
target_include_directories(refinitiv INTERFACE
${REFINITIV_SOURCE_DIR/Ema/Include
${REFINITIV_SOURCE_DIR/Eta/Include
# etc...
)
This is, however, tedious and prone to breaking whenever Refinitiv releases a new SDK version and decides to change a path or link dependency etc
Question:
What I would to do is use their CMakeLists.txt file, but only to access the already-built targets, not to build them as part of my build.
Is this possible?
Let's say I want to build a simple windows exe that does HTTP requests with curl.
( See example: https://github.com/JetBrains/kotlin-native/tree/master/samples/curl ).
The example above works, but in order for the exe to run, it needs to find libcurl-4.dll, either in the local dir, or e.g. in the installation dir ( e.g. C:\msys64\mingw64\lib ).
I would like to ship just the exe file, without having to provide the dll files separately. Is it possible to build the exe file with all the things it uses from the library (and transitive dependencies...) bundled into the exe file?
(This question is about if I can do this with a Kotlin 1.3.61 Native project, and how.)
I'm studying Kotlin too and it took many hours until I realize how to handle def file, includes and static library.
I made an example of how to use static library (curl with gzip and SSL support compiled with mingw) on kotlin-native. This way you dont need to dll files to be supplied with your app
https://github.com/carlosrafp/Libcurl-Kotlin-Native-standalone
On libcurl.def file you can see:
headers = curl/curl.h // path to curl header
libraryPaths = src/nativeInterop/cinterop // path to your static library
staticLibraries = libcurl.a // the static library
linkerOpts.mingw = -lws2_32 -lwldap32 // linking dependences
I based on the nice post of jonnyzzz:
https://jonnyzzz.com/blog/2018/10/29/kn-libcurl-windows/
You need to build the static libraries using mingw (libcurl, gzip) and msys2/mingw(openssl) to use with kotlin-native compiler
You can definitely do this for a static library(see this), but not for the .dll. About the shared library bundling, I would just recommend you to see this question. It's about the same but a bit generalized.
I download a autotrace library to use in my java project but it contains only (libautotrace.a, libautotrace.la, libautotrace.dll.a and header)
my question: is it possible to convert libautotrace.dll.a to dll library?
You can not.
The dot-a files you have were compiled for a Unix system, and can not be directly converted to a Windows format.
You will need to find a windows-native build or the source code to build it yourself.
I'm trying to use a open source library from a Windows application, and the only pre-built version I can find comes as a file called "lib.dll.a"
What format is this, and can I convert it to a normal dll file?
Naming the output file libjvm.dll.a will allow gcc to recognize it as a
library named jvm. The .dll.a suffix indicates (by convention) that it is
an import library, rather than a static library (which would simply be named
libjvm.a, again by convention).