Lets say I have a solution S1 with two projects pdep and pmaster, respectively creating a static and dynamic library. I have the configurations:
release win32 : produces pdep.lib
debug win32 : produces pdepd.lib
release x64 : produces pdepx64.lib
debug x64 : produces pdepx64d.lib
pmaster link configuration is done by Configuration Properties -> Linker -> Input -> Additional Dependencies
No #pragma comment(lib ) in the code. No common properties references.
What I observe :
In s1 with both pdep and pmaster the command line for the linker is fine. ie /LIBPATH:"c:\pdep\lib\x64\Release" "pdepx64.lib"
In a solution S2 freshly created by clicking on the project pmaster, I always have an additional line with an absolute path to a specific version of pdep, regardless of the configuration. ie /LIBPATH:"c:\pdep\lib\x64\Release" "pdepx64.lib" "c:\pdep\lib\pdepd.lib"
How does the linker in S2 derives the additional option "c:\pdep\lib\pdepd.lib"? How do I get rid of it?
Multiple possibilities:
Common Properties -> References
Link Library Dependencies in Linker or Librarian section. This assumes that Project Dependencies have been setup.
#pragma comment(lib...) is playing some role
You can flatten the project file using msbuild with a preprocess flag. Then load that into a plain text or xml editor. Look at the linker command and see what $(properties) hold the options, and then look at where that is being set.
With msbuild you can also use more verbose logging and it will report which conditions are evaluated and such.
Related
In Eclipse for Java, library classes are auto-imported in the class file
and it also prompts to choose which library if 2 library classes have the same method .
Is there a similar option for Eclipse CDT to automatically include iostream, math.h, stdio.h. Or do I need to type it out for every source file.
My compiler is Linux GCC.
Eclipse CDT does have the option to automatically add and managed the #includes for you.
To do so, select Source menu -> Organize Includes, or if you prefer the keyboard shortcut, Ctrl+Shift+O (letter o).
The settings that control what the organize includes does is controlled from preferences -> C/C++ -> Code Style -> Organize Includes, as shown in this screenshot:
If you have a symbol that is in multiple include files, you will be prompted. In this screenshot I have b with no #include already covering it, and two includes in my project that define the symbol (works with system includes too):
When building a static library which contains duplicate definition of a function, MSVC++ 2013 gives me just a warning:
LNK4006 "... already defined in ... second definition ignored"?
I'm afraid that a warning is too easy to miss. Is it possible to make MSVC++ 2013 to report an error and fail the build if multiple definitions for the same function is found (in different .cpp files)?
Note that the reverse of the solution suggested here (i.e. Project Settings > linker > uncheck 'Force file output') is not applicable because that's for an executable, but in this question a static library is in focus thus no "linker" project option.
There doesn't seem to be a way to treat specific warnings as errors. You can however treat every linker warning as error:
Go to: Project Properties -> Linker -> General -> Treat Linker Warnings As Errors and switch it to Yes (/WX).
I just created a new cocoa project on Xcode 4.3.3. The preprocessor macros for the Apple LLVM compiler 3.1 settings have a DEBUG=1 $(inherited) value assigned. I removed it and add it again, and now I'm getting an error when compiling :
clang: error: no such file or directory: 'DEBUG=1'
I search for the value on the project settings and I saw that the value is also defined in "Other warning flags"
My questions are:
What is the difference between just having DEBUG vs DEBUG=1?
What does $(inherited) do?
What is it also doing on the other warning flags?
First, if you're getting a compilation error, then you most likely put the macro back in the incorrect place in the project settings. Please ensure you've put it into the Debug configuration branch of the Preprocessor Macros item under the Apple LLVM compiler x.x - Preprocessing section.
For your other questions:
The first version just defines the macro DEBUG so it's essentially empty. You can test for whether it exists or does not exist, but not much. The second sets it to 1 so that the preprocessor can actually do comparisons like #if DEBUG && SHOULD_DIE_ON_ERROR where you might abort if the application comes across some validation error, but only if SHOULD_DIE_ON_ERROR is set and 1 and you're running in debug mode.
The $(inherited) just brings in other macros you're inheriting from further up the chain. So if your project defines some items and your target defines some more, the target gets the project's settings as well without having to re-define them.
It shouldn't be effecting the warning flags at all. If anything, it determines code paths in header files you include (like the cocoa frameworks) which may use different implementations for things or may add debugging information to data structures, or whatever.
I am using VS2010 Express and just installed Boost v1_47. I have added the 'include' folder to 'additional include folders' option, and also the 'lib' folder to the 'additional libraries' option in VS.
Then, I included boost/regex.hpp in one of my files, but actually wrote no code using boost yet. However, when building the solution I get lots of error messages, coming in two flavours:
Redefiniton errors, such as:
1>D:\boost\boost_1_47\boost/detail/interlocked.hpp(83): error C2373: '_InterlockedCompareExchangePointer' : redefinition; different type modifiers
1> C:\Program Files\Microsoft SDKs\Windows\v7.1\include\winnt.h(2597) : see declaration of '_InterlockedCompareExchangePointer'
Invalid calling convention errors (lots of these), such as:
D:\boost\boost_1_47\boost/regex/v4/regex_traits_defaults.hpp(271): error C3641: 'boost::re_detail::global_lower' : invalid calling convention '__cdecl ' for function compiled with /clr:pure or /clr:safe
Note: I haven't explicitly included winnt.h in any of my source/header files, and have tried de-activating pre-compiled headers and removing the stdafx.h includes, but it didn't solve the problem.
What's going on?
Thanks in advance
You have to make sure that you compile your program with the same settings as boost.
It seems like you used the wrong project template (CLR something) to create your application project.
You could try to modify the properties of your existing project to make it compatible with boost, but the CLR ... projects have lots of incompatible property values set by default, so i think the easiest way would be to create a new project from scratch (and import your existing code).
You should use the "Empty Project" template and create a new project, and then add your existing source and header files to it, and add the boost include path again, and add any required boost .lib files to Project Properties > Linker > Input > Additional Dependencies (Most boost libraries work out of the box without adding anything to linker inputs because they are header only, so you might not need to add any .libs).
Boost is a C++ required, designed to be consumed by C++ code, not C++/CLI code, thus it can only be used with native C++ classes, and most boost headers will produce headers when included in a source file which contains C++/CLI code.
I'm trying to use a static library created by me in Visual C++ 2005 (unmanaged C++). I declare one function "int myF(int a);" into a .h file, I implement it in a .cpp file, I compile it - the .lib file is produced.
I create a new project (a separate solution) in VC++ 2005 (also native C++), I add the paths for the include file and the lib file; when I invoke the function myF the linker reports an error: "error LNK2019: unresolved external symbol _myF referenced in function _main". if I create the client project in the same solution as the library project and then add a reference to the library projects, it works, but I'm not going to implement everything like this, but rather to add external libraries to my projects...
What is wrong?
Thank you.
You need to also include the actual .lib file in your 2nd project (not just the path to it).
There should be an option in the linker settings to do this.
It is not sufficient to list the folder in which MyStatic.lib can be found. You have to explicitly tell the linker that Dependant.vcproj is using MyStatic.lib.
In VS2005 you do this by project properties->Linker->Input->Additional Dependencies. You can also sprinkle some preprosessor stuff in the .h file to tell the compiler to tell the linker to use MyStatic.lib.
Edit:
The preprocessor magic goes like this
#pragma comment(lib, "MyStatic.lib")
(EDIT: This was a response to the question of getting the /NODEFAULTLIB error in link phase which has now been deleted... shrug)
You are mixing compiler settings if your are getting the defaultlib error. For example, if you build your library in debug and the build your main in release, you will get this error since they are built to use different versions of the CRTL. This can also happen if you use different settings for linking with the C Runtime as a object library or as a DLL. (See the C/C++ options, the "Code Generation" section, under the "Runtime Library" setting)
In many projects there isn't much you can do if you can't correct the settings of the library (for example, 3rd party libraries). In those cases you have to use the /NODEFAULTLIB switch which is a linker option in the "Input" section called "Ignore Specific Library".
But since you are in control of both the main and the library, build a debug and a release version of your LIB file or make sure your "C/C++;Code Generation;Runtime Library" settings match in both projects.
Try setting additional dependencies in the linker input for a project properties.