I'm developing an application at work using C++, Qt, Mingw32 and Netbeans. I need to use an in house API that has been developed by the software group in the company.
I have the symbol libraries .lib files for the DLLs i need to link against, but i cannot use these libs with Mingw32, it works fine with Microsoft Visual Studio.
Does anyone know if there is a way to export the symbols and create a .a symbol library that works with Mingw32 ? If not i'll have to go over to Visual Studio i guess.
I have tried using the program "pexports" to create a .def file and dlltool, but that didn't work. Still got unreferenced symbol errors, then i added the symbols it complained about to the .def, because they weren't there and it stopped complaining and compiled. But the program crashes. I tried the same code in Visual Studio and it compiles and runs fine.
Have you considered dynamically loading the DLL? LoadLibrary, GetProcAddress, etc. You can probably easily write a class that encapsulates all the DLL's entry points, loading and unloading the library, and does all the #typedefs, etc. It's grunt work but if it's an in-house library there probably aren't too many entry points?
Import libs are overrated. :p
Not sure if it helps, but you may wish to check this guide.
Here's how I did that for the mysql library.
Create a list of exports using dllwrap:
dllwrap --export-all-symbols --output-def libmysql.def libmysql.dll --implib liblibmysql.a
This creates a list of exports in the .def file but the name mangling is incorrect.
Edit the .def file in a text editor and remove the '#' symbols.
The symbol names typically also have a number appended to them as well.
I don't know how to determine the correct name except by experimentation:
Run the following to create a netbeans compatible library:
dlltool --input-def libmySQL.def --dllname libmySQL.dll --output-lib libMySQLclient.a -k
Compile with it and you'll get undefined symbols. The undefined symbols will have the correct decorations.
Edit the .def file again and correct the symbol names. Re-run dlltool to get the correct .a library file.
Have you tried linking the DLL directly, rather than a .a/.lib? MinGW is usually happy to do that for you.
I give up, some people say it is not possible with a dll compiled on microsofts compiler with c++ exports, because of the name mangling
Related
How to sqlite3 dll without use? I'm imported sqlite3.h and sqlite3.lib, and error sqlite3.dll not found. Need run without sqlite3.dll.
This is not how it works. If the .lib is compiled to be dynamically linked then it just exports the list of symbols available inside the dll but the code still resides inside the dll.
If you want to avoid using dll, you need a static version of the library, I don't know if it's already provided by sqlite, otherwise you need to compile it yourself, this could help you.
As far as I know sqlite3 is a single source file. Just add it to your build and you should be golden.
While using C++ in Visual Studio 2013, I've come across a really weird warning/bug thing.
I have a static library and a console application.
Static library imports 4 3rd party .lib files, and their headers.
Console application imports the static library and the headers of the original 4 .lib files, so that I can use the code from the original 4 .libs and my .lib.
(I think this is the right setup in this situation, if there is a better way, do tell!)
However, when I build the static library, I get a warning: "LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library" for each .lib imported.
But where is it getting the code if not from the libraries? If I remove the .libs from being imported, the build fails stating that it needs them! I don't know what to do in a situation like this. I would be happy enough to just leave the .libs being imported as is and ignore the warnings, but when I try to disable them (Under disable specific warning, "4221", in the compiler options), the warnings are not disabled!
Edit: The 4 3rd party .libs are standalone - they do not use each other's code so I do need to import all of them.
I am truly at a loss - any advice would be much appreciated.
I found a way of disabling the warnings using /ignore: on the linker command line, but I'm still confused as to why the linker gave the warnings in the first place, when removing the library as input caused multiple "unresolved external symbol" errors.
Oh well, problem (sorta) solved.
I'm working on a cross-platform c++/qt project with a plugin system, we are using so files on linux and dll on windows. We are using gcc on Linux and Visual Studio 2010 on Windows through cmake.
The problem is our plugins sometimes need to call a function from the application source code, which is working fine on Linux with gcc by just including the header files. But on Visual Studio, we got unresolved external symbol errors.
Is it because so and dll files works differently?
thank you.
The default behaviour for exporting symbols from dlls on Windows is exactly opposite: by default, symbols are invisible, you need to export them explicitly. With VC++ this is done by __declspec(dllexport) declarators.
EDIT (Information added): You are entering a region of non-standardized, system specific behaviour... There are much more problems associated with writing cross-platform "pluggable" component systems in C++ than you might be expecting. On Windows there are so called import libraries, which define all symbols exported from a dll. You have to link against these libraries in order to resolve these symbols. This is called implicit linking. You can also link explicitly which means loading dll and its exported symbols at run-time. However all these are just technical details compared to so called binary compatibility issues, which will almost certainly kill you, if not considered during the design of your component system.
I am wondering about one thing: You said you're using Qt. Qt application framework has got it's own cross platform conventions and rules for writing and building pluggable components. Why don't you stick with these...?
I made a program on Mac OS X using OpenGL and dynamically linking libpng. I'm now trying to port it to Windows. Whenever I try to compile and link my ported program in Borland it gives me this error and about 10 more that are the same, but with a different '_png_create_read_struct':
Error: Unresolved external '_png_create_read_struct' reference from C:\PROGRAMMING\PNGTEST.OBJ
I assume it's because I have not properly set up libpng with Borland C++ 5.5.1 for Win32. I've put png.h and pngconf.h into the include folder into C:\Borland\BCC55\Include, and I have put libpng12.dll.a, libpng13.a, libpng13.dll.a, libpng.a, libpng.dll.a, libpng12.def, libpng.def, libpng12.la, and libpng.la into C:\Borland\BCC55\Lib (there is probably no need for them all, but as a noob I have no idea which ones are needed and not).
Do I need to put a libpng.obj file in there too? And if so how would I make/get one? I have tried using makefile.bc32 to set up libpng, yet that gives me a missing separator error.
Here are my command-line options:
bcc32 -tW pngtest.cpp -lpng
I include png.h in my code. What am I doing wrong or is there an even better way to load images with alpha that doesn't need libpng, or even a better compiler to get for Windows?
You're probably better off with the MinGW compiler than Borland. Borland is not well supported any longer.
You could also download DevC++ and see if it has a libpng package in its addon mechanism.
DevC++ is an IDE that uses the MinGW C/C++ compiler.
That said, if you feel you must use BCC, you'll either have to
a) Build libpng with Borland. This is the best solution if you're going to use borland.
b) Use, I think, Impdef to create an import library from libpng.dll. You'll find impdef.exe or imp(something).exe in the borland bin directory.
Note that some libraries will not work with impdef as there is static code linked to the dll that causes it to fail without the proper runtime.
First of all, I would not have "polluted" the BC55 installation with third-party libraries; it will make moving the project to other build environments much more difficult. It would have been better to place them in a folder within your project.
Secondly do you know that the export library you are attempting to link is built for BC55? The .a extension suggests a GNU library (Borland libraries conventionally use .lib extension), in which case it would not link with BC55 which uses a different object file format. If this is the case you will need to rebuild the library as you attempted to do, so I suggest that you should really be asking a question about the problem you had with doing just that. I wonder whether the makefile is written for Borland make or GNU make, since they have differing syntax?
The command line option -lpng might be correct for GCC (where it will link libpng.a), but is meaningless to BCC. The -l option merely passes the text that follows to the linker. The linker command line, requires that the complete name be passed, and if no extension is provided, .lib is added implicitly.
You should probably just use coff2omf to convert the library. The DLL files are almost certainly in "Microsoft" COFF format.
See COFF2OMF.EXE, the Import Library Conversion Tool.
I'm in the process of porting a large C++ application from Linux (gcc) to Windows (Visual C++ 2008) and am having linker issues with plugins. On Linux this wasn't an issue, as .so supports runtime symbol lookup, but dll does not seem to support this.
Some background information:
The application (the host), which hosts a scripting environment, provides interfaces to plugins (shared libraries that are loaded at runtime by script API calls), allowing the host and the scripting API to be extended without recompiling the host application. On Linux this is just a matter of including the host application's headers in the plugin source, but on Windows I'm receiving linker errors. I'm not sure exactly what I need to link with for Visual C++ to resolve these symbols.
One of our dependencies (open source, LGPL) has preprocessor declarations that it uses to insert __declspec(dllexport) and __declspec(dllimport) into it's headers. Some prior research indicates that I may have to do this as well, but I'd like to be sure before I go modifying a whole bunch of core headers. (I was previously able to get this working on MinGW, but we've decided that supporting Visual Studio is a requirement for this sort of commercial project.)
My question, in a nutshell: How do I link runtime-loaded dlls against a host exe in Visual C++?
Edit: To clarify the problem with an example, I have a class in my host application, Object, which represents the base type of an object that may be accessed by a script. In my plugins I have a number of classes which extend Object to perform other functions, such as integrating networking support or new visual elements. This means that my dll must link with symbols in the host exe, and I am not sure how to do that.
What do you mean by "runtime symbol lookup"? Do you mean dynamically loading libraries using dlopen and dlsym and so on? The equivalents in Windows are called LoadLibrary and GetProcAddress.
In windows, you don't export symbols from a executable. You should only export them from a dll. The right way to solve your problem is to rearchitect so that the exported symbols are in a dll that the executable and other plugin dlls can link against.
You can't, easily. The windows loader isn't designed to export symbols out of an EXE and bind them to symbols in a DLL.
One pattern that I have seen is the DLL export a certain function that the EXE calls. It takes as a parameter a structure which contains addresses of functions in the EXE for the DLL to call.
I have been implementing the same, constructing a plugin library to build under both Linux and Windows.
The solution under Linux is to use the -rdynamic option in the gcc command line. This exports all of the symbols in the main executable, so that a plugin can find them on loading.
Under Windows, the solution is to add __declspec(dllexport) in front of the definition of those functions in the exe that you want the dlls to use. Compilation will create a .lib file for the dlls to link to. Certainly works under Visual studio 2008.
Related post: https://stackoverflow.com/a/3756083/1486836
As 1800 INFORMATION says, don't do it like that. Move Object out of the executable and into a "third" DLL. Link the plugins and the executable against that.