Suppose I have two vc++ project, proj_a and proj_b
proj_a contains a header file a.h
proj_b has dependency on proj_a. It contains file b.h that does #include <a.h>. I add a.h's directory in the "additional include directories" in its project settings to build it.
Now say, I have 100 more projects, whose files #include <b.h>. Only adding b.h's directory in the "additional" column does not work. I have to include the path of a.h too.. How to avoid this?
Simply put, how to keep the number of include paths for any vc++ project equal to the number of direct dependencies?
I don't have the option to set vc++ environment settings to globally include a.h's path since everybody else in my team will have to import my settings and things will turn messier..
I don't have enough idea but is there a way to achieve this through precompiled headers? I think they are project-specific and should not be shared across projects?
Dependencies are transitive. That is, since b.h includes a.h, anything that includes b.h will need to be able to find a.h. The only thing you can do about it is to somehow remove the dependency of b.h on a.h, perhaps by using a forward declaration for the types in a.h instead of relying on the full definition of the types from the header file.
If that's not an option, at least you can ease the pain of include paths that are duplicated across projects by using Visual C++'s "property sheet" feature. These let you define shared build settings in a single file which can be inherited by an arbitrary number of projects. This will also solve the problem of sharing these settings with your collaborators.
Thanks for the answer Nick. I could have used relative path to a.h inside b.h and save having additional-include-directories inside proj_b and rest of 100 projects.
Actually, in my case there are multiple flavors of proj_a: 'proj_a1, proj_a2, etc. each having a separate a.h. The other 100 projects decide on which flavor to include by having appropriate additional-include-directory in their settings. This was an issue, whenever we need to upgrade proj_a flavors, all include-dirs will need to be changed.
I got across this problem by removing all include-dirs and instead defining PROJ_A1, PROJ_A2, etc. in the rest of projects. b.h does not #include a.h anymore, it include a a_redirector.h header file instead (with relative path). Inside a_redirector.h, we have all #ifdef PROJ_A1, #ifdef PROJ_A2, etc. that looks at the include a particular a.h file (relative paths here too) depending on what has been defined.
Now, whenever we need to upgrade proj_a flavors, I need only to modify a_redirector.h only to point to all new a.h thereby having a single point of control as compared to the earlier architecture.
Related
I have a project with two module (client and server).
Each module is in subfolder of it's own, with it's own make file.
I have single configure.ac file in the project's root directory.
We use AC_SEARCH_LIBS to set compilation flags for the project.
The problem is that both modules need to use different libraries (server needs pthread, client does not).
How is it possible to set different compilation flags for the different modules?
What is the best practice?
Do I need to split configure.ac ? (if yes, how it should be done correctly)
There's no need to split into multiple configure.ac.
The trick is, to create different substitution variables for each library, which you can then use independently in your Makefile.ams
configure.ac (excerpt):
AC_SEARCH_LIBS([fooFun], [foo], [FOO_LIBS="-lfoo"])
AC_SEARCH_LIBS([barFun], [bar], [BAR_LIBS="-lbar"])
AC_SEARCH_LIBS([bazFun], [baz], [BAZ_LIBS="-lbaz"])
AC_SUBST([FOO_LIBS])
AC_SUBST([BAR_LIBS])
AC_SUBST([BAZ_LIBS])
and server/Makefile.am (excerpt):
server_LDADD = #FOO_LIBS# #BAR_LIBS#
resp. client/Makefile.am (excerpt):
client_LDADD = #BAZ_LIBS#
I am using Visual C++ 2008 Express for the first time for a project. And I can't seem to be able to split the .h & .cpp files for classes I'm writing. I was under the impression that you add a header file and prototype the class in there, and then you add a .cpp file with the implementation into your source files directory. Then when you include the .h it would automatically include the .cpp implementation files. Is this correct or am I missing something?
Not sure if this is the same as in Express version. But you can also add a new C++ class with header (.h) and source (.cpp) at the same time by right clicking on the project -> Add -> Class...
By including the .h file using #include, doesn't mean the actual implementation (in another .cpp file) is also include in your source file. The content of .h file which are class and method prototypes is only included. These prototypes allow you to make use of the classes declared in header file (without including real C++ code.)
Each source files (.cpp) are first compiled into object files. All these object file are then linked together to create single executable file. The referenced symbols in, each object file, are actually linked to their implementation during this linking process (http://www.cprogramming.com/compilingandlinking.html)
I don't remember the rules, but sometimes the IDE assumes you're putting all your code in the header file. This is legal, but not a common preference.
In every platform there are various versions of a given library: multi-threaded, debug, dynamic, etc..
Correct me if I am wrong here, but in Linux an object can link to any version of a library just fine, regardless of how its compiled. For example, there is no need to use any special flags at compile time to specify whether the link will eventually be to a dynamic or a static version of the run-time libraries (clarification: I am not talking about creating dynamic/static libraries, I am talking about linking to them - so -fPIC doesn't apply). Same goes for debug or optimized version of libraries.
Why in MSVC (Windows in general with other compilers. true?) I need to recompile the code every time in order to link to different versions of libraries? I am talking the /MD, /MT, /MTd, /MDd, etc flags. Is the code actually using different system headers each time. If so, why?
I would really appreciate any pointers to solid documentation that discusses these library matters in Windows for a C/C++ programmer..
thanks!
The compiler setting does very little other than simple change some macro definitions. Its microsoft's c-runtime header files that change their behaviour based on the runtime selected.
First, the header files use a # pragma directive to embed in the object file a directive specifying which .lib file to include, choosing one of: msvcrt.lib, msvcrtd.lib, libcmt.lib and mibcmtd.lib
The directives look like this
#ifdef <release dll runtime>
#pragma comment(lib,"msvcrt.lib")
#endif
Next, it also modifies a macro definition used on all c-rt functions that adds the __declspec(dllimport) directive if a dll runtime was selected. the effect of this directive is to change the imported symbol from, say, '_strcmp' to '__imp__strcmp'.
The dll import libraries (msvcrt.lib and msvcrtd.lib) export their symbols (to the linker) as __imp_<function name>, which means that, in the Visual C++ world, once you have compiled code to link against the dll runtimes you cannot change your mind - they will NOT link against a static runtime.
Of course, the reverse is not the case - dll import libraries actually export their public symbols both ways: with and without the __imp_ prefix.
Which means that code built against a static runtime CAN be later co-erced into linking with the dll or static runtimes.
If you are building a static library for other consumers, you should ensure that your compiler settings include:
One of the static library settings, so that consumers of your .lib can choose themselves which c-runtime to use, and
Set the 'Omit Default Library Name' (/Zl)flag. This tells the compiler to ignore the #pragma comment(lib,... directives, so the obj files and resulting lib does NOT have any kind of implicit runtime dependency. If you don't do this, users of your lib who choose a different runtime setting will see confusing messages about duplicate symbols in libc.lib and msvcrt.lib which they will have to bypass by using the ignore default libraries flag.
These using these compiler options have two effects. The automatically #define a macro that may be used by header files (and your own code) to do different things. This effects only a small part of the C runtime, and you can check the headers to see if it's happening in your case.
The other thing is that the C++ compiler embeds a comment in your object file that tells the linker to automatically include a particular flavor of the MSVC runtime, whether you specify that library at link time or not.
This is convenient for small programs, where you simply type at a command prompt cl myprogram.cpp to compile and link, producing myprogram.exe.
You can defeat automatic linking of the commented-in flavor of the c-runtime by passing /nodefaultlib to the linker. And then specify a different flavor of the c-runtime instead. This will work if you are careful not to depend on the #defines for _MT and
_DLL (keep in mind that the standard C headers might be looking at these also).
I don't recommend this, but if you have a reason to need to do this, it can be made to work in most cases.
If you want to know what parts of the C header files behave differently, you should just search for _MT and _DLL in the headers and see.
All of the options use the same header files, however they all imply different #define which affect the header files. So they need to be recompiled.
The switches also link to the appropriate library, but the recompile is not because of the linking.
See here for a list of what is defined when you use each.
I have a set of statically-compiled libraries, with fairly deep-running dependencies between the libraries. For example, the executable X uses libraries A and B, A uses library C, and B uses libraries C and D:
X -> A
A -> C
X -> B
B -> C
B -> D
When I link X with A and B, I don't want to get errors if C and D were not also added to the list of libraries—the fact that A and B use these libraries internally is an implementation detail that X should not need to know about. Also, when new dependencies are added anywhere in the dependency tree, the project file of any program that uses A or B would have to be reconfigured. For a deep dependency tree, the list of required libraries can become really long and hard to maintain.
So, I am using the "Additional Dependencies" setting of the Librarian section in the A project, adding C.lib. And in the same section of B's project, I add C.lib and D.lib. The effect of this is that the librarian bundles C.lib into A.lib, and C.lib and D.lib into B.lib.
When I link X, however, both A.lib and B.lib contain their own copy of C.lib. This leads to tons of warnings along the lines of
A.lib(c.obj) : warning LNK4006 "symbol" (_symbol) already defined in B.lib(c.obj); second definition ignored.
How can I accomplish this without getting warnings? Is there a way to simply disable the warning, or is there a better way?
EDIT: I have seen more than one answer suggesting that, for the lack of a better alternative, I simply disable the warning. Well, this is part of the problem: I don't even know how to disable it!
As far as I know you can't disable linker warnings.
However, you can ignore some of them, using command line parameter of linker eg. /ignore:4006
Put it in your project properties under linker->command line setting (don't remember exact location).
Also read this:
Link /ignore
MSDN Forum - hiding LNK warnings
Wacek
Update If you can build all involved project in single solution, try this:
Put all project in one sln.
Remove all references to static libraries from projects' linker or librarian properties.
There is "Project Dependencies..." option in context menu for each project in Solution Explorer. Use it to define dependencies between project.
It should work. It doesn't invalidate anything I said before, the basic model of building C/C++ programs stays the same. VS (at least 2005 and newer) is simply smart enough to add all needed static libraries to linker command line. You can see it in project properties.
Of course this method won't help if you need to use already compiled static libraries. Then you need to add them all to exe or dll project that directly or indirectly uses them.
I don't think you can do anything about that. You should remove references to other static libs from static libs projects and add all needed static libs projects as dependences of exe or dll projects. You will just have to live with fact that any project that includes A.lib or B.lib also needs to include C.lib.
As an alternative you can turn your libraries into dlls which provide a richer model.
Statically compiled libraries simply aren't real libraries with dependency information, etc, like dlls. See how, when you build them, you don't really need to provide libraries they depend on? Headers are all that's needed. See? You can't even really say static libraries depend on something.
Static library is just an archive of compiled and not yet linked object code. It's not consistent whole. Each object file is compiled separately and remains separate entity inside the library. Linking happens when you build exe or dll. That's when you need to provide all object code. That's when all the symbol and dependency resolving happens.
If you add other static libraries to static library dependencies, librarian will simply copy all code together. Then, when building exe, linker will give you lots of warnings about duplicate symbols. You might be able to block those warnings (I don't know how) but be careful. It may conceal real problems like real duplicate symbols with differing definitions. And if you have static data defined in libraries, it probably won't work anyway.
Microsoft (R) Incremental Linker Version 9.00.x (link.exe) knows argument /ignore:4006
You could create one library which contains A, B, C & D and then link X against that.
Since it's a library, only object modules which are actually referenced will get linked into the final executable.
Note that one way of getting this warning is to define a member function in a header without the inline statement:
// Foo.h
class Foo
{
void someFunction();
};
void Foo:someFunction() // Warning! - should be "inline void Foo::someFunction()"
{
// do stuff
}
The problem is you are not localizing library C's symbols. So you have a ODR violation when you link in A and B. You need to have a way to make these private. By default all symbols are exported. One way to do this is to have a special linker definition file for both A and B that explicitly mention which files need to be exported.
[1] ODR = One Definition Rule.
I think the best course of action here will be to ignore/disable the linker warnings(LNK4006) since C.lib needs to be part of both A.Lib and B.lib and A.Lib does not need to know that B.lib itself uses C.Lib.
This may not fix your link error, but it might help with your dependency tree issue.
What I do, is just use a #pragma to include a lib in the .cpp file that needs it. For example:
#pragma comment(lib:"wsock32")
Like I said, I'm not sure it would keep the symbols in that object file, I'd have to whip up an example to try it out.
Poor flodin seems frustrated that nobody will explain how to disable the linker warnings. Well, I've had a similar problem, and for years I have simply lived with the fact that several hundred warnings were displayed. Now, however, thanks to the info from Link /ignore, I figured out how to disable the linker warnings.
I'm using Visual Studio 2008. In Project -> Settings -> Configuration Properties -> Librarian -> Command Line -> Additional Options, I added "/ignore:4006" (without the quotes). Now my warnings are gone!
Is it possible to build resources into a static library and reuse them by simply linking with the library?
I'm primarily thinking about the case where you call a function in the library which in turn accesses resources.
The only thing you need to do to use resources (images, dialogs, etc...) in a static library in Visual C++ (2008), is include the static library's associated .res file in your project. This can be done at "Project settings/Linker/Input/Additional dependencies".
With this solution, the resources of the static library are packed into the .exe, so you don't need an extra DLL. Regrettably, Visual Studio does not include the .res file automatically as it does for the .lib file (when using the "project dependencies"-feature), but I think this small extra step is acceptable.
I have looked for a very long time for this solution, and now it surprises me it is that simple. The only problem is that it is totally undocumented.
It can be done, but it's quite painful: You can't do it by simply linking with the static library.
Consider this: resources are embedded in an EXE or DLL. When some code in the static library calls (e.g.) LoadIcon, it'll get the resources from the EXE or DLL that it's linked with.
So, if your static library requires resources to be available, you've got a couple of options:
You can have the library build them on the fly, and then use (e.g.) CreateDialogIndirect. See Raymond Chen's "Building a dialog template at run-time".
You can have them embedded in the library as simple arrays (i.e.) char my_dialog_resource[] = { .... };, and then use (e.g.) CreateDialogIndirect. You'll probably need to find (or write) a utility that converts from .RES files to .CPP files.
You can ship the LIB file with a resource script (.RC file) and corresponding header file. You then #include them as relevant. You'll need to reserve a range of resource IDs for the LIB to use, so that they don't collide with those of the main EXE or DLL. This is what MFC does when used as a static library. Or you can use string resource IDs (this doesn't work for STRINGTABLE resources).
Your static library can ship with a separate resource DLL.
I just went through this with the MS Visual Studio compiler. We were converting some legacy projects from DLLs into static libraries. Several of these DLLs had dialog or string resources embedded in them. I was able to compile the .RC scripts for these DLLs into our main application by including them in the main application's RC script file via the "TEXTINCLUDE" mechanism. I found it easiest to do this by editing the RC file directly, but Visual Studio provides a slightly more "wizardy" mechanism as well. The implementation is most likely different in other compilers.
To manipulate the main RC script directly:
.1. In the "2 TEXTINCLUDE" section, include the header file that defines the resource IDs for your library. The syntax is
2 TEXTINCLUDE
BEGIN
"#include ""my_first_lib_header.h""\r\n"
"#include ""my_second_lib_header.h""\0"
END
.2. In the "3 TEXTINCLUDE" section, include the RC script from your library.
3 TEXTINCLUDE
BEGIN
"#include ""my_first_library.rc""\r\n"
"#include ""my_second_library.rc""\0"
END
Steps 3 and 4 should happen automatically, but I found it was more reliable to just enter them myself, rather than depending on Microsoft's resource script compiler to take care of things.
.3. Add the header file with your libraries resource defines to the read only symbols list. This list is usually near the top of the file.
#define APSTUDIO_READONLY_SYMBOLS
#include "my_first_lib_header.h"
#include "my_second_lib_header.h"
#undef APSTUDIO_READONLY_SYMBOLS
.4. Include your library's RC script in the APSTUDIO_INVOKED section. This is usually at the bottom of the file.
#ifndef APSTUDIO_INVOKED
#include "my_first_library.rc"
#include "my_second_library.rc"
#endif
You can also do all of this automatically through the visual studio IDE, but I found it didn't always apply when I expected it to.
Open the "Resource View" window in Visual Studio.
Right-click on your main application's resource file and choose "Resource Includes..." from the context menu.
In the box labeled "Read-only symbol directives," add the include statements for the .h files that define the resource ID's for your libraries.
In the box labeled "Compile-time directives," add the include statements for your library's .rc script.
Click okay. You may also want to manually trigger the RC script compilation, to make sure it happens.
If your library's resource script references any files on disk (text files, icons files, etc.), you'll need to make sure that the main application project knows where to find them. You can either copy these files to somewhere your application can find them or you can add an additional include path in the compiler settings.
To add an additional include path:
Open up the properties dialog for your main application.
Select "Configuration Properties/Resources/General" from the left-hand navigation pane.
In the properties list, Enter any pertinent paths next to "Additional Include Directories."
As per Visual Studio 2010, the development tools from Microsoft apparently cannot properly handle compiled resource data inside static libraries at all.
To distribute a compiled resource file (a .res file), you have two choices:
Distribute the .res files separately, and instruct the client code to link against them;
Use cvtres to merge several .res files into a single object (.obj) file, and provide it separately.
Note that you can't lib in object files created with cvtres. If multiple object files are provided, lib complains as though as multiple .res files were given; if a single object file is provided, lib does not complain, but the linker simply ignores the embedded resource data in the lib file.
It might be the case that there is a way to force the linker to read and link the libbed in resource data (with some command-line option, section manipulation and so on), since the resource data is indeed available in the library (as dumpbin reveals). So far, I haven't found a solution, and, unless one is willing to hack the development tools, anything better than this simple solution is probably not worth the effort.
The only way to ship resource data in a static library (in this case, with a static library) is to distribute the resources separately and explicitly link them in the client code. Using cvtres can reduce the number of distributed resource files to one, if you have many of them.
I don't think so. Static library doesn't have it's own HINSTANCE. It's code is executed in the context of DLL or EXE which links it. That's why all the resources you'll try to load from the static library's code will be of that enclosing DLL/EXE.
I did that kind of resources reuse with a DLL though, as far as it has it's own address space, and you can call LoadResource with DLL's HINSTANCE.
The recommended way is to provide a dll with the resources together with your library.
When the following method is used, any resource (in this example, an icon) can be used as an integral part of a static library and such library can be used by any type of application, including a console one (which doesn't have any resource segment whatsoever).
Icon is converted to a static array of BYTE. bin2c can be used for that.
Data is converted into a HICON handle. Here is how I have done that:
HICON GetIcon()
{
DWORD dwTmp;
int offset;
HANDLE hFile;
HICON hIcon = NULL;
offset = LookupIconIdFromDirectoryEx(s_byIconData, TRUE, 0, 0, LR_DEFAULTCOLOR);
if (offset != 0)
{
hIcon = CreateIconFromResourceEx(s_byIconData + offset, 0, TRUE, 0x00030000, 0, 0, LR_DEFAULTCOLOR | LR_DEFAULTSIZE);
}
return hIcon;
}
GetIcon is used instead of LoadIcon.
Instead of calling:
m_hIcon = ::LoadIcon(hInstanceIcon, MAKEINTRESOURCE(pXMB->nIcon));
Then call
m_hIcon = GetIcon()