I'm trying to test out a library that provides a VC++ example; however, I use gcc/g++ for all of my projects.
Well, the way the VC++ example accesses the library is it uses the #import directive, passing the location of the library DLL, then it does a using namespace LIBRARYNAME, and then it's able to create some undefined type (I'd assume it's defined in the DLL) and create a new instance of it with __uuidof. From then on, to call one of the library functions the example just does a createdObj->foo() and that's that.
Well... g++'s #import is different from VC++'s import (see here), so this example won't work for me.
Is there any way this can be converted to compile under g++, or am I SOL until the library developer provides me with a static library I can try out?
If you are using cygwin, then this page: http://www.cygwin.com/cygwin-ug-net/dll.html will provide you with all the help you need.
If you are using mingw, you can accomplish the same thing, but you probably won't have grep and sed, so you'll have to use some other method of doing the filtering to get your .def file.
If you were using #import in VC++ it means the DLL isn't a regular DLL, it's a COM DLL.
Since gcc doesn't have COM support, you'll just have to wait for the library author to write a non-COM version.
Maybe it could have helped you to use the OLEViewer and "View type information" to extract the basics of the IDL. Or maybe you could just use the VC++ generated .tlh and .tli files and import them into your G++ project.
I guess this answer is way too late, but right now I'm encountering similar issues myself so I just got into this thread. Hope you found the solution on time.
Regards.
Related
I've created a managed C++ log parser application using C++ vectors and Winforms. I want to add multithreading and Boost seemed like a better option than Winforms BackgroundWorker because I want to be able to execute my existing C++ function with each thread. I installed Boost multiple times following multiple different tutorials (lastly this one: https://levelup.gitconnected.com/the-definite-guide-on-compiling-and-linking-boost-c-libraries-for-visual-studio-projects-c79464d7282d) and I still have the same issue when I try to #include <boost/thread.hpp>
Error LNK1104 cannot open file 'libboost_thread-vc143-mt-x64-1_78.lib'
I don't know why it's looking for this library when I have Boost 1_79 installed not 1_78. My .lib file also has "mt-gd-x64" not just "mt-x64". I've already specified the correct file path to the library in Project->Properties->Linker->General->Additional Library Directories. I've also tried installing Boost via Visual Studio 2022 NuGet Package Manager. The lib file in that folder is also slightly off. "vc120" instead of "vc143". I've even tried changing the .lib file name to match the file name in the linker error exactly but when I do that I get more errors like LNK1104 cannot open file 'libboost_chrono-vc143-mt-x64-1_78.lib'
Do I just need to delete all my Boost files and download version 1_78 and try again? Why is Visual Studio looking for the wrong file name when it compiles? Is my #include statement wrong?
I ended up solving this problem by downloading boost 1_78, building it, and specifying that folder instead or the 1_79 folder. If anyone might know why the program was looking for 1_78 instead of 1_79 feel free to respond Also big thanks to George Gkasdrogkas who wrote the tutorial that worked best for me on how to install Boost. Tutorial is linked in the question :)
I've looked around (including StackOverflow), but the only question close to mine, as far as I can tell, is specific to Windows distributables, which doesn't apply to me.
I want to release a library: MyLibrary.lib
It uses some third-party libraries, for instance, ZMQ
I've included the third-party library into MyLibrary both with either #pragma or actually adding it to the project.
Either way, MyLibrary.lib compiles fine and creates a .lib file
HOWEVER.
An executable that is linked to MyLibrary complains at link time that it can't find the referenced ZMQ functions, as if ZMQ is not incorporated into MyLibrary.
Looking at MyLibrary with a hex editor it doesn't seem like ZMQ.LIB was incorporated. There are references to it but it seems "weak linked". I don't see the ZMQ code in there.
Alternatively, if I can get the application/executable to build and run it, it'll complain at runtime that it can't find zmq.dll.
Either way, it's obviously not in "MyLibrary".
How can I get a library to include other third-party libraries, so I don't have to distribute a bunch individually? What step am I missing?
Using MSVC2013
Thanks
Although I had the .lib I needed, it turns out it was an import lib, and the .dll was distributed elsewhere. I found the .dll and now it works. Thanks to all who responded.
What about the flags described in this article:
https://msdn.microsoft.com/en-US/library/2kzt1wy3%28v=vs.120%29.aspx
Can they help you?
I'm trying to build my application with MSVC 2010 instead of GCC. With GCC everything works fine. My app uses boost_system and boost_thread libraries.
I built boost with VC2010 in "system" layout, that means the libraries are named just libboost_system.lib (and not libboost_system_compiler_threading_version_wtf_snafu.lib)
The libs reside in C:\Boost\lib,
the Makefile specifies
LFLAGS = /NOLOGO /INCREMENTAL:NO /SUBSYSTEM:CONSOLE
LIBS = /LIBPATH:C:/Boost/lib libboost_system.lib libboost_thread.lib Ws2_32.lib
when invoking nmake it compiles, but when trying to link it quits with
LINK : fatal error LNK1104: cannot open file 'libboost_date_time-vc100-mt-1_43.lib
I mean seriously, WTF? I told it to link libboost_systen.lib and libboost_thread.lib how come it tries to link libboost_data_time and why does it assume I built the libs in "tagged" layout??
How can I stop MSVC trying to be smart and guess what I might have wanted to link?
Thanks,
Philipp
This is a feature of the Boost libs with compatible compilers for automatic linking.
(Those convoluted library names cover the myriad of threading and linking options that are available on the platform; there are good reasons to use that convention on Windows...)
More information here:
http://www.boost.org/doc/libs/1_33_1/more/getting_started.html#auto-link
I can't find a page for a more recent version, but I believe the BOOST_ALL_NO_LIB and related options are all still valid in 1.43.
Assuming you are auto-linking (i.e. you've defined BOOST_ALL_DYN_LINK or library specific equivalents).
For layout 'system' you have to define the preprocessor macro:
BOOST_AUTO_LINK_NOMANGLE
to link to the correct library names.
For layout 'tagged' you have to define the preprocessor macro:
BOOST_AUTO_LINK_TAGGED
to link to the correct library names.
I don't know if you could do this override for some libraries and keep the default for others. That would be a very cumbersome setup I'd imagine.
I don't know if it's possible to do this, but I would like the /NODEFAULTLIB to be applied to a static library project.
I have many application projects (A.exe, B.dll, C.dll) that use a common static library D.lib.
This library has a lot of code and also has other .lib dependencies as well. One of them is the openssl library, which seems to have been built for win32 against the Release version of the CRT (i don't have the original project/sources).
So far, to avoid the mixing of the Release/Debug versions of CRT, I have to put the /NODEFAULTLIB:msvcrt.lib linker directive in all leaf projects (A.exe, B.dll). This works but I think it's not the ideal way of dealing with that issue.
I tried to put this property in D.lib project, but it has no effect.
Is there a way to force msvc++ to ignore the msvcrt.lib dependency from the 3rd party library?
A .lib does not have any linker settings because you don't link it, you link to it. A .lib is just an archive of .obj files, sort of like an uncompressed .zip file - that's why you have to put the setting on all projects that link to it.
If you're using VS2005+ you could use property sheets so that you only have to put the setting in one place and then use that property sheet in all projects.
However, OpenSSL is just that - Open Source, so you should be able to get the source for the version you are using and build it again (and add it to your version control system of course). I thought OpenSSL could be built as a DLL or LIB, which would solve your problem as the DLL would not interfere with the linking of your code.
Failing that, you always have the option of slitting your functionality out into a separate DLL so that you only have issues with one project.
To prevent your distributed static link library from depending on a specific MSVC runtime library you need to set this compiler option (in Visual Studio 2010 it looks like):
Configuration Properties -> C/C++ -> Advanced -> Omit Default Library Name = Yes (/ZI)
Now your users can link to your release built static lib from their debug build and not try to link to the incorrect runtime library causing problems, as well as linkers warnings.
Note that may cause link errors if your library actually depends on a specific runtime library or its behavior, and compatible components are not provided in some other way.
My understanding is that if library LIB in linked statically into a DLL, the DLL contains already all relevant code from LIB. Therefore, this coupling cannot be removed. This is just based on my understanding of statical linking, not on experiments.
I'm just looking for a simple, concise explanation of the difference between these two. MSDN doesn't go into a hell of a lot of detail here.
__declspec( dllexport ) - The class or function so tagged will be exported from the DLL it is built in. If you're building a DLL and you want an API, you'll need to use this or a separate .DEF file that defines the exports (MSDN). This is handy because it keeps the definition in one place, but the .DEF file provides more options.
__declspec( dllimport ) - The class or function so tagged will be imported from a DLL. This is not actually required - you need an import library anyway to make the linker happy. But when properly marked with dllimport, the compiler and linker have enough information to optimize the call; without it, you get normal static linking to a stub function in the import library, which adds unnecessary indirection. ONT1 ONT2
__declspec(dllexport) tells the linker that you want this object to be made available for other DLL's to import. It is used when creating a DLL that others can link to.
__declspec(dllimport) imports the implementation from a DLL so your application can use it.
I'm only a novice C/C++ developer, so perhaps someone's got a better explanation than I.
Two different use cases:
1) You are defining a class implementation within a dll. You want another program to use the class. Here you use dllexport as you are creating a class that you wish the dll to expose.
2) You are using a function provided by a dll. You include a header supplied with the dll. Here the header uses dllimport to bring in the implementation to be used by the current program.
Often the same header file is used in both cases and a macro defined. The build configuration defines the macro to be import or export depending which it needs.
Dllexport is used to mark a function as exported. You implement the function in your DLL and export it so it becomes available to anyone using your DLL.
Dllimport is the opposite: it marks a function as being imported from a DLL. In this case you only declare the function's signature and link your code with the library.