I have simple question related to LIB command I have one sum.cpp file which contains one function add(int,int).
Now library name a.lib depends on sum.obj file and one another library name b.lib which depends upon a.lib and sum.obj
so scenario is
a.lib: sum.obj
b.lib : sum.obj a.lib
everything works fine but my doubt is why lib command not issuing duplicate warning or error.
Related
I have a situation where I need to load a DLL (libcocotb.dll) at runtime (using LoadLibrary) from another DLL (libembed.dll) that exists in the same directory. These DLLs are not in the same directory as the application.
> tree
.
├── ...
├── libcocotb.dll
└── libembed.dll
Specifying just the library name LoadLibrary("libcocotb.dll"), did not find the library. LoadLibrary(".\\libcocotb.dll"), did not find the library. Adding the directory to the PATH seems like the wrong answer, and I would need to determine the location of the directory at runtime since the binaries need to be relocatable (they are going in a Python wheel at the end of the day).
On Linux, I can just add $ORIGIN to the RPATH of the loading DLL. Is there nothing similar on Windows? I am not very familiar with Windows loader and library system.
One way to do it in Windows is:
save the HMODULE of libembed.dll when it gets loaded, which is passed as the first argument to its DllMain entry point;
later, when preparing to load the other DLL, use GetModuleFileName with the saved HMODULE to get the full path to libembed.dll;
split the libembed.dll filename off the full path, using for example the PathRemoveFileSpec API or the _splitpath CRT function;
combine the resulting directory path with the libcocotb.dll filename to build the full path to the other DLL, using for example PathCombine or _makepath;
use the full path to libcocotb.dll to LoadLibrary the DLL.
I'm following a tutorial on CMake and I have problems understanding the necessity of using the 'include_directories' command at one point.
Let me explain the project first:
In my working directory I have:
- a main.cpp function, a CMakeLists.txt(the main one), a configuration file, a 'MathFunction' directory and a 'build' directory
In the MathFunction directory I have:
- a CMakeLists.txt file that will be invoked by the main one
- A file 'mysqrt.cxx' that contains the implementation of a function which will be used in 'main.cpp' application
- A 'MathFunctions.h' header file that contains the prototype of that function
In the CMakeLists from 'MathFunction' directory I'm creating a library using code from 'mysqrt.cxx' like this:
add_library(MathFunctions mysqrt.cxx)
This snippet is a part of my main CMake code:
# add the MathFunctions library?
#
if (USE_MYMATH)
include_directories ("${PROJECT_SOURCE_DIR}/MathFunctions") # WHY DO WE NEED THIS
add_subdirectory (MathFunctions)
set (EXTRA_LIBS ${EXTRA_LIBS} MathFunctions)
endif (USE_MYMATH)
add_executable(Tutorial tutorial.cxx)
target_link_libraries (Tutorial MathFunctions)
Now I do not understand why I need too add that 'include_directories' command in order to use the library? Shouldn't it be enough that the last command 'target_link_libraries' links the already created executable and libraries togheter so there would be no need to also include_directories?
Thank you for reading and I'm sorry if I have not explained it very well but I hope you will understand what I mean :D
Command include_directories sets directories for header files (.h) to be searched. Linking (target_link_libraries) with a library basically specifies only a library file (.so, .dll or other type). As you see, these are different things.
When linking executable with a library target, CMake propagates (more precisely, "consumes") some properties of that library target to the executable. Among these properties there is INTERFACE_INCLUDE_DIRECTORIES property, which adds include directories to the executable.
So, when a library target has INTERFACE_INCLUDE_DIRECTORIES property correctly being set, you don't need to explicitly specify include directories for executable:
MathFunctions/CMakeLists.txt:
add_library(MathFunctions mysqrt.cxx)
# Among other things, this call sets INTERFACE_INCLUDE_DIRECTORIES property.
target_include_directories(MathFunctions PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
CMakeLsits.txt:
add_executable(Tutorial tutorial.cxx)
# This also propagates include directories from the library to executable
target_link_libraries (Tutorial MathFunctions)
Note, that using simple
# This *doesn't* set INTERFACE_INCLUDE_DIRECTORIES property.
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
in MathFunctions/CMakeLists.txt doesn't imply propagating include directories to the linked executable.
Using CMake I'm able to cross-compile and create a static library which depends on other static libraries. However, the resulting static library doesn't include the "content" of the other static libraries. Therefore, I want to create an archive, i.e. a static library, that actually includes everything (all the object files).
To this aim, I've tried to use the following directive in CMakeLists.txt:
add_custom_target(combined ALL COMMAND ${CMAKE_AR} rc libcombined.a $<TARGET_FILE:target1> $<TARGET_FILE:target2> $<TARGET_FILE:target3>)
CMAKE_AR is set to an absolute path where my cross-compiler(archiver?) is; its values is something like: c:/arm/arm-none-eabi-ar.exe
However, when I try to build the project (make && make install), I receive the following error:
'..' is not recognized as an internal or external command, operable program or batch file.
make[2]: *** [src/CMakeFiles/combined] Error 1
If I open the build.make file where the src/CMakeFiles/combined is, I have something similar to this:
src/CMakeFiles/combined:
cd absolute-path-to-the-build-folder/src && ../../relative-path-to-the-archiver-executable/arm-none-eabi-ar.exe rc libcombined.a absolute-path-to-target1-archive absolute-path-to-target2-archive absolute-path-to-target3-archive
If I manually replace the relative path to the archiver executable with the absolute path, the new archive is created correctly. The same happens if I just add quotes in the specified archiver path.
At this point, I think it might be something related to Windows and/or to the make utility which doesn't interpret correctly the command/path.
Therefore, I have the following question:
Why is the CMAKE_AR value converted to a relative path from an absolute path?
How can I solve this without involving external scripts?
About last point, I tried to escape the CMAKE_AR path with quotes, but then I get the error: "COMMAND may not contain literal quotes".
What you want to do is create an object library that depends on your various static libraries in order to get a single library that contains all the dependencies.
I have a CMake setup to link together 4 static libraries and 1 shared one into a top level shared library (Let's call it Top.dll). This will work fine except for one thing. I have a module definition file that expresses which symbols should be public. Top.dll builds and so far so good.
Now when I try to link an executable with Top.dll via CMake I get linker errors for every public symbol claiming it is defined in two places (Top.dll and the static library in which it was actually defined) even though Top.dll contains no original definitions of its own. If I remove the static library then as expected I get unresolved symbol errors. If I remove the module definition file, I get the same. It seems like it is either there zero times or twice. Is there some setting I am missing here? I don't think I'm using CMake in a non-basic way...
UPDATE An explanation via CMake
# setup the lib
add_subdirectory(vendor/A) #shared library
add_subdirectory(vendor/B) #static library
add_subdirectory(vendor/C) #static library
add_library(Top SHARED ${ALL_SRC_FILES})
target_link_libraries(Top A B C)
set_target_properties(Top PROPERTIES LINK_FLAGS
"/def:${PROJECT_SOURCE_DIR}/definitions.def") #contains symbols from B
add_subdirectory(C/Tests)
# CMakeLists.txt from C/Tests
add_executable(Tests ${SRC_FILES})
target_link_libraries(Tests Top)
The above is simplified, but I will get errors like the following at the point that the C/tests project is compiled:
B.lib(xxx.obj) : error LNK2005: _ABC already defined in Top.lib(Top.dll)
If I remove B.lib from the target_link_libraries call, then as expected I get unresolved symbols. If I remove the /def line, same result.
I've been able to get around this by setting the target_link_libraries of B and C to private. This may or may not be the correct solution and I will wait for other answers. If I don't do this it appears that the dependency is carried up to the final executable (So it links to both Top.dll and B.lib, etc).
I recently decided to organize the files in my project directory. I moved the parsers I had for a few different file types into their own directory and also decided to use ocamlbuild (the as the project was getting more complicated and the simple shell script was not sufficient any longer).
I was able to successfully include external projects by modifying myocamlbuild with some basic rules (calling ocaml_lib, I'll use ocamlfind some other time), but I am stuck on how to include the folder as a module into the project properly. I created a parser.mlpack file and filled it with the proper modules to be included (eg, "parser/Date", et cetera), wrote a parser.mli in the root of the directory for their implementations, and modified the _tags file (see below).
During the compilation, the parser directory is traversed properly, and parser.cmi, parser.mli.depends were both created in the _build directory; as well as all *.cm[xio] files in the parsers subdirectory.
I feel I might be doing something redundant, but regardless, the project still cannot find the Parser module when I compile!
Thanks!
_tags
debug : true
<*.ml> : annot
"parser" : include
<parser/*.cmx>: for-pack(Parser)
<curlIO.*> : use_curl
<mySQL.*> : use_mysql
<**/*.native> or <**/*.byte> : use_str,use_unix,use_curl,use_mysql
compilation error
/usr/local/bin/ocamlopt.opt unix.cmxa str.cmxa -g -I /usr/local/lib/ocaml/site-lib/mysql mysql.cmxa -I /usr/local/lib/ocaml/curl curl.cmxa curlIO.cmx utilities.cmx date.cmx fraction.cmx logger.cmx mySQL.cmx data.cmx project.cmx -o project.native
File "\_none\_", line 1, characters 0-1:
Error: **No implementations provided for the following modules:**
Parser referenced from project.cmx
Command exited with code 2.
You'll notice -I parser is not included in the linking phase above; actually none of the parser related files are included!
edit: Added new details from comments and answer below.
You need to "include" the parser directory in the search path. You can do this in _tags:
"parser": include
Then ocamlbuild can search the parser directory for interesting files.
I wonder if parser.mli is somehow interfering with the dependencies in processing the mlpack file. parser.cmi will be generated from the pack operation when parser.mlpack is processed and compiled. Try building with the parser.mli file removed. If that works, then this can be re-processed into a real answer.
Also, you don't need parser/ as a prefix to your modules in parser.mlpack if parser.mlpack is in the parser directory and you have the include tag set. But that shouldn't make a difference for this.
Update: this worked around the problem, but wasn't the root cause. Root cause, per comment below, was a file mentioned in the .mlpack that had been relocated.