I'm trying to use GLC library in Visual C++. I download already built version. The library(libGLC_lib2.a) is in ar format. I tried to add libGLC_lib2 or libGLC or libGLC_lib2.a in Visual C++ project properties, but linker gives unresolved external symbols: can't find the library. So is it possible to specify libraries with ar format in Visual Studio?
P.S. The examples within library are Qt based and the library specified with the option -lGLC_lib2
Visual C++ doesn't use .a files for providing the definitions of DLLs, typically it uses .lib files. The library linking convention you referenced (-lGLC_lib2) is more consistent with GCC command-line arguments, which would explain why the pre-built binaries you downloaded had a .a file instead of a .lib.
In order to use this library with Visual Studio, you'll likely need to rebuild it from source.
Alternatively, you may be able to produce a .lib file from the pre-built binaries. see the following article for more information on how this can be done: http://www.mingw.org/wiki/MSVC_and_MinGW_DLLs
Did you set the 'Additional Library Directories' in the linker settings as well as adding the library.
Related
I am trying to create a C++ project in Visual Studio 2013 that has CGAL and Boost (and a couple of other libraries) as dependencies. I preferably like to link to these libraries dynamically. Also, I'd like to link to the "Release" versions of these libraries for performance reasons (not the "Debug" versions).
Starting from an empty C++ project, I added the path to header files of the aforementioned libraries as shown in the image below:
Inside the linker options, I then added the directories that contain the DLL and lib files of the external libraries. (CGAL directory contains CGAL's compiled DLL files along with lib files).
At this point, I have not added a single "lib" file "Additional Dependencies" dialog:
Now something weird is going on and I cannot explain why. If I try to build the project as-is (under the "Debug" configuration), I get a LNK1104 error about the linker not being able to find CGAL-vc120-mt-gd-4.7.lib. I know that the error means I should add the lib file in "Additional Dependencies" dialog...
But wait... WHAT...?!!
How does Visual Studio know how to automatically link against this lib file?! Worse yet, how does it know it needs the "debug" version of the library? (With the gd suffix). Also, how does it know I compiled CGAL with VS2013!!??
At first, I though the project was inheriting properties from some preset property sheets somewhere in my system. But I am certain that's not the case as this behavior shows even with a project created from scratch.
My main question is, how would you force Visual Studio to link against the "Release" version of this library? (eg. CGAL-vc120-mt-4.7.lib)
Side question but related: Am I even linking against the DLL files? How can I be certain that I am in deed doing dynamic linking and not static linking?
This is probably happening due to the #pragma comment(lib) mechanism - eg see What does "#pragma comment" mean?
This is a way of the compiler emitting instructions for the linker so that it can decide between multiple versions of a library depending on the compiler version. In this case it means that it can automatically pick up the correct version of the library (debug vs release, vs2013 vs vs2015, MT vs MD, etc). When you added the explicit reference to the library in Additional Dependencies then it is now trying to look for two files.
So, to fix the problem, remove it from Additional Dependencies and let VS pick the right library. If you are getting the LNK1104 error then it suggests that either the link library path isn't set up correctly, or you don't have the CGAL library file it's looking for. You can increase the verbosity settings for the linker in the Project Options to get more detail about what's happening.
I have a problem using boost.asio. I use Windows XP and Visual Studio 2005
I followed these steps:
I downloaded the latest version (http://sourceforge.net/projects/boost/files/boost/1.46.1/) of W: \boost_1_46_1
I set the environment variable INCLUDE : W:\boost_1_46_1
In the properties of my project (VS->tools->Options project&solutions->vcc++directories) I added $(INCLUDE)
I added in my file. h this:
I get the following error:
LINK : fatal error LNK1104: cannot open file 'libboost_system-vc80-mt-gd-1_46_1.lib
This is a linker error. Find the lib, and go to linker input, and add it there. Be sure to set the libpath as well. This picture should guide you:
The boost::asio library needs to be built. ( Many other boost 'libraries are headers only and do not need to be built ). Building it yourself is a small challenge. Better to use the pre-built binary installer which is here
Once you have the built libraries, one way or another, you have to tell the linker where they are. However, you do not need to specify each individual library by name, just specify the folder that contains them. The easiest way to do this IMHO is to create an environment variable called BOOSTROOT which you you set equal to the folder where you installed boost. Then you tell the linker to look for libraries in $(BOOSTROOT)/lib
I'm using Visual Studio C++ 2005 on Windows XP.
I have created a DLL shared library using Visual Studio C++ 2005.
However, I am not sure how to link it. Normally I have just created the static libraries (*.lib).
Do I link the same way I would when linking a library. By using the properties C/C++ and linker general properties and selecting the path for the headers and library paths?
Many thanks for any advice.
When you create the DLL there should be a .lib file created for the purpose of dynamic linking. You can use these just as you would static .lib files.
This article explains Windows dlls well.
The .LIB file associated with a DLL
describes what (exported) symbols are
present in the DLL, together with
their locations.
To put it simply:
When you link: you Need Lib, not DLL
When you run it: you need dll, not lib (Put the DLL with your executable)
How do you specify, in Visual Studio 2010, the order in which library files should be linked?
I have a project that links against libexpat and against another library. This library (not under my control) seems to also include libexpat. The problem is that 'we' use a different version of the library (XML_UNICODE vs not). In Visual Studio 2008 things seemed to work out okay (might have been a coincidence), but in Visual Studio 2010 the wrong instance of libexpat is linked. I was thinking that if I could specify the order in which these two libraries should be linked that then I could circumvent the problem.
A few years back I discovered a hack that allows you to force Visual C++ to link libraries with a specific precedence. This is not elegant, but it is functional.
It seems that the linker for Visual C++ generates link order on the fly based on symbol dependencies. By adding a symbol reference up-front, you can force the linker to include the first library specified in the linker input. Please note, I have only tested this with Visual C++ 6 and 8 (2005).
Let's say for example that you have two libraries with the symbol XML_ParserCreate:
libexpat.lib - XML_ParserCreate
someother.lib - OtherSymbolsYouNeed, XML_ParserCreate
First, order your library dependencies as you would expect, libexpat.lib and then someother.lib. Via command line these would be options to link.exe. In Visual Studio 2005, they would be options under the project's Configuration Properties -> Linker -> Input -> Additional Dependencies. I would imagine Visual C++ 2010 has a similar menu.
Next, add a command line option that defines a known repeated symbol up-front, by using the /INCLUDE linker option. In Visual Studio 2005, this can be added under the project's Configuration Properties -> Linker -> Command Line -> Additional options:
/out some.exe ... libexpat.lib someother.lib
/include:XML_ParserCreate
The definition of this symbol will cause the linker to immediately prefer the first library that terminates (realizes) it. In general Visual C++ will generate an error with repeated symbols; if you haven't already, make sure you are also specifying the /FORCE:MULTIPLE linker option.
My specific need for this was using the DUMA memory debugging library. It defines a variety of memory functions that are also defined in libcmtd.lib. The following would incorrectly link libcmtd's version of _malloc, despite a library order that seems to the contrary:
/out some.exe ... duma.lib libcmtd.lib
/FORCE:MULTIPLE
This was resolved by manually adding the symbol, and has worked reliably for years:
/out some.exe ... duma.lib libcmtd.lib
/INCLUDE:_malloc /FORCE:MULTIPLE
I have found 'a' solution: if you add the libraries through #pragma comment(lib... the order of linking is the same as the order in which you type those pragma's. I'm still keeping the question open for a solution when the libraries are added through the project file instead of through pragma statements.
You could create a DLL with the third party library and link it against the static version of expat that it needs and then link your code against the version of expat you need.
However, the fact that it worked before might mean that one library has all the functionality of the other plus some extra. I don't know the details of expat. If that is the case, you need to make sure that you only have the version you want to use in your library search path. A different search directory order in the other version of the compiler could explain the change in behaviour.
I think you can change the order in which library files are linked bij adding them in the project file in linker -> input -> additional dependencies. The library files will be linked in the order in which they are specified.
A library can be used in an application in two ways:
Statically-linked
Dynamically-linked
But how to do that using both Visual Studio (windows) & GCC?
I know libraries are distributed only in these 4 ways:
Source
header-only libraries
*.lib files for windows. *.a for linux
*.dll (windows) & *.so (linux).
Source distribution is just compiled."header-only libraries" are nothing but a source distribution.
Now if the desired library is distributed in *.lib form. Inorder to use it.
On Visual Stuido :
We add directory path containing headers(*.h) to Configuration Properties > General > Additional Include Directories
we add each *.lib file to Configuration Properties > Linker > Input > Additional Dependencies
we add directory path of *.lib files to: Configuration Properties > Linker > Additional Library Directories
How to do the same thing for GCC/MingW?
I don't know how to build my application when the library is distributed as *.dll or *.so too. Can someone tell me what do I need to do in these situations for both Visual studio (windows) and GCC(linux)/mingw(windows)
On GCC, for static linking, you'll include the library in the command line. Lets say you've glib-2.0.lib and your program that uses GLib library is my_prog.c, then you invoke GCC as
gcc my_prog.c -L<library_dir_here> -lglib-2.0.
As for the dll and so, dynamic libraries are something you don't link to your programs by passing them to your linker. Instead the operating system gives you a function to load them when it's required, at run time. Thats the reason it's called dynamic. In Windows you've LoadLibrary and on Linux you've dlopen. Both these functions get a string (which is the dll or so's name) and load it if it's avaiable on the machine. Once it's loaded, the function you require from the library is looked-up by passing its name to GetProcAddress on Windows and dlsym on Linux; both returns a function pointer, with which you can call that function. Since you're not directly calling the functions provided by the libraries directly, but thru' function pointers, there'll be no need for you to link them statically (i.e. pass them to the linker) when you build your app.
For DLL distributions the scenario is similar to that of .lib files. (your #3)
You will have to configure your project to build a DLL. The project will build LIB and DLL files.
Depending on your needs/architecture/design you can either
Link against the LIB file just as you do in your #3 above. Note that the DLL file will have to exist on the target machine at run-time otherwise the application will not load.
Call "LoadLibrary()" from the client app and skip the linking part/no need to have the LIB used in the client application.
I can't help you with the gcc specific questions.