Since I must use a slow internet connection (56K), to keep Qt/Windows library version in sync with Qt/x11 I need several hours to download (57MB). I can save same time downloading only sources (40MB), so I have patched it to compile with cross-mingw32. Since I need only few files from windows source, sh ould be nice if you can distribute a tarball containg only file from windows source missing/differing in linux source. Such a tarball is only 550KB of size (can be smaller if you exclude files not needed to compile). If some gentoo dev is interested to create an ebuild for Qt/Windows (better if included in toolchain, I think), next attacched are patches I used to compile Qt/Windows 4.2.2 using cross-mingw32/gcc-3.4.6-r2.
Created attachment 103927 [details] Patches to compile Qt/Windows with cross-mingw32 Tested with cross-mingw32/gcc-3.4.6-r2 Check README file for more info
Which ebuild is this about??? (And, we are not creating castrated homebrew tarballs for something that upstream distributes, busy enough as it is).
(In reply to comment #2) > Which ebuild is this about??? It is intended to build qt libraries to be used with cross-mingw32 instead of having to download windows binaries from Trolltech
Hum...
I think the point is, what "ebuild" are you patching? There isn't a qt-windows ebuild in portage.
I'm not patching any ebuild, I'm requesting for a new one (I used proposed patches directly with upstream sourcecode). If qt can be build using toolchain, running crossdev mingw32 could create a new symlink: $PORTDIR_OVERLAY/mingw32-cross/qt -> /usr/portage/x11-lib/qt otherwise a proper ebuild can be created: it should check if 'crossdev mingw32' have already been executed. By now, I'm trying to build it with mingw32-g++-4.1.1, but seems that windows only code (*_win.cpp files) are not designed to be compiled with g++-4, so they need to be fixed.
Created attachment 104218 [details] qt_4.2.2-patches-0.2.tar.bz2 Few changes (Changelog included) Now I can compile it using cross-mingw32/gcc-4.1.1-r2, but only if accessibility support is disabled (src/gui/accessible/qaccessible_win.cpp still to be patched). TODO: - patch accessibility support to compile with mingw32-g++-4* - check for warnings from *_win.cpp files (mainly with mingw32-g++-4*)
I missed to say this depend on bug 156767 I solved it with a symlink /usr/mingw32/usr/local/include/float.h -> ../../include/float.h but still waiting a fix in portage
i'm still not sure these mingw ebuilds should be in the tree perhaps more appropriate would be an overlay in overlays.g.o
Created attachment 104262 [details] Multi-category qt-4.2.2.ebuild I tried to change qt ebuild to be used for Qt/Windows too. It needs my patches copied in FILESDIR/mingw32/ (bzipped) and DISTDIR/qt-win-addons-4.2.2.tar.bz2 file (check README in patches tarball to see how I created it). When it is used for x11-lib/qt, it will install Qt/X11 as usual; when it is used for cross-mingw32/qt it will install Qt/Windows (perhaps 'crossdev mingw32' could create a symlink to it). If you still think it should be an overlay, it can be changed to be used only for Qt/Windows. ISSUES for official qt ebuilds (at least for v4.2.2): 1) sed commands in src_unpack function have none effects for mkspecs/linux-g++/qmake.conf because patched variables are imported from mkspecs/common/g++.conf and mkspecs/common/linux.conf 2) 'configure -no-reduce-exports' can be used to disable visibility support instead of patching configure script 3) There is a reason for official ebuild to run emake sub-tools-all-ordered || die emake sub-examples-all-ordered || die instead of simple 'emake || die'? Using 'configure -nomake examples' will prevent examples and demos to be built and installed (and is slight faster since doesn't create makefiles for them).
Nope, these are all good suggestions for the Qt ebuild. These are things they have added more recently (must be in the 4.2.x series only) that just haven't been caught yet.
I've made modifications to the ebuild in portage based on your ISSUES listed in #10. My big question on this: is there a reason you're not using the existing Qt for Windows ebuild (other than portage support). Or are you just trying to get cross-compilation support for Qt/X11 via mingw?
(In reply to comment #12) > is there a reason you're not using the existing Qt for Windows ebuild (other > than portage support). I didn't found any existing Qt for Windows ebuild; if you know one, please give me a link: I will propose my ideas to his maintainer. > Or are you just trying to get cross-compilation support for Qt/X11 via mingw? No, my intent is to build Qt/Windows libraries so we can cross-compile qt programs using mingw32. We could use windows sources, but only few files differ from x11 sources (*_win* instead of *_x11*), so my idea is to save bandwidth to help users with slow internet connection (as me). File qt-win-addons-4.2.2.tar.bz2 I created is only 550K while qt-win-opensource-src-4.2.2.zip is 40M. Further TIP for official ebuild: You can run make INSTALL_ROOT=${D} install_subtargets || die instead of make INSTALL_ROOT=${D} sub-tools-install_subtargets-ordered || die make INSTALL_ROOT=${D} sub-examples-install_subtargets || die Using '-nomake examples', demos and examples won't be installed.
I've made your subtargets suggestion modification. It seems to me that the mingw tookit and other stuff is going to be moved into an overlay (see the threaded started at http://archives.gentoo.org/gentoo-dev/msg_141604.xml ). If this is the case, it probably makes sense to put this stuff into that overlay as well, I think.
Created attachment 104673 [details] qt-windows-4.2.2.ebuild Changed to be used only for Qt/Windows. From mentioned thread seems that a new overlay will really be open under the control of a mingw project. This bug could be reassigned to them as soon as they start (hoping that bugs.g.o can still be used for stuff in that overlay)
Created attachment 106195 [details] qt-4.2.2-patches-0.3.tar.bz2 Few changes to build QtTest4.dll, libQtTest4.a and libQtUiTools.a
Created attachment 106197 [details] qt-windows-4.2.2.ebuild Changed to use patches tarball directly + some ebuild cleaning TIP for x11-libs/qt/qt-4.2.2.ebuild glib, qt3support and (maybe) pch use-flags can be checked with qt_use function: this will clean the ebuild a little.
(In reply to comment #14) > It seems to me that the mingw tookit and other stuff is going to be moved into > an overlay (see the threaded started at > http://archives.gentoo.org/gentoo-dev/msg_141604.xml ). If this is the case, > it probably makes sense to put this stuff into that overlay as well, I think. > Does anyone know if a such overlay have been opened? I cannot find any news on it.
Created attachment 124692 [details] qt-4.3.0-patches-0.1.tar.bz2 Patches to cross-compile Qt/Windows 4.3.0
Created attachment 124694 [details] qt-windows-4.3.0.ebuild Ebuild for new version
This ebuild tries to get qt-all-opensource-src-4.3.0.tar.bz2, is it intended? Where to get that file from?
(In reply to comment #21) > This ebuild tries to get qt-all-opensource-src-4.3.0.tar.bz2, is it intended? > Where to get that file from? You can find qt-all-opensource-src-4.3.0.tar.gz in any Trolltech mirror (ex. ftp://ftp.trolltech.com/qt/source/ ) I don't remember where I found bz2 version, but gz version should works as well (change it in ebuild).
Created attachment 124807 [details] qt-windows-4.3.0.ebuild Fixed to fetch correct file.
Created attachment 138369 [details] qt-4.3.3-patches-0.1.tar.bz2
Created attachment 138370 [details] qt-windows-4.3.3.ebuild -It takes care of mingw32 variants (mingw32 i686-mingw32 ...). -It strips march/mcpu/mtune c/xxflags for win32-g++ spec and disables mmx/3dnow/sse/sse2 instructions: it should be safer when you want to use generated dll on a different computer. -Added ~amd64 keyword.
Created attachment 139081 [details] qt-windows-4.3.3-r1.ebuild Added "append-flags -fno-strict-aliasing" to solve QA warning with mingw32-gcc-4
This is an ebuild which will enable me to crosscompile Qt programs via mingw32 for Windows? Cool! Something I have waited for since a long time, since Qt's own crosscompilation support seems very poor. :)
I am getting an error. :( mingw32-g++ -c -include .pch/release-shared/qt_pch.h -pipe -O2 -fno-strict-aliasing -pipe -O2 -fno-strict-aliasing -Wall -fexceptions -mthreads -frtti -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_CORE_LIB -DQT_MAKEDLL -DQT_ASCII_CAST_WARNINGS -DQT_44_API_QSQLQUERY_FINISH -DQT3_SUPPORT -DQT_MOC_COMPAT -D_USE_MATH_DEFINES -DQT_DLL -DQT_NO_DEBUG -I"../../include" -I"../../include/QtCore" -I"tmp" -I"global" -I"../3rdparty/zlib" -I"/var/tmp/portage/cross-mingw32/qt-windows-4.3.3-r1/work/qt-all-opensource-src-4.3.3/include/ActiveQt" -I".moc/release-shared" -I".uic/release-shared" -I"." -I"../../mkspecs/win32-g++" -o .obj/release-shared/qrect.o tools/qrect.cpp tools/qlocale.cpp: In function ‘char* qdtoa(double, int, int, int*, int*, char**, char**)’: tools/qlocale.cpp:5918: error: ‘_clear87’ was not declared in this scope tools/qlocale.cpp:5919: error: ‘_control87’ was not declared in this scope make[2]: *** [.obj/release-shared/qlocale.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/cross-mingw32/qt-windows-4.3.3-r1/work/qt-all-opensource-src-4.3.3/src/corelib' make[1]: *** [release] Error 2 make[1]: Leaving directory `/var/tmp/portage/cross-mingw32/qt-windows-4.3.3-r1/work/qt-all-opensource-src-4.3.3/src/corelib' make: *** [sub-corelib-make_default-ordered] Error 2 An idea of mine: Why not integrate this into the Qt ebuilds, like it is done for GCC and the rest of the toolchain?
(In reply to comment #28) > I am getting an error. :( It is related to bug 156767: float.h header from mingw-runtime should be read before gcc system float.h header. I have solved it creating a symlink: /usr/mingw32/usr/local/include/float.h -> ../../include/float.h > An idea of mine: Why not integrate this into the Qt ebuilds, like it is done > for GCC and the rest of the toolchain? I agree with this thread (http://archives.gentoo.org/gentoo-dev/msg_141604.xml ) to have a mingw overlay and with Caleb (comment #14) to put this ebuild in that overlay, but unfortunately seems that a such overlay have never been opened (at least I cannot find it).
windows ebuilds should be placed into an overlay, not into the tree
Is this a Windows ebuild or a crosscompilation ebuild? In the latter case: crossdev support for mingw32 is also in the tree... And if you would take it out, you'd again have to supply seperate ebuilds for every platform, which you'd need to keep in sync... And I would really prefer such a solution. I.e. let something like crossdev setup cross-mingw32/qt(-core,...).
Roberto: Could you reduce the diff against the official qt-4.3.3 ebuild? Maybe some Qt dev helps you to include some changes into it... Possibly that would also ease a merge with the official ebuild in case there is no too strong opposition by Staff.
(In reply to comment #32) > Roberto: Could you reduce the diff against the official qt-4.3.3 ebuild? Sorry, but I prefer to keep it separated from official ebuild. By now, configure script need to be hardly patched to configure building for Qt/Windows and my patches are suitable only for this purpose. Merging with official ebuild means to delay any future version release to get ebuilds working for Qt/Windows. Further I don't consider to split this ebuild for next releases. Maybe I will consider to try to merge it if upstream will support configure script to build Qt/Windows too. If you still want to try to merge it with official ebuild, check my first ebuild I posted here (qt-4.2.2.ebuild)
Your ebuild also removes ", has some unnecessary indention changes, etc. Further some parts of your modifications could be useful in the official ebuild, too. So I really don't think this has anything todo whether or not the ebuild should be merged. It is just easier to see what you changed if the diff is smaller...
Do you already have updated patches for qt-4.3.4? At least the one to configure fails to apply.
(In reply to comment #35) > Do you already have updated patches for qt-4.3.4? At least the one to configure > fails to apply. Is a PITA to download it with a slow internet connection (56K). I will work on it as soon as I can use a DSL connection (somewhere).
(In reply to comment #30) > windows ebuilds should be placed into an overlay, not into the tree > Agreed, as far as I can see none of us have any interest in maintaining this. It's also not appropriate for inclusion the tree, as per previous comment.
