[Interest] Problem creating a dll that loads static Qt libraries (in mingw) -> final chapter

[erick oliveira da silva]

Hi Till,

Thanks for your reply. I learned a lot with it.

I compiled qt library by myself. I download the sources and compiled with
gcc-mingw, the same compiler I am trying to build my simple qt shared
library now.

The function that I would like to export:

--- Header : dllfct.h ---------------------------------

#ifndef DLLFCT_H
#define DLLFCT_H

#include <QtCore/qglobal.h>
#include <QtGlobal>

#if defined(MY_DLL)
#define EXPORT  Q_DECL_EXPORT
#else
#define EXPORT  Q_DECL_IMPORT
#endif

// function to be imported/exported
EXPORT void tstfunc (void);

#endif //DLLFCT_H

-----------------------------------------------------

-- Source File : dllfct.cpp ---------------

#include <QString>
#include <QDebug>
#include "dllfct.h"

void tstfunc (void)
{
QString msg = "Hello";
  qDebug(qPrintable(msg));
}

---------------------------------------------------------

-- Pro file:

QT -= gui
TEMPLATE = lib
CONFIG += qt dll release

SOURCES = dllfct.cpp

MAKEFILE = Make_QDECL

DEFINES += MY_DLL

INCLUDEPATH += ./dllQDECL
DEPENDPATH += ./dllQDECL

HEADERS = dllfct.h

--------------------------------

and here my output:

D:\dllmingw\qt>mingw32-make -f Make_QDECL.Release
g++ -c -O2 -frtti -fno-exceptions -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT
-DMY_DL
L -DQT_DLL -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW
-DQT_HAVE_S
SE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT
-I"..\..\qt_static_4.7.4\
include\QtCore" -I"..\..\qt_static_4.7.4\include" -I"dllQDECL"
-I"..\..\qt_stati
c_4.7.4\include\ActiveQt" -I"release"
-I"..\..\qt_static_4.7.4\mkspecs\win32-g++
" -o release\dllfct.o dllQDECL\dllfct.cpp
g++ -Wl,-s -shared -Wl,--out-implib,release\libqtdll.a -o release\qtdll.dll
rele
ase/dllfct.o  -L"d:\qt_static_4.7.4\lib" -lQtCore -lole32 -luuid -lws2_32
-ladva
pi32 -lshell32 -luser32 -lkernel32
Creating library file: release\libqtdll.a
release/dllfct.o:dllfct.cpp:(.text+0x18): undefined reference to
`_imp___ZN7QStr
ing16fromAscii_helperEPKci'
release/dllfct.o:dllfct.cpp:(.text+0x2e): undefined reference to
`_imp___ZNK7QSt
ring11toLocal8BitEv'
release/dllfct.o:dllfct.cpp:(.text+0x3e): undefined reference to
`_imp___Z6qDebu
gPKcz'
release/dllfct.o:dllfct.cpp:(.text+0x61): undefined reference to
`_imp___ZN7QStr
ing4freeEPNS_4DataE'
release/dllfct.o:dllfct.cpp:(.text+0x71): undefined reference to
`_imp___Z5qFree
Pv'
collect2: ld returned 1 exit status
mingw32-make: *** [release\qtdll.dll] Error 1

------------------------------------------------------------------------------

Just to remind, if I change the pro file to build a static library(*.a) and
remove , I can link suscessfully a static library and also build
suscessfully a executable file that calls this function. My problem is
really just with dlls.

Using the directive __declspec( dllexport ) instead of Q_DECL_EXPORT didn't
change my output.

Thank you very much all of you for the replies.

Best Regards,
Erick


2012/1/19 Till Oliver Knoll <till.oliver.knoll at gmail.com>

>
> Am 19.01.2012 um 14:18 schrieb erick oliveira da silva <
> eosilva2000 at ig.com.br>:
>
> Hi Till,
>
>
>> Depending on your code it *might* be necessary (and hence correct
>> behaviour) to export the /entire/ class!
>>
>
> In my case, I unfortunatelly really need to export functions, not classes.
> And the same program works in Linux with gcc.
>
>
> First off, the fact that it works with gcc on Linux doesn't give us any
> confirmation whether your code/build instructions/compiler switches are
> correct on Windows! Why? Because that "__declspec(dll_export/import)" stuff
> is very Windows-specific and has no effect on any other platform with
> regards to whether a given symbol is exported from a DLL, or in other
> words: by default (*) on Linux (and any other platform that I know of) ALL
> symbols are exported from a given .so/.dynlib shared library - only on
> Windows you have to explicitly tell which symbols to export.
>
> (Side-note: there is another, I think older mechanism besides the
> "__declspec" approach: to provide an explicit "export table" (*.def ?).
> Refer to the MSDN documentation. But I prefer the __declspec approach, as
> it is "closer tied with the actual code", IMHO easier to maintain.)
>
> So the fact that something works on any other platform than Windows with
> regards to linking doesn't assure you that you are doing it right on
> Windows ;)
>
>
> So we can limit the discussion on the MS compiler/build environment vs gcc
> on MinGW (and since that's also building DLLs the same "Windows DLL rules"
> apply here).
>
>
> That said, I understand you have something like:
>
> // FooLib.h
>
> // The macro being defined properly
> FOOLIB_EXPORT void myFunction();
>
> // FooLib.cpp
>
> #include <QtCore/QString>
> #include "FooLib.h"
>
> void myFunction() {
>   QString msg = "Hello";
>   qDebug(qPrintable(msg));
> }
>
> and you link that with a static build of Qt 4.7.4 (did you compile it
> yourself? Or is that provided from Nokia/
> "Digia"?), which works with MSVC, but fails on gcc/MinGW. Is that about
> right?
>
> btw: do you use the same *.pro/qmake/nmake build approach with MSVC, or do
> you setup your project "from scratch" within Visual Studio (with the help
> of the "Qt AddOn" - or whatever it is called these days)?
>
>
> So as Andreas already pointed out at this point it might be helpful to see
> the actual (example) code and *.pro files which reproduces the problem.
>
>
> Cheers, Oliver
>
> (*) "By default" meaning "the compiler switches you get with the proper
> QMAKESPEC and qmake approach" - IIRC you can also have gcc (or was it the
> native compiler on AIX?) explicitly export given symbols and have
> everythink else "hidden" (not exported - reducing the file size by a couple
> of Bytes and possibly speeds up dynamic linking by a couple of
> %-fractions). But this again would become compiler/platform-specific, just
> as this __declspec stuff on Windows. So for the sake of simplicity of this
> discussion let's just say "everything is exported on any platform other
> than Windows".
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120120/54a258cf/attachment.html>