Including DLL's In VC++(VS2010) Project Output - visual-c++

Disclaimer: Am a C# developer trying to understand a few C++ fundamentals
Have created a command line project which has the .lib of a DLL file linked under Linker > Input > Additional dependencies, and also has the location of the header files specified under C/C++ > General > Additional Include Directories. Ran a build and all compiled okay, with the .exe being built in the Debug/Release dir.
Problem is I also expected the .dll file the project depends on to be there (just like when you add a reference in a .Net project) - but it isn't. When launching the .exe it complains that it can't find the DLL. Fair enough, but why didn't the VC++ put the DLL there if it knows it's required?
And is there a "best practice" to ensuring the dependent DLL files are in the output dir, other than manually copying them there? I have a project that will require use of some third-party libraries, and I was hoping the IDE would help me manage them...
Big thanks for any guidance given!

If you create solution which contains exe and dll, all output files are created in $(SolutionDir) Debug or Release subdirectories, and exe runs successfully. Otherwise, you have one of the following options:
Copy Dll in Post-build step to directory where it is available for loading (usually .exe directory)
Add Dll directory to PATH.

Related

CMake cannot find source file, but file was not specified in CMakeLists.txt, in TFS build definition

I'm porting a large project to linux. I wrote all the CMakeLists.txt files, and everything compiles in my machine.
For whatever reason we still use TFS. The old version, not git with TFS.
I'm working in my own branch, but that branch has no build definition for linux. Before I check in, I want to be sure that everything compiles on the server too. So I need to merge my branch to another one, and submit that shelve set to the build job.
In my machine everything compiles fine. But when I run the build in the server, applying a shelveset to the branch that has a linux build definition, I get an error from the build, saying
CMake Error at
/myproject/subproject/CMakeLists.txt:165 (add_library):
Cannot find source file:
/myproject/subproject/IInternalTransactionManager.h
Tried extensions .c .C .c++ .cc .cpp .cxx .cu .m .M .mm .h .hh .h++ .hm
.hpp .hxx .in .txx
Indeed, that file is not there. Cmake complains about the file not being in the sources directory, which is true, because it is in another directory. But the fact is that I'm not asking for it either! My CMakeFiles.txt file does not include that file. That file is a header which is used in a few files, contains only classes definitions (no implementations), and the directory in which myHeader.h resides has been defined in include_directories. My CMakeLists.txt looks something like this:
set(PROJECT_NAME project)
project(${PROJECT_NAME})
include_directories(
../_include
)
set(source_files
main.cpp
file_that_includes_myHeader.cpp
)
add_library( ${PROJECT_NAME} STATIC ${source_files} )
and my file structure is something like:
/myproject/subproject/main.cpp
/myproject/subproject/file_that_includes_myHeader.cpp
/myproject/subproject/CMakeLists.txt
/myproject/_include/myHeader.h
So, why should cmake complaining about a missing file, if such file is not included in the CMakeLists.txt file? And why would this happen only the build in TFS? My guess is that there is something wrong when applying the shelvetset and is not related to my code, but I cannot prove it.
I compared the code after the shelveset is applyied, and still in that version the CMakeLists.txt does not mention myHeader.h
Or, there is some rule about including headers in CMakeLists.txt files which I'm not aware of.
So, after expending too much debuging I contacted the team in charge of the build process. And as it turns out, the building process in the TFS building definition was definetly NOT what I expected. And of course this was not documented.
Our development is mostly in windows (by far). The linux build has a step before building: a script is launched which parses each Visual Studio project file, gets the included files, and substitutes the source files in the CMakeLists.txt files with the one parsed from VS. Right or wrong, is just the way it is.
I could build the linux build in my local machine because everything was done correctly. The windows build worked too, even though the VS project files sometimes included some files which were not in the source directory but in some header only directory, and somehow that compiled. I guess because the directory was defined in the include directory. But When the CMakeLists.txt files were updated, cmake complained (rightly so) about not finding the files.
So, if anybody experiences similar issues, contact your devops team or whoever is in charge of such things.

Finding my Linux shared libraries at runtime

I'm porting an SDK written in C++ from Windows to Linux. There are other binaries, but at its simplest, our SDK is this:
core.dll - implicitly loaded DLL ("libcore.so" shared library on Linux)
tests.exe - an app use to test the DLL (uses google test)
All of my binaries must live in one folder somewhere that apps can find. I've achieved that on Windows. I wanted to achieve the same thing in Linux. I'm failing miserably
To illustrate, Here's the basic project tree. We use CMake. After I build I've got
mysdk
|---CMakeLists.txt (has add_subdirectory() statements for "tests" and "core")
|---/tests (source code + CMakeLists.txt)
|---/core (source code + CMakeLists.txt)
|---/build (all build ouput, CMake output, etc)
|---tests (build output)
|---core (build output)
The goal is to "flatten" the "build" tree and put all the binary outputs of tests, core, etc into one folder.
I tried adding CMake's "install" command, to each of my CMakeLists.txt files (e.g. install(TARGETS core DESTINATION bin). I then then executed sudo make install after my normal build. This put all my binaries in /usr/local/bin with no errors. But when I ran tests from there, it failed to find libcore.so, even though it was sitting right there in the same folder
tests: error while loading shared libraries: libcore.so: Cannot open shared object file: No such file or directory
I read up on the LD_LIBRARY_PATH environment variable and so tried adding that folder (/usr/local/bin) into it and running. I can see I've properly altered LD_LIBRARY_PATH but it still doesn't work. "tests" still can't find libcore.so. I even tried changing the PATH environment variable as well. Same result.
In frustration, I tried brute-force copying the output binaries to a temporary subfolder (of /mysdk/build) and running tests from there. To my surprise it ran.
Then I realized why: Instead of loading the local copy of libcore.so it had loaded the one from the build output folder (as if the full path were "baked in" to the app at build time). Subsequently deleting that build-output copy of libcore.so made "tests" fail altogether as before, instead of loading the local copy. So maybe the path really was baked in.
I'm at a loss. I've read the CMake tutorial and reference. It makes this sound so easy. Aside from the obvious (What am I doing wrong?) I would appreciate if anyone could answer any of the following questions:
What is the correct way to control where my app looks for my shared libraries?
Is there a relationship between my project build structure and how my binaries must then appear when installed?
Am I even close to the right way of doing this?
Is it possible I've somehow inadvertently "baked" (into my app) full paths to my shared libraries? Is that a thing? I use all CMAKE variables in my CMakeLists files.
You can run ldd file to print the shared object dependencies for file. It will tell you where are its dependencies being read from.
You can export the environment variable LD_LIBRARY_PATH with the paths you want the linker to look for. If a dependency is not found, try adding the path where that dependency is located at to LD_LIBRARY_PATH and then run ldd again (make sure you export the variable).
Also, make sure the dependencies have the right permissions.
Updating LD_LIBRARY_PATH is an option. Another option is using RPATH. Please check the example.
https://github.com/mustafagonul/cmake-examples/blob/master/005-executable-with-shared-library/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
# Project
project(005-executable-with-shared-library)
# Directories
set(example_BIN_DIR bin)
set(example_INC_DIR include)
set(example_LIB_DIR lib)
set(example_SRC_DIR src)
# Library files
set(library_SOURCES ${example_SRC_DIR}/library.cpp)
set(library_HEADERS ${example_INC_DIR}/library.h)
set(executable_SOURCES ${example_SRC_DIR}/main.cpp)
# Setting RPATH
# See https://cmake.org/Wiki/CMake_RPATH_handling
set(CMAKE_INSTALL_RPATH ${CMAKE_INSTALL_PREFIX}/${example_LIB_DIR})
# Add library to project
add_library(library SHARED ${library_SOURCES})
# Include directories
target_include_directories(library PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/${example_INC_DIR})
# Add executable to project
add_executable(executable ${executable_SOURCES})
# Linking
target_link_libraries(executable PRIVATE library)
# Install
install(TARGETS executable DESTINATION ${example_BIN_DIR})
install(TARGETS library DESTINATION ${example_LIB_DIR})
install(FILES ${library_HEADERS} DESTINATION ${example_INC_DIR})

Building SQLite DLL with VS2015

I'm trying to build SQLite as a DLL from sources. In the the "How to" section of the website, they give a simple command line to build it :
cl sqlite3.c -link -dll -out:sqlite3.dll
When I try this command, I get the DLL but not the ".lib" file. With the DLL only I cannot use SQLite inside another dev project. Without the .lib file, there are some symbols missing.
here are some notes i made a while ago on creating a sqlite3.lib file using the contents of sqlitedll-X_X_X.zip (and some other files). This approach might differ from your intended approach - but it may get your project started - I hope it helps.
create \tmp folder in your project directory
find the following 3 files (on the web) and then copy them into the \tmp directory: lib.exe, link.exe, mspdb80.dll
from the latest sqlitedll-X_X_X.zip file (i used: http://www.sqlite.org/sqlitedll-3_7_3.zip) copy sqlite3.def and sqlite3.dll to \tmp directory
open command line (terminal) and navigate to \tmp directory
create .LIB file by typing:
LIB /DEF:sqlite3.def /MACHINE:X86
copy the newly created sqlite3.lib file to your project directory
make sure that the following files are in the project directory:
sqlite3.h (from: http://www.sqlite.org/sqlite-amalgamation-X_X_X.zip)
sqlite3.dll (from: http://www.sqlite.org/sqlitedll-X_X_X.zip)
also
add the sqlite3.h file to the project
make sure that the linker can see sqlite3.lib
For those trying to do this with CMake, and assuming that you are building from amalgamation sources, to produce the .lib file when building a shared variant on Windows you need to add a compile definition SQLITE_API=__declspec(dllexport), for example:
project("SQLite3"
VERSION 3.39.1
DESCRIPTION "Small, fast, self-contained, high-reliability, full-featured SQL database engine"
LANGUAGES C
)
# ...
add_library(${PROJECT_NAME})
# ...
if(BUILD_SHARED_LIBS)
if(WIN32)
target_compile_definitions(${PROJECT_NAME}
PRIVATE
"SQLITE_API=__declspec(dllexport)"
)
else() # haven't tested that
target_compile_definitions(${PROJECT_NAME}
PRIVATE
"SQLITE_API=__attribute__((visibility(\"default\")))"
)
endif()
endif()
# ...

How to manage development and installed versions of a shared library?

In short: This question is basically about telling Linux to load the development version of the .so file for executables in the dev directory and the installed .so file for others.
In long: Imagine a shared library, let's call it libasdf.so. And imagine the following directories:
/home/user/asdf/lib: libasdf.so
/home/user/asdf/test: ... perform_test
/opt/asdf/lib: libasdf.so
/home/user/jkl: ... use_asdf
In other words, you have a development directory for your library (/home/user/asdf) and you have an installed copy of its previous stable version (/opt/asdf) and some other programs using it (/home/user/jkl).
My question is, how can I tell Linux, to load /home/user/asdf/lib/libasdf.so when executing /home/user/asdf/test/perform_test and to load /opt/asdf/lib/libasdf.so when executing /home/user/jkl/use_asdf? Note that, even though I specify the directory by -L during link, Linux uses other methods (for example /ect/ld.so.conf and $LD_LIBRARY_PATH) to find the .so file.
The reason I need such a thing is that, of course the executables in the development directory need to link with the latest version of the library, while the other programs, would want to use the stable version.
Putting ../lib in the library path doesn't seem like a secure idea, not to mention not completely correct since you can't run the test from a different directory.
One solution I thought about is to have perform_test link with libasdf-dev.so and upon install, copy libasdf-dev.so as libasdf.so and have others link with that. This solution has one problem though. Imagine the following additional directory:
/home/user/asdf/tool: ... use_asdf_too
Which gets installed to:
/opt/asdf/bin: use_asdf_too
In my solution, it is unknown what use_asdf_too should be linked against. If linked against libasdf.so, it wouldn't work properly if invoked from the dev directory and if linked against libasdf-dev.so, it wouldn't work properly if invoked from the installed location.
What can I do? How is this managed by other people?
Installed shared objects usually don't just end with ".so". Usually they also include their soname, such as libadsf.so.42.1. The .so file for development is typically a symlink to a fully-versioned filename. The linker will look for the .so file and resolve it to the full filename, and the loader will then load the fully-versioned library instead.

How to link a .lib in Visual Studio 2008 C++

I'm finding it really difficult to properly link a .lib file to my C++ Win32 Console Application. Here's my problem.
Just as in this MSDN article, I have developed a MathFuncsLib.lib file.
http://msdn.microsoft.com/en-us/library/ms235627%28v=vs.80%29.aspx
Then, in the MyExecRefsLib Win32 Console App, I want to link to the above file. So, inside MyExecRefsLib folder (same folder where .sln file resides) I created a directory called "LibraryFiles" and placed both MathFuncsLib.lib file AND MathFuncsLib.h file.
Then, in Properties->Linker->Input I added both "MathFuncsLib.lib" and "MathFuncsLib.h" (without full path) and then in Properties->Linker->Additional Library Directories I added the path to my folder "LibraryFiles" which is what pretty much EVERY thread on the web about this problem tells me to do.
But now it gives me the following error:
fatal error C1083: Cannot open the
include file. 'MathFuncsLib.h': No
such file or directory.
What am I doing wrong? Please help.
Note that my code is exactly the same as what's in the above given MSDN link.
To link with a .lib file, you just need to:
right clic on the project name, select Properties
under Properties->configuration properties->C/C++->General item "other include directories" add the path to your .h file
under Properties->Linker->Input add the path and name of your .lib file
And that's it.

Resources