I am just approaching C++ development (from a C# background), and i am wondering what is the difference between Library Directories in C++ project settings (in Visual Studio):
and the Linker "Inputs" where i can also supply libraries:
Is there any fundamental difference between these?
This setting got fumbled a bit in VS2010, it was much clearer in previous versions. Where the settings you show in your screenshot were present in Tools + Options. Which shows the core intent, they contain directories that are determined by the setup for Visual Studio and its components. The locations of the CRT, MFC, ATL and SDK libraries.
The Linker + Input + Additional Dependencies setting is the important one, there you say exactly what .lib files the linker should link. You can specify the path of a .lib file and be done. But it is not uncommon that you only specify the name of the .lib file, then edit Additional Library Directories to tell the linker where to search for those .lib files. Which is handy if the install location for, say, Boost isn't always the same or you want to switch from one version of Boost to another.
So in summary:
Linker + Input + Additional Dependencies: add the .lib files you need to link
Linker + General + Additional Library Directories: only use if you didn't specify the path of .libs
VC++ directories: don't mess with it
Do note that the last two bullets only specify directories, not .lib files that the linker should link. The first bullet specifies actual .lib files. What is invariably confusing to starting MSVC programmers is that the linker magically knows how to find important .lib files without specifying them explicitly in the Additional Dependencies setting.
That's unfortunately the non-visual part of Visual C++. There are two distinct ways in which a project can specify .lib files that the linker should link without using the setting. The first one is the project template you selected to get the project started. It uses project property sheets, files that specify default settings for a project. You see them with View = Other Windows + Property Manager. An important one is "Core Windows Libraries", it sets the Additional Dependencies setting to link the essential Windows .lib files, the ones you always need like kernel32.lib and user32.lib. Those settings are "inherited" by your project. Otherwise giving meaning to "NoInherit" if you ever run into it.
The second important way is the #pragma comment directive. Which is used in source code, it injects a linker directive. The "lib" variety is important, that tells the linker to link a .lib file. In addition to what you explicitly specify in the linker's Additional Dependencies setting. A very good example of that one is vc/atlmfc/include/afx.h. Search for "#pragma comment". Note the macro soup that selects the proper mfc .lib file, depending on compiler specific settings. And the bunch of extra Windows .lib files an MFC needs to link.
The C++ build model is filled with a maze of twisty little passages. The IDE tries to make you fall in the pit of success but in the process hides what's important to get to the next level of understanding. It isn't different in C#, to know how to make the Reverse() extension method not consume O(n) storage requires digging in.
Most (not all) libraries come with two sets of files:
Header files are #included in the source code that's using the libraries, to provide declarations for functions, classes, constants or whatever else might be needed
Library files are binary code that contains the code of the library. These are used by the linker when it assembles the final executable
Related
I tried to add my USART library to my project but I am still failing to properly add it so it will be recognized.
I created an USART.c and USART.h file, which I want to add. This is what I tried:
1) Right Click on the Solution / Properties / Toolchain / Directories
2) Adding the Path where I got these two files
When I try to build the project, it did not work. I get the message undefined reference to 'initUSART'.
How do I add my own libraries to projects then?
The screenshot in your question shows that you arranged for the compiler to find the header files for your library. But you also need to use the compiler to compile your library functions (e.g. initUSART) and create a static library file (with a lib prefix and a .a extension). You would need a separate Atmel Studio project for that, or learn how to use the AVR GCC toolchain outside of the IDE to compile libraries. Then you need to put that file in a directory that is in the linker's search path for libraries, and then you need to pass the appropriate -l argument to the linker. For example, if your library is called libuart.a, you need to pass -luart to the linker. The Project Properties for an Atmel Studio project has the relevant settings you need to configure.
GCC has a standard way to compile, create, and link to static libraries, which I outlined above. You can learn about that from any tutorial on GCC static libraries. You then would need to apply that knowledge to the AVR GCC toolchain, and find the appopriate options inside Atmel Studio that you need to set.
Aside: Atmel Studio does not make it easy to use libraries at all. The Arduino IDE does a much better job because you just put the source files for the library in the right place and it compiles them for you. There are a huge number of Arduino libraries too; you wouldn't have to write your own UART driver if you could use the Arduino platform.
The simple alternative: If you don't know much about compiling and linking to C libraries and configuring your IDE, you would have a much easier time just copying the library files into your project, adding them as source files, and letting Atmel Studio compile them just like any other source file in your project.
Another simple way of adding folders to your project is to copy/paste the folder into your project and then open Atmel Studio.
On the right side (where is by default Solution Explorer) you'll see all your files except the ones that you just added. Now press the Show all files and search for you folder which should appear grayed out. Right click on it and Include in project. That should be all!
This image should help
I got another solution that might help . i found Include Directories in this path for MegaAvr(8bit) :
C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.6.364\include
Just Puts All your Library in one Folder And Copy All of It in this path , then include it like another library . For example I created a folder named "ali" in that path , then i copied all my libraries in this folder (like alcd.h , usart.h) and then included in my programes with this :
#include <ali/usart.h>
and done ! just remember to backup your folder before Windows Installation (Drive Format) . Also you can find your libraries (.h and .c) in Solution Explorer -> Dependencies after Code Compilation .
GoodLuck ...
inside Folder
including xio.h in folder ali
xio.h in dependencies after compilation
my folder in specified path
I need to link library from one project into another, and it looks there are 2 ways, can you tell what is the difference and what is the consequence of having "true" in one setting and "false" in another (the same) setting?:
and another one:
What is the difference, and do I need both setting set to "yes" or just one and if so which one?
A one-line explanation would probably be that the second option specifies something about how the first one works.
Link Library Dependencies set to Yes: if the solution is set up so that the current project has a dependency on another project that produces a .lib file, then that file will be linked in automatically.
Use Library Dependency Inputs set to Yes: useful mostly in Debug builds, when Incremental Linking is enabled. Normally, if a .lib generated by another project changes, and the current project depends on it, the linker can no longer link the current project incrementally (it's difficult for it to know how exactly the .lib changed). If you set this option to Yes, then the linker doesn't use the .lib file generated for the other project, but rather the individual .obj files that were used by the librarian to generate that .lib (as if the .lib didn't exist, and every object file from the other project were given to the linker individually, alongside the .obj files from the current project). This enables it to continue linking incrementally.
As far as I can tell, Use Library Dependency Inputs only makes sense if Link Library Dependencies and Enable Incremental Linking are both also set to Yes, and the current project depends on another project that generates a .lib file that changes often during development.
Additional information here and reference docs here.
UPDATE based on the comment from the OP:
As far as I can tell, the property entry under Project Reference Properties specifies the setting individually for each referenced project (whether to use the .lib from that specific project or not), while the one under Linker - General is the default setting for referenced projects.
For example, if you set the one under Linker - General to No and add a new referenced project, then, for that project, the setting under Project Reference Properties will default to False. However, the settings for referenced projects that were added before keep their individual setting.
I expect the individual setting under Project Reference Properties to override the default from Linker - General, but I haven't actually tested this bit.
cant seem to find a definintive answer to how to add a library. theres project properties with a whole bunch of places to add filepaths but im wondering if i shouldnt be editing all of them, can someone tell me the purpose of each possible entry, if there are more, and possibly which ones i should be editing? or a handy tutoril? ill list what entries i know about. currently trying to add the Wwise library.
project->project name properties->configuration properties->vc++
directories->library directories (click edit and addthe relevant
filepath)
project->project name properties->configuration
properties->linker->general->additional library dependencies (click
edit and addthe relevant filepath)
project->project name properties->configuration
properties->linker->input->additional dependencies (enter the names
of the libraries manually)
If i go through all that i get more linker errors than i started with
Those are the directories that the linker will search for .libs that are provided with Visual Studio. Like the CRT, MFC, ATL and the Windows SDK. You don't want to tinker with that one, the default value is read from the registry and was written there by the installer. Only change if you want to link to non-standard versions of these .libs
Those are the files that the linker will actually link.
Those are the additional directories that the linker will search for files that were specified in bullet 2 or from #pragma comment directives in the source code. You'll only need to set this if bullet 2 didn't specify the full path of the file or the .lib file isn't present in one of the VS standard directories or the project directory. You typically put the Boost install directory there for example.
So bullet 2 is the important one, that actually specifies what will be linked. Bullet 3 just helps the linker find the file.
So I used the VisualMagick tool to set up a Static Library project and compiled all of the ImageMagick Source to static lib files. Then I created a new solution and moved all those libs and the needed .h files to my lib folder in my new solution. My cpp file that I want to use the lib files compiles fine, even with #include Magick++.h in the header, until I add any references to things in imageMagick. Like if I say Magick::Image image; It will give me LNK1120. I have added the lib folder to my projects Additional Library Locations (or something like that) in the solution properties. I am new to the whole Linking language thing, coming mostly from a Python/Java background. Any suggestions? I have tried a brute google search and tried a lot of the suggestions I have seen.
I'll put the foregoing comments interchange in the form of a real answer:
To convince VS20xx to link your app with some non-standard library, including maybe a new library that you just built:
Under the VS main-menu "Project" tab, take "<your-project-name> Properties ..." and then
First, tell the linker where to look for a lib (like make -L):
Linker --> General
In the "Additional Library Directories" edit box, give the paths -- just the directories -- where lib files live.
Second, tell the linker what library files you want to lilnk with (like make -l):
Linker --> Input and then
In the "Additional Dependencies" edit box, add the space-separated unadorned lib-file name(s), no quotes needed, like:
Additional Dependencies mysqlclient.lib libcurl.lib mynewlib.lib
That should be it. (yeah, suuuuuuuuure :-)
I'm developing a large project using Qt 4.6, CMake 2.8 and Visual Studio 2008 for the Windows platform.
As far the build system goes, it's all standard stuff: I'm using CMake's QT4_WRAP_CPP macro to generate moc files from header files, which are then linked into the final executable in the add_executable command. Everything is working as expected.
The only restriction with this setup is that I can't define widgets or helper using Q_OBJECT in .cpp files. This would be very convenient for small, context-specific helpers classes that should appear right next to where they're used.
I tried to pass the whole list of source files (both .h and .cpp) to QT4_WRAP_CPP, instead of just the header files, but that doesn't work (linking fails because some moc-related symbols are undefined).
I think the problem is that, for a given pair of files foo.h and foo.cpp, the QT4_WRAP_CPP macro will generate the same moc file (moc_foo.cxx) in the same directory, and obviously that means the first file will be overwritten by the second one, and as a result symbols will be missing at link-time.
Is there a way to fix or work around that problem? For instance, I tried to add a specific rule for foo.cpp of the form
QT4_GENERATE_MOC(directory/foo.cpp directory/foo.moc)
and then add
#include "foo.moc"
at the end of foo.cpp. I think this ought to work, but alas Visual Studio only allows one build rule per file, and .cpp files already have a build rule (compilation to object file), so this approach doesn't work, at least with Visual Studio.
Another idea that I had was to create a new macro, say QT4_WRAP_CPP_WITH_PREFIX, based on QT4_WRAP_CPP (which is defined in share/cmake-2.8/Modules/Qt4Macros.cmake), that would take an additional prefix argument and would add this prefix to the generated moc files. That way, I would call QT4_WRAP_CPP_WITH_PREFIX twice, once for .h files and once for .cpp files, with different prefixes. What I just dislike about this approach is that I'd be messing with the internals of CMake's Qt support, instead of using the public API.
Any better idea?
Recent versions of CMake have "automoc" which worked like a charm for me:
http://blogs.kde.org/2011/11/01/cool-new-stuff-cmake-286-automoc
Simply add in the CMakeLists.txt:
set(CMAKE_AUTOMOC TRUE)
and then in the cpp (e.g. example.cpp) file:
#include "example.moc"
(the *.moc must match the cpp file's name).
Referring to the documentation "Using the MOC" (http://doc.qt.nokia.com/4.1/moc.html), you'd only need to import "foo.moc" at the end of your implementation file. As you can not tweak the build rules correspondingly, try to export a .pro file and apply the build rule as suggested by the nokia document.