Library architecture i386 ist not compatible with target architecture i386:x86-64

[tim5]

Hello,

I would like to link my dll into my QT-Project (dynamic). I am using the QT5.15.2 MinGW 64-bit Kit.

The error, when debugging following code is:



Shared library architecture i386 is not compatible with target architecture i386:x86-64.
"Cannot load library GP_MUC.dll: Unknown error 0x000000c1."


After researching I found out that a i386 architecture means that my dll is a 32 bit dll. And since I am running my project with a 64-bit compiler I am not wondering anymore. But I could just not find a solution on the internet for this. Do I need to run my QT-Project with a 32bit Compiler or is there a chance using this 32 Bit Dll in my 64bit compiled QT-Project.

I am using this code for loading my dll into my project.

main.cpp:


#include "mainwindow.h"

#include <QApplication>
#include <QLibrary>
#include <QDebug>

int main(int argc, char *argv[])
{
QApplication a(argc, argv);

if (QLibrary::isLibrary("GP_MUC.dll")) {
QLibrary lib("GP_MUC.dll");
lib.load();
if (!lib.isLoaded()) {
qDebug() << lib.errorString();
}

if (lib.isLoaded()) {
qDebug() << "success";

// Resolves symbol to
// void the_function_name()
typedef int (*FunctionPrototype)();
auto function1 = (FunctionPrototype)lib.resolve("MUX_Version");


// if null means the symbol was not loaded
if (function1) function1();
}
}

MainWindow w;
w.show();
return a.exec();
}





Maybe you can help me with giving me a hint or even giving me an example of how to do it.

Kind regards
Tim

[d_stranz]

Is the DLL yours or something from an external source? If it is yours and you have the source code, just add a 64-bit configuration to the project if it isn't already there and build that configuration. If it is not yours and you only have a 32-bit binary version, then you are probably stuck with making your program 32 bits as well. See this Stackoverflow article for workarounds (https://stackoverflow.com/questions/2265023/load-32bit-dll-library-in-64bit-application).

Typically, you don't use LoadLibrary to load a DLL at run time. Instead you link the executable with the .lib export library that is produced along with the DLL and let Windows take care of loading it. The major exception is if you are developing some sort of plug-in architecture where you do not know the DLLs you will be loading at build time and must load them dynamically at run time.

By the way, all 64-bit compilers I know of can also produce 32-bit binaries with the right compile and link flags.

[tim5]

Is the DLL yours or something from an external source? If it is yours and you have the source code, just add a 64-bit configuration to the project if it isn't already there and build that configuration. If it is not yours and you only have a 32-bit binary version, then you are probably stuck with making your program 32 bits as well. See this Stackoverflow article for workarounds (https://stackoverflow.com/questions/2265023/load-32bit-dll-library-in-64bit-application).

[QUOTE]
The DLL is from an external source/ company. I am creating a program for this company. I think I can ask them to add a 64bit Configuration.

I've already tried making my program 32 bit. Now I have a LNK1107 Error - invalid or damaged file: reading at 0x2E0 not possible. :(

I will have a try with the workarounds.



Typically, you don't use LoadLibrary to load a DLL at run time. Instead you link the executable with the .lib export library that is produced along with the DLL and let Windows take care of loading it. The major exception is if you are developing some sort of plug-in architecture where you do not know the DLLs you will be loading at build time and must load them dynamically at run time.



But I only have the DLL (and know about the functions within) I do not have .lib .h or .a files. I read that because of that I have to use LoadLibrary.



By the way, all 64-bit compilers I know of can also produce 32-bit binaries with the right compile and link flags.




Thanks a lot for you support.

[d_stranz]

The DLL is from an external source/ company. I am creating a program for this company. I think I can ask them to add a 64bit Configuration.

Then also ask them to provide you with the corresponding .lib file -and- the header files that define the exports from the library. Seems sort of ridiculous that a company would contract you to write code and then tie your hands behind your back. If they are creating the DLL, then they should certainly know enough to understand what is required to write code that uses it.

[ChrisW67]

In some circumstances you can generate the link library (blah.lib) to match a DLL (blah.dll):
GenerateLibFromDll (https://wiki.videolan.org/GenerateLibFromDll)
This uses the Microsoft tools.
You will still need the matching headers.

The OP indicates that MingW is being used as the tool chain in this thread, but provides a linker error message that looks to be coming from a Microsoft tool chain in the other thread on this same topic.

[d_stranz]

The OP indicates that MingW is being used as the tool chain in this thread, but provides a linker error message that looks to be coming from a Microsoft tool chain in the other thread on this same topic.

I think DLLs should be compatible no matter what build tool chain is used. It's the export libraries and other binary things that may not be. I believe that each compiler mangles names differently, so you will get linker errors if you try to link a binary from MingW with another produced by Microsoft if one uses definitions from the other.