Building DLL in Visual Studio with Static Linking to QT

mlathrop

Hi there!
I am trying to build a DLL in Visual Studio that uses some QT functionality. I don't want users of the DLL to have to link against the QT DLL as well so I built QT statically and selected that version of the QT library in visual studio. However when I build the library it still lists QT as a dependency in dependency walker and gives an error message at run time saying

The procedure entry point ?toLocal8Bit@QString@@QEGBA?AVQByteArray@@XZ could not be located in the dynamic link library C:\path\to\the\dll\I_made\in_Visual_Studio.dll

Any ideas on how to achieve this?

koahnig

@mlathrop

You are aware of the implications with respect to licenses?

Do you have QByteArray in the library?

mlathrop

@koahnig Yes I have a startup licence. QString is used in the DLL and so is toLocal8Bit(). What do you mean by is it "in" the library? Do you mean is it used? Or is it included? Or something else?

koahnig

@mlathrop

You are creating a dll and I refered to this as a library as short for dynamic link library.
It looks like you have hand-picked some of the class. You need to take of all the dependencies and QString and QByteArray have dependencies as you see in the documentation.
Therefore the question, if you have included QByteArray in your dll. If not, this would explain your error message.

When you are entitled to get support, why are not asking there?

mlathrop

@koahnig
Sorry for the delay in responding... I can't seem to get this to email me when people post. First off, the startup license doesn't have support :/

On the actual issue:
I have tried to just build dynamically for the sake of a more common case, and I get the same error. I am linking the client application to qtmain.lib and Qt5Core.lib as well. In the cpp file of the DLL I have the following includes:
#include <QString>
#include <QFile>
#include <QXmlStreamWriter>
#include <QXmlStreamReader>
#include <QByteArray>

I am curious as to why I don't get any kind of error at Link or compile time for the DLL.

koahnig

@mlathrop

Are you always using the same VS compiler? You cannot mixed with different version of the MS compiler. AFAIK only the 2017 studio is compatible with the previous version.
Therefore, the best is you download the pre-compiled library for the same version of visual studio. Otherwise you may error messages as you posted.

kshegunov

Wait a bit. This symbol looks very strange. There is no Qstring::toLocal8Bit the class is QString!

koahnig

@kshegunov

What is about this toLocal8Bit? This is in QString. Do you mean QByteArray?
I do not know the syntax of VC compilers.

kshegunov

?toLocal8Bit@Qstring@ is the (qualified) symbol name, Qstring::toLocal8Bit in this case.
@ is the end of symbol name (a separator).
QEGBA is the methods characteristic - CV-qualifier, access (public/private/protected), calling convention etc.
?AVQByteArray@ is the qualified name of the return type - class QByteArray.
@ is the end of section (a separator).
XZ - basically means "no method parameters".

So the above (if I haven't made a mistake) should be:

public: QByteArray __thiscall Qstring::toLocal8Bit() const;

Now, see that the class is wrong, there's no Qstring in Qt, the name should be capitalized.

koahnig

@kshegunov

Sorry, I did not catch the lower case 's'.

However, when it is a typing error in user's code, it shall be caught by the compiler or there is also the same typing error in include file. All very strange.

kshegunov

@koahnig said in Building DLL in Visual Studio with Static Linking to QT:

when it is a typing error in user's code, it shall be caught by the compiler or there is also the same typing error in include file.

Yes, my point exactly!

All very strange.

Indeed, something's fishy here.

mlathrop

@koahnig
I am using 2015 across the board so I don't think that is the issue... Interestingly, things don't work when I build dynamically and link against the QT libraries either. The capitalization error was a typo when I re-typed the error message (it is shown on a pop-up window that I couldn't copy from). The post it edited to reflect this. A workaround for the issue is to call "name.toStdString().c_str()" where name is the QString, though this feels less efficient.

koahnig

@mlathrop

Really a bit strange. Possibly you should post a snippet of your code showing where the problem shows up.

When you are using dlls is this self-compiled or pre-build from Qt webpage?

Also when you compile, from where do you take the code?
At least in the past there was always the recommendation to download the source code archive (.zip for windows). The source code as delivered with the pre-compiled Qt libs was not suitable for re-compilation. AFAIK this is still the case or at least I have not read the opposite yet.

mlathrop

@koahnig said in Building DLL in Visual Studio with Static Linking to QT:

east in the past there was always the recommendation to download the source code archive (.zip for windows). The source code as delivered with the pre-compiled Qt libs was not suitable for re-compilation. AFAIK this is still the case or at least I have not read the

I got the dll's from the website (or actually from the installer... but all it does is download them...)

Here is a code snippet:

if (xml.isEndElement() && xml.name() == "Test") {
          int id = Add(left, right, bottom, top, front, back);
          QString adjusted_name = name;
          int i = 0;
          while (!SetName(id, adjusted_name.toLocal8Bit())) {
            adjusted_name = name + QString::number(i++);
          }
}

koahnig

@mlathrop said in Building DLL in Visual Studio with Static Linking to QT:

@koahnig said in Building DLL in Visual Studio with Static Linking to QT:

east in the past there was always the recommendation to download the source code archive (.zip for windows). The source code as delivered with the pre-compiled Qt libs was not suitable for re-compilation. AFAIK this is still the case or at least I have not read the

I got the dll's from the website (or actually from the installer... but all it does is download them...)

This means that you standard pre-compiled dll version. When you have taken care of chosing the same pre-compiled version as the tool chain you are using, this should be fine.

Are you mixing std::string with QString?
When name is std::string than you a conversion.

What is the parameter in SetName?
There may apply the same.

kshegunov

@mlathrop said in Building DLL in Visual Studio with Static Linking to QT:

Interestingly, things don't work when I build dynamically and link against the QT libraries either.

Then it's most probably a linking issue. Can you show how you link the Qt libraries (e.g. from your .pro file)? Also add the actual linker invocation line, so we can see what is executed exactly.

A workaround for the issue is to call "name.toStdString().c_str()" where name is the QString, though this feels less efficient.

Besides inefficient, depending on how you use that it might be much less safe ...

mlathrop

@koahnig

SetName takes in a char* because it is a part of an API.

@kshegunov

Here are the relevant linker calls. I don't know how to get the .pro file from a VS project.

Here is the linker call in the project that makes the dll:

/OUT:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pdb" /DYNAMICBASE "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" "qtmain.lib" "Qt5Core.lib" "Qt5Multimedia.lib" "Qt5Gui.lib" "winmm.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin\yyy3D.pgd" /SUBSYSTEM:CONSOLE /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\3DRelease\yyy3D.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\lib\x64" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64" /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /TLBID:1

Here is the linker call for the project that uses the dll and has the run time error:

/OUT:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.dll" /MANIFEST /LTCG:incremental /NXCOMPAT /PDB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pdb" /DYNAMICBASE "Qt5Core.lib" "Qt5Gui.lib" "Qt5Multimedia.lib" "yyy3D.lib" "sl_zed64.lib" "opencv_world310.lib" "cudart.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /IMPLIB:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.lib" /DEBUG /DLL /MACHINE:X64 /OPT:REF /PGD:"E:\Users\misappsci\Documents\Projects\Aerie\host_x64\x64\Release\AerieLib.pgd" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:"x64\Release\AerieLib.dll.intermediate.manifest" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Qt\5.7\msvc2015_64\lib" /LIBPATH:"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0/lib/x64" /LIBPATH:"C:\Program Files (x86)\ZED SDK\dependencies\opencv_3.1.0/x64/vc14/lib" /LIBPATH:"C:\Program Files (x86)\ZED SDK\lib" /LIBPATH:"E:\Users\misappsci\Documents\Projects\yyy\x64\bin" /LIBPATH:"C:\Program Files\boost\boost_1_63_0/lib/x64/" /TLBID:1