I have the following problem:
I need to build a static library (.lib) that can be provided with other source code in such a way that the project can be linked with it. However when I build the library in release mode, the build generates .pdb files and has full paths to them baked into the final .lib itself, making it unusable.
I don't necessarily care if it generates .pdb or not, but what setting should I change in the .vcxproj to make sure that the final release .lib doesn't require (or insert) absolute paths for those .pdbs?
Related
I have the following problem, I have a separate cmake project that generates c++ files and I want to glob them into a library that uses them. Right now this is done in this manner
add_subdirectory(generator)
add_custom_target(run-generator ... byproduct GENERATED_FILES)
include(files.txt)
target_link_libraries(library ${GENERATED_FILES})
The include files.txt is actually a set(GENERATED_FILES all_autogen_files), right now they're fixed but in the future they might change. That is what I would want to have is something like
add_subdirectory(generator)
execute_process(generator_binary ... commands)
file(glob ${GENERATED_FILES} output_location_of_gen_files)
target_link_libraries(library ${GENERATED_FILES})
As I understood execute_process runs on the spot is read, so this would generate all the files before the file(glob) but I don't know how would I go about actually building the generator binary before the execute process, since right now what builds it before is that it is a dependency on the target_link_libraries
The only way this could possibly work is if you create a superbuild, i.e. a CMake project that builds everything with ExternalProjects. The reason is that you can't create new targets or add sources to existing targets during the build.
With a superbuild you need at least 3 separate CMake projects: One that builds the generator and then generates the files, one that globs the generated files and builds the rest of your build artifacts, and the superbuild project that adds both with ExternalProject_Add. By setting the dependencies correctly you can then ensure that the project that uses the generated files is configured after the generating project has been built.
However, globbing in CMake is discouraged anyway, so listing the files explicitly is the proper way to do it. If your code-generator starts generating new files then they should be added to the list manually in the same commit, as otherwise even with CONFIGURE_DEPENDS it is not guaranteed that the new files will be built when using globbing and the ExternalProject approach.
TL;DR
How do I configure CMake and Emscripten to build my static library to produce a WASM and JS bootstrap file?
I have a static library being built with CMake that I want to build as a WASM library (and JS bootstrap) using Emscripten. Simply using the Emscripten CMake toolchain and adding the appropriate compiler/linker flags result in only a .a file being built - even if -o <project name>.js is added to the compiler and/or linker flags.
The reason is that because I've told CMake I want a static library, it uses CMAKE_AR to build. CMAKE_AR (if undefined) is defined as emar in the Emscripten toolchain file, and emar cannot produce .wasm and .js output.
I have tried creating a new executable target that has a dependency on the library, and otherwise just sets up the compiler/linker settings. However this causes a CMake error, because I've defined an executable target that has no source files (they're associated with the library target). If I add a stub main file, I get an Emscripten warning:
system_libs:WARNING: main() is in the input files, but "_main" is not in EXPORTED_FUNCTIONS, which means it may be eliminated as dead code. Export it if you want main() to run.
I could get round by adding an empty file to exe source file list (probably, I haven't tried), but this feels very much like a hack.
You are correct in that you need to create an executable target in order to produce a .wasm file.
If cmake insists on you creating a dummy source file because it doesn't understand that all the code for your program can come from libraries then I guess you that is your best option.
See CMake: Is it possible to build an executable from only static libraries and no source? for how to work around this limitation of cmake.
I have a problem building multiple Fortran-90+ executable targets using CMake, when I use Fortran modules that are shared by all executables, and build in parallel using make -j. The issue seems to be that the compiled object files are placed in different subdirectories for each target, CMakeFiles/targetName.dir/src/file.f90.o, while the module files are placed in the same directory for every target (I can change this directory by setting Fortran_MODULE_DIRECTORY, but it will still be the same dir for all module files). The problem is then that all targets start writing these module files in parallel, and I get a
Fatal Error: Can't rename module file 'module.mod0' to 'module.mod': No such file or directory
when using gfortran (which apparently creates a .mod0 file and then renames it to .mod). The problem does not arise when I issue make without the -j option (serial build).
I can see two solutions, but I don't know how to implement them. Firstly, put the object files for all targets in the same directory rather than target-specific directories. This may be the preferred option, since I won't have to compile the shared source files N times for N targets. The make process will then recognise that the object files exist, and not compile the corresponding source files again, hence not touching the .mod(0) files again (I may need to make all following targets depend on the first).
The second solution would be to put the .mod(0) files in the target-specific directories, so that they are not overwritten or removed by the other targets. This would solve my problem, even though it would still involve more compiling than necessary. I have no idea how to accomplish either option, so any hint there or alternative solution is welcome.
The answer I was looking for was provided in the comments to the question by #RaulLaasner:
I would create an additional target in the form of a core library of the relevant source files, which can then be linked to all executables. This should work in parallel. The mod files can still be in put into a single directory.
I used add_library() and target_link_libraries() to achieve this.
Note that e.g. Gentoo ebuild scripts add --as-needed to the linker, which may cause undefined references in your core library when you link it and external libraries to form the executable. To prevent this, make sure you link the external libraries to your core library first. To this end, my CMakeListst.txt contains:
add_library( "Core" STATIC src/functions.f90 src/routines.f90 ) # creates libCore.a
target_link_libraries( Core ${EXTERNAL_LIBRARIES} ) # link external libraries to libCore.a
...
add_executable( myProgram1 src/myProgram1.f90 ) # creates the first executable
target_link_libraries( myProgram1 Core ) # links libCore.a to myProgram1
The last two lines can be repeated to build the other executables (e.g. using foreach()).
IDE: VS2005
Say I am using Poco library and the executable needs below dlls. I have to put them in same directory where the executable is.
msjava.dll
msvcp80.dll
msvcr80.dll
PocoFoundation.dll
PocoNet.dll
Is there any way that can build a dll-free executable? Thanks.
They don't have to be in the same directory. They can be in another directory if your PATH variables includes the directory they are in.
It looks like the Poco libraries can be downloaded as source, so you should be able to build them as static libraries and make a stand alone executable.
Update
For the msvc DLL's, you can build against static libraries. Bring up the properties of your project, go to C/C++, Code Generation and modify "Runtime Library". Make sure to choose a library other then "Multi-threaded DLL" or "Multi-threaded Debug DLL." You will also want to make sure you do that for the Poco libraries as well.
I got a .h file, two .lib files, a .dll file and a tiny test project from a hardware vendor to talk to their hardware.
Compiling and running their test project works just fine. Noteworthy: they don't use the .dll. I can throw the dll-directory and all of it's content away, everything works just fine.
To start things off I simply copied the communication parts of their code (connect, disconnect and send a command) into my project. This is actually all that you can do. I have included the .h file and pointed to the directory containing the .lib files. Just like in the tiny test project. It all compiles, but when I try to run the project complains that it is missing the .dll file.
Can anybody explain what is happening? How are libs and dlls supposed to work?
All of this is on windows, VS2005. I compared the .vcproj files and could not find any significant differences.
The test project is statically linked - the lib is included in the exe.
Your project is dynamically linked - the dll is referenced and therefore needed at runtime.
See this Stack Overflow question for more information.
Basically the answer depends on whether you are going to use static or dynamic linking for your executable.
With static linking, you need the .h and .lib files but not the .dll files to compile and link. Your executable will be larger but you won't need any of the .h/.lib/.dll files during runtime.
With dynamic linking, you just need the .h files to compile and link. Your executable will be smaller but you will need one or both of the .dll files during runtime.
For a more detailed treatment of this from the Visual Studio perspective, check out http://msdn.microsoft.com/en-us/library/1ez7dh12.aspx -
"Dynamic linking differs from static linking in that it allows an executable module (either a .dll or .exe file) to include only the information needed at run time to locate the executable code for a DLL function. In static linking, the linker gets all of the referenced functions from the static link library and places it with your code into your executable."