mingw-cross-env should build Qt with "-no-iconv". That way, the
programmer will get linker errors when trying to build his application.
That way, he will know that he *must* include the text codec plugins.
mingw-cross-env should build Qt with "-no-iconv". That way, the
programmer will get linker errors when trying to build his application.
That way, he will know that he *must* include the text codec plugins.
FreeBSD and OSX seem to have a problem with MAKEFLAGS being set. Tens
or hundreds of g++ processes are created and they eventually end up
with strange errors.
Several improvments made to building Qt. One is the removal of the
"-isystem" hack for putting the mingwrt at the top of the include
path search list to solve the float.h problem.
Previously we did not specify -arch, so the configure script used
the host architecture as the default. This worked as long as the
host and target architectures matched. That's why we had to force
it with -host-arch i386 to make it work on 64 bit hosts.
The correct value "windows" may have different properties than
i386, but this has not be researched. In any case "windows" is
the value use by the binary executable configure tool for windows.
Additionally, the configure script did not respect -arch when
cross-building on MAC. Now CFG_ARCH is set automatically to
windows to cover this case.
Also, "-largefile" is not appropriate for Windows. Now specify
"-no-largefile" to avoid defintions meant for Unix. Windows
apparently still has its largefile support.
The configure script assumes that gstreamer is the phonon backend
but ds9 is used for mingw32. This patch fixes this in the configure
script. We now invoke configure with -no-glib and -no-gstreamer.
Also fixed case of GL include directory reference.
Some syntactic improvements suggested upstream.
I assumed that having -lQtCore4 in OPENSSL_LIBS was harmless for
static Qt. That is false. Although building Qt succeeds, this
also causes an application's makefile generated by qmake to mention
-lQtCore4. For static Qt, the actual library is called "libQtCore.a"
(without the "4"), which caueses linking to fail.
Therefore, I removed this library from OPENSSL_LIBS and included
a reminder for people who want to build shared Qt with qt-zlib.
Also, OPENSSL_LIBS and PSQL_LIBS are probably more than "harmless"
for static Qt. They help qmake generate appropriate makefiles
for applications.
It is not correct to add QtCore4 in ssl.pri when -lz is removed
for qt-zlib.
In mingw-cross-env we add QtCore4 to OPENSSL_LIBS so the zlib
dependency of openssl is satisfied in case of qt-zlib. This
is necessary for the time being because the QtCore4 in the link
command that qmake generates appears before the contents of
OPENSSL_LIBS.
-fixed compile test for win32-g++
-removed compile test hacks since compile test works now
-fixed odbc test for mingw32
-fixed iconv compile test for win32-g++
-fix ipv6 detection on win32-g++
-fix largefile detection on win32-g++
-fix getaddrinfo detection on win32-g++. Result is still
negative, apparently correctly.
-fix opengl detection on win32-g++
-removed obsolee opengl error hack
-improved exempting win32-g++ from XLib test
-improved zlib treatment when compiling on MAC for win32-g++
-finished rtti support
-restored replacement of -lz with -lQtCore4 on ssl.pri
-specifed "-no-fontcnfig" because this gets enabled now
by default thanks to working freetype detection.
-restored -openssl-linked, setting OPENSSL_LIBS and
zlib fix in ssl.pri. Previous conclusion that these
were unnecessary was apparently an experimental error.
glib is now detected which I hope is a good thing.
The postgresql library -lpq depends on -lsecure32, -lssl, and so
on. These are static libraries. When we build the psql plugin as
a shared library, linking fails unless we provide the list of
required libraries.
Previously, this was taken care of with a hack in the configure
script. Since that hack is not suitable for an upstream merge
request, I have moved it here.
We have been building Qt with "-openssl-linked". A patch was needed to adjust
OPENSSL_LIBS to keep a shared Qt build from failing at the point where
QtNetwork4.dll is linked. The patch is not needed if we use "-openssl" instead.
Because libssl and its dependencies are static libraries in mingw-cross-env,
a simple "-openssl" also causes libssl and dependencies to be embedded
(imported) into QNetwork4.dll, but it does so without requiring the patch.
Details:
The patch solved a problem that is a feature of a specific recipe of
Qt build ingredients:
(1) -shared
(2) -openssl-linked
(3) -qt-zlib
in an environment were:
(4) openssl is static
(5) “system” zlib is static
At least 1-3 are needed to see the problem. I suspect that 4 and 5 are needed as
well.
What I think I understand:
“-shared” means that QtNetwork4.dll will be built, which is the locus of the
problem.
“-openssl-linked” means that libssl and its dependencies are to be embedded in
QtNetwork4.dll. OPENSSL_LIBS supplies the list of dependencies.
“-qt-zlib” means that QtCore4 contains a zlib implementation.
Given this recipe for QtNetwork4.dll, the zlib implementation of “-lz” conflicts
with the zlib implementation of “-lQtCore4”.
The patch removed "-lz" from OPENSSL_LIBS and replaced it with "-lQtCore" in the
same position. Adding "-lQtCore" in this way is not a robust solution. For example,
it will break a debug build.
Mark Brand
Brad Pitcher
Nikos Chantziaras
Volker Grabsch