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.
Related
I have two C projects that pull in the same library.
One project compiles and links fine, the other gets an "unresolved external reference" linker error for a symbol referenced inside a function which both projects call from the same static library.
As far as I can tell, all the linker and code generation properities of importance are equal between the two.
Is there a way to use the working project, to figure out where the linker in THAT project finds the symbol? I've been using trial and error, including more and more of the libraries from one project into the other with no success.
I found what I wanted! In the Project Properties, under Linker->Debugging, there is an option named "Generate Map File". This can be done on the command-line with /MAP.
The generated map file gets the same name as the project (by default) with .map as file extension. It is a text file containing, among other things, the library name where each symbol is defined.
Using the map file for my project that builds, I was able to quickly find the definition of the symbol missing from my broken project.
I want the users to be able to re-link my Qt-using application to their own build of Qt, without being forced to rebuild all of the sources. This could be used for LGPL compliance, for example. To do this, I need to provide object files for all of my sources. To make it easy, using qmake, I've partitioned the project internally into:
A static library project that contains objects for all of the source files, including the file that has int main(int, char**).
An application project that links the static library above with Qt. Qt may be either a static library or dynamic. There are no source files for this project.
I then distribute the static library (.lib) and the application project file so that anyone can relink the application with their own version of Qt, in whichever fashion they prefer (either statically linked Qt or dynamically linked Qt), as long as they have the necessary version of MSVC.
I'm doing the build under both MSVC 2008 (Qt 4) and 2012 (Qt 5). The makefiles are generated by qmake.
The problem is that the linking fails when building the application project.
LINK : error LNK2001: unresolved external symbol _WinMainCRTStartup
As soon as I add a dummy source file dummy.cpp to the application project, the linking succeeds. Is there a way of avoiding this workaround?
//dummy.cpp (this is the entire source)
int dummy;
It turns out that the linker isn't clever enough to figure out what default runtime library is needed for the executable if only static libraries are given to link, with no discrete object files. This can be corroborated by asking the linker to be verbose in the .pro file:
win32-msvc*: QMAKE_LFLAGS += /VERBOSE /VERBOSE:LIB /VERBOSE:REF
When the dummy file is present in the application project, the linker lists the following default libraries:
Processed /DEFAULTLIB:msvcprt
Processed /DEFAULTLIB:MSVCRT
Processed /DEFAULTLIB:OLDNAMES
Processed /DEFAULTLIB:uuid.lib
Without the dummy file, no default libraries are chosen by the linker at all. It is then unable to find the entry point, since the C runtime is not linked in.
Adding the relevant C runtime library is sufficient to link the application. In the application project file, one adds:
win32-msvc*:CONFIG(release, debug|release): QMAKE_LFLAGS += /DEFAULTLIB:msvcrt
win32-msvc*:CONFIG(debug, debug|release): QMAKE_LFLAGS += /DEFAULTLIB:msvcrtd
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 am building a Visual C++ 6.0 workspace in Visual Studio 2010, so that it'll update some dependencies
I have all the files and dll's it is looking for, it builds but then fails at linking with this error
1>LINK : fatal error LNK1181: cannot open input file '\Projects\exe\CRelease/api.lib'
I have api.dll which it needs to build, but I don't have a .lib file version of it. and even if I did (like if I somehow converted the .dll into a .lib), I wouldn't know where to place it in a directory structure
how do I "fix" this?
guidance appreciated, thank you
Normally api.dll would have an accompanying import library called api.lib which is what you need to link to. The import library is different to a statically-compiled version of api (which would also likely be called api.lib) - it's more like a list of available functions provided by the dll, and so will usually be much smaller than a corresponding static library.
If you do find or get api.lib, it doesn't really matter where it lives, as long as it can be accessed by your linker.
If you don't find the import library, you're looking at doing explicit run-time linking where api.dll is loaded and unloaded explicitly in your code, and api's exported functions are called through function pointers.
I noticed the following about a library I use:
Library is compiled to .lib file.
My code needs to be compiled as Multi-threaded (Debug) DLL to link to this library.
I open the .sln (solution) file of the library (it is open source) and see the following in its Project properties:
Runtime Library option is set to Multi-threaded (Debug) DLL.
Configuration Type is set to Static Library (.lib)
My confusion is:
Isn't there a conflict in the library options above? (Static Library says one option, DLL says another)
What kind of an animal is a .lib that is dynamically linked? How is it different from a DLL?
Note that I am aware of the difference between static libraries and dynamic libraries in the Linux world.
The "RunTime Library" option isn't about YOUR library. It tells the compiler that you'll import your functions from MSVCRTxx.DLL at runtime.
The "configuration Type" option does refer to your library, and therefore is independent of the "RunTime Library" option.
A Windows DLL can be dynamically loaded with the LoadLibrary (or LoadLibraryEx) API, but then you have to find and bind each exported function to a function pointer using GetProcAddress or GetProcAddressEx. You'd better get the function signatures right, or Bad Things Will Happen, as usual.
A LIB file allows Windows to do all that for you when your EXE is started (including finding which DLL to use, and recursively loading dependent DLL's), linking the dynamic library statically at run time, while avoiding bloating your EXE file with the executable code, and allowing several processes to share the same DLL image in memory.
I don't know about the config mismatch, but a .LIB file when created with a .DLL library is an "export library" - it doesn't contain any code, but just the names of the callable functions and objects in the DLL. The linker uses this to satisfy references at link time which are finally resolved by dynamic loading at run-time.