How to set the QT_DLL macro?

[Angus Leeming]

Ralf Habacker wrote:
>>frontends/.libs/libfrontends.a(QBibitemDialogBase.o)(.text+0x583): In
>>function `_ZNK6QGList5countEv':
>>/home/angus/lyx/13x/build-mingw-xcompile/src/frontends/qt2/ui/QBibitemDialogBase.C:
>>variable 'vtable for QSpacerItem' can't be auto-imported. Please read the
>>documentation for ld's --enable-auto-import for details.

> This problem is fixed by adding the following line to
> mkspecs\win32-g++\qmake.conf
> QMAKE_LFLAGS            = -Wl,--enable-runtime-pseudo-reloc

Hmmmm, not entirely true. I need to pass this flag to the linker, but I
also need to pass QT_DLL to the compiler. Looking at the explicit echo of
the compiler call when building the Qt libs, I see that you pass QT_DLL
directly to the compiler too:

i386-mingw32-g++ -c -Wall -O2 -fno-exceptions -fno-rtti
-DUNICODE -DQT_DLL -DQT_NO_DEBUG
-I"../interfaces" -I"../../../include" -I".moc/release-shared/"
-I"/home/angus/mingw-xcompile/qt3/mkspecs/win32-g++-cross"
-o .obj/release-shared/editor.o editor.cpp

So, I guess that I'm doing the right thing here. I just need to work out
how to tell automake to set this flag only when building on (or
x-compiling for) Windows.

> On cygwin I'm using the following switch, which may help to prevet seg
> faults. It requires a relink of the qt-3.dll
> QMAKE_LFLAGS            =
> -Wl,--script,$(QTDIR)/mkspecs/cygwin-g++/i386pe.x-no-rdata

Now that is very, very interesting. I'll try it out. (Am I correct to say
that only the dll needs to be re-linked?


> add a -shared option to configure or add the term 'shared' to
> .qmake.cache's CONFIG line  (qmake/generators/win32/mingw-make.cpp line
> 406)

I'm using an automake generated Makefile to build LyX, so I'm going to need
to understand more about what Qt's "configure -shared" does.

I see that when linking designer.exe you pass a bunch of flags to the
linker:

i386-mingw32-g++ -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import
-Wl,-enable-runtime-pseudo-reloc -Wl,-s -Wl,-subsystem,windows -e
__Z19QtWinMainCRTStartupv
-o ../../../bin/designer.exe .obj/release-shared/main.o

I'm currently building LyX as a console app, so guess that I don't need the
    -Wl,-subsystem,windows -e __Z19QtWinMainCRTStartupv
right?

We've already discussed "-Wl,-enable-auto-import" and
"-Wl,-enable-runtime-pseudo-reloc".

What do "-Wl,-enable-stdcall-fixup" and "-Wl,-s" do?


>>ps, linking against the qt3.dll is still excrutiatingly slow. Compilation
>>is far quicker, but the final link still takes ~20 minutes :(
>
> This depends on the time of used machine. On a suse linux server system
> with Xeon 2.6GHz and sata harddisc linking requires about 30-40 seconds.

Linking takes something similar here when I'm linking qt3.dll or am linking
against the Qt examples programs etc, but expands to 20 minutes when
linking LyX (a *much* bigger app). This is linking against the qt3.dll.
I'm using a 2.7GHz machine running Fedora Core 3. Memory usage when
linking is 70%, so it's not a swap issue. However, Michael Schmitt reports
that linking reduces to less than a minute when linking statically.

>>pps, I may have compiled lyx, but trying to start it up on Windows
>>results in an error dialog "The application failed to initialise itself
>>correctly" :(
>>
> I've heard of similar seg faults with mingw. Do you have tried to link
> it static ?

Not yet. Actually, what flags do I need to pass to i386-mingw32-g++ to
ensure it links against libqt3.a not qt3.dll? I tried to just hide qt3.dll
before linking on mingw/msys yesterday and the bloody thing still linked
against it :)

I'll also try out your magic script above.
And passing the linker the same set of flags as you use.
Lots and lots to try still.

First, I'll wait for the qt lib to finish building in its entirety and will
try out the examples. Currently we're at examples/dirview...

Many thanks for all the feedback.
Angus