Fri, 19 Apr 2002 10:00:14 +0100
> > > > > > Basically with QT 3 there has been a move from the previous
> > > > configuration
> > > > > > scripts to qmake. This causes some problems with Cygwin because
> > Cygwin
> > > > > > requires a special set of steps to be taken in order to produce
> > shared
> > > > > > libraries and these aren't supported by qmake. The DLL links
> > the
> > > > qmake
> > > > > > generated Makefile, but is useless since it doesn't have a .DLL
> > suffix.
> > > > I
> > > > > > have produced my own script which creates a qt-mt-3-0.dll but
> > is
> > > > only a
> > > > > > temporary fix. So what I'm asking is if anyone has any ideas on
> > to
> > > > solve
> > > > > > this problem.
> > > > > Yes, I have a patched qt3-cygwin release with native qdir/qfile
> > support.
> > > > > You can get qt-3 in the next few days from cvs.
> > > > How did you link the DLL?
> > > With ld, of course. Im not sure, what you like to hear with this
> > > I have created a mkspec/cygwin-g++/dir and have patched qmake. See the
> > > appended patch of the head release of anoncvs.kde.orgs qt-copy dir
> > One small comment about the patch. IMHO, the Cygwin DLL support should
> > turned on by an option in the mkspecs (like the hpux shlib support
> > rather than #ifdef __CYGWIN__. On the other hand, both methods work to
> > same effect I guess.
> You mean to write a specific qmake makefile generator ? Yes, may be, but
> needs more time to understand the source as I had. If you like to do this,
Not quite a specific one. If you look at the hpux qmake.conf's they have a
line "QMAKE_HPUX_SHLIB = 1" which turns on some conditional processing in
unixmake.cpp/unixmake2.cpp. We could add a QMAKE_CYGWIN_SHLIB flag in a
similar way. The #ifdef __CYGWIN__ would be replaced with something like:
if (!project->variables ()["QMAKE_CYGWIN_SHLIB"].isEmpty ())