Member Avatar for richardtreier

Alright. I am (attempting) to use this http://sites.google.com/site/rcorcs/download/systemsoftware simple database library in VC++ 2008 Express. I admit that I am a newbie to C++, since Ive used only "light" programming languages like python, php, java.

To use it I have the header files, and as "lib" folder I have a dll and a ".a" file. In a project before I used a .dll and a .makefile file to create a .lib, but this time I dont know what to do anymore. I have found out that the ".a" in linux is the equivalent of a ".lib" in windows, but I have not found any way to use it in VC++.

Could somebody please tell me what to do in order to be able to use this library(In VC++ 2008 ofc)?

  • 4 Contributors
  • 4 Replies
  • 127 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by mike_2000_17

Dani AI

Generated

The replies so far are on the right track: flagged the platform mismatch, pointed out that *.a import libs come from the GNU toolchain, and outlined the useful options (C-compatible exports, making an MSVC import library, or runtime loading). Below are practical, concrete next steps and pitfalls to watch for.

First, confirm the DLL is usable from MSVC:

  • Check bitness (32 vs 64) and exported symbols. From a Visual Studio command prompt use dumpbin /EXPORTS your.dll or open the DLL in a GUI viewer (Dependency Walker / Dependencies) to see exported names and whether they look decorated.

  • If the exports are plain C-style names (no C++ mangling) and the DLL is the same architecture, you can create an MSVC import library. Create a .def that lists the exports and run lib to produce a .lib:

    dumpbin /EXPORTS rcorcs.dll > exports.txt
(edit rcorcs.def with EXPORTS lines)
lib /def:rcorcs.def /out:rcorcs.lib /machine:x86

  • If lib.exe or dumpbin are missing, install the Windows SDK or use the VS command prompt that includes the tools.

If creating an import library is impractical, load the DLL at runtime and get entry points by name. Example pattern:

typedef int (*OpenFunc)(const char*);
HMODULE h = LoadLibrary("rcorcs.dll");
OpenFunc openf = (OpenFunc)GetProcAddress(h, "open_database");
if (!openf) { /* inspect GetLastError or exports */ }

Important cautions:

  • If the library exposes C++ classes, templates, STL types, or throws C++ exceptions across the boundary, mixing MinGW-built DLLs with MSVC callers is unsafe; in that case rebuild the library with MSVC or use MinGW to build your app.
  • Pay attention to calling conventions and name decoration (stdcall vs cdecl changes exported names). If symbols look decorated, match the prototype or use ordinals.

If rebuilding is an option, compiling the library with your toolchain is the cleanest fix.

Recommended Answers

All 4 Replies

Member Avatar for deceptikon

If it's not a library that was built for Windows, you won't be able to use it.

Member Avatar for Ancient Dragon

libraries with *.a extension were produced with GNU compiler, such as g++ on *nix and MinGW on MS-Windows. They are not usable with Microsoft compilers.

Edited by Ancient Dragon because: n/a
Member Avatar for richardtreier

Ok. Thank you, I will try to build it on my own then.

Member Avatar for mike_2000_17

Depending on the way that the DLL was compiled, it might be possible for you to use it from a VS2008 project.

The easiest solution, of course, is to contact the issuer of the library in question and ask for a VisualC++ import library (or the source code so that you can recompile the DLL yourself). If they don't want to bother providing that, then, besides cursing at them or considering finding another library with similar capabilities, you can read further.

First of all, the dll was compiled with MinGW (almost certainly). The .dll file contains the actual code and the .a file is called an "import library" (and the "a" stands for "archive" which is GNU jargon for "static library").

Second, all DLLs are not the same. The main thing that can be different is the name-mangling (which is a kind of encoding of the names of the functions) which is different from one compiler to the next (but usually, each compiler-vendor adopts some convention that make libraries compiled with different versions of the compiler compatible with each other). Generally, the name-mangling of one compiler(-brand) is not compatible with the name-mangling of another. Fortunately, the name-mangling can be disabled by specifying that the functions (and the library) should be compatible with or callable from C code, because C doesn't have or need name-mangling. So, if the functions in the headers (whose code are in the DLL) are all declared with extern "C" or within a giant extern "C" { .... } , then it means that you should able to use those functions from pretty much anywhere (any C++ compiler, C compiler, or even Python or others). If it is not the case, then you will not be able to use that library from a VS2008 project.

So, at this point, if all the DLL functions are C-compatible, then all you need is to generate an import library for the DLL. This could be a tedious process if there is a large amount of code, but essentially, you can follow . If that fails, you can try to use the functions by loading them at run-time (which doesn't require an import library), see this page.

If the above is prohibitively long to do, then the only solution remaining is to switch to MinGW for your project, or find another library instead of that one. To use MinGW, you can also use the IDE which will install MinGW too.

Edited by mike_2000_17 because: n/a
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.