Hi, Tested the latest patch and it is building successfully. Too bad Qt isn't going to fix the symbol clash in libjscore.a and libQtScript.a. MCE/usr/i686-pc-mingw32/lib/libjscore.a(OpaqueJSString.o):OpaqueJSString.cpp:(.text+0xa0): multiple definition of `OpaqueJSString::ustring() const' MCE/usr/i686-pc-mingw32/lib/libQtScript.a(OpaqueJSString.o):OpaqueJSString.cpp:(.text+0xa0): first defined here Thanks for the fix.
On 29 November 2011 19:16, Zach Thibeau <zachary.thibeau@...> wrote: > On 11/29/2011 06:52 AM, Volker Grabsch wrote: [...] >> >> (BTW, I also thought about adding a MacOS X cross toolchain in >> the far future. However, I don't know how much need is there, >> as you'll need proprietary stuff to get it run anyway. Also, >> as soon as Apple successfully switched to LLVM, they will almost >> certainly release fewer and fewer parts of the build toolchain >> as Free Software, probably even disallowing cross-compiling >> at all in their license (except from Apple to Apple hardware, >> I guess, so you can still develop for iOS on a MacBook). >> >> Anyway, there's the IMCROSSS project which already contains lots >> of useful scripts for MacOS X cross compiling, but it seems to be >> inactive for about 2.5 years: http://www.sandroid.org/imcross/ >> >> Any thoughts on that topic are welcome. Does anyone have >> a real need for cross-compiling (with static linking) for >> MacOS X? >> ) >> >> >> Greets, >> Volker >> > hmm a cross compiler targeting mac would be awesome would help with porting > my own project to osx, be hard to test if the end binaries would work on an > osx system since I don't have a mac computer but the idea would be > beneficial for people who don't have access to macs nonetheless(Continue reading)
On 29 November 2011 21:52, Volker Grabsch <vog@...> wrote: [...] > (BTW, I also thought about adding a MacOS X cross toolchain in > the far future. However, I don't know how much need is there, > as you'll need proprietary stuff to get it run anyway. Also, > as soon as Apple successfully switched to LLVM, they will almost > certainly release fewer and fewer parts of the build toolchain > as Free Software, probably even disallowing cross-compiling > at all in their license (except from Apple to Apple hardware, > I guess, so you can still develop for iOS on a MacBook). > > Anyway, there's the IMCROSSS project which already contains lots > of useful scripts for MacOS X cross compiling, but it seems to be > inactive for about 2.5 years: http://www.sandroid.org/imcross/ > > Any thoughts on that topic are welcome. Does anyone have > a real need for cross-compiling (with static linking) for > MacOS X? > ) GNUstep is still alive and well: http://lists.gnu.org/archive/html/discuss-gnustep/2011-11/msg00113.html Has anyone here used it? Tony
Tony Theodore schrieb: > On 29 November 2011 21:52, Volker Grabsch <vog@...> wrote: > > > > Any thoughts on that topic are welcome. Does anyone have > > a real need for cross-compiling (with static linking) for > > MacOS X? > > ) > > GNUstep is still alive and well: > > http://lists.gnu.org/archive/html/discuss-gnustep/2011-11/msg00113.html This looks great, although I never actually worked with it. > Has anyone here used it? Additional question: Has anyone here use it in combination with Qt? Is it possible to cross compile a Qt application for MacOS X without the proprietary SDK from Apple? Greets, Volker -- -- Volker Grabsch ---<<(())>>---
Hey, I'm using an unmodified mingw-cross-env for my project MKVToolNix. The current release is the first one built with mingw-cross-env[2], and one user asked my this question[1]: "Why do all .exe files in mkvtoolnix have an export table? They are all exporting ~100 functions of names starting with libssh2, e.g. libssh2_channel_close." which I couldn't answer because my knowledge about DLLs and EXEs on Windows is very limited. He further elaborated: "The export table should only exists on DLLs. It is likely all EXEs are linking to libssh2 and libssh2 is built as a DLL-like library, which is built as a static library, but with all functions still marked 'export'. So all libssh2 functions, no matter used or not, are linked and exported, making the EXEs very big." How would I go about checking whether or not his assumption about the libssh2 built by mingw-cross-env is correct? How could I change that behavior (I guess by patching libssh2 not to use the dllexport declspecs), or could someone do it instead of me (like I said, I'm primarily a Linux developer whose knowledge about DLLs is mightily lacking)? Thanks. Kind regards, mo(Continue reading)
Hi list, Now I wrote a cmake package and patched some of the cmake find_package modules: https://bitbucket.org/muellni/mingw-cross-env-cmake/changeset/474d09e12a89 I moved the cmake toolchain file from gcc.mk into that package. It installs into the usr/ directory. Unfortunately the cmake binaries can't just be renamed, so it installs a usr/bin/cmake, ctest, ccmake and cpack executable. I placed a wrapper script at usr/bin/i686-pc-mingw32-cmake which uses the toolchain file and is invoked by $(CMAKE) from within the makefiles. Among the changes of the find_package modules is also a script from this list (https://lists.nongnu.org/archive/html/mingw-cross-env-list/2010-11/msg00069.html), which I added to the ${QT_USE_FILE}. Now ${QT_LIBRARIES} contains all needed libraries for static linking. Then I patched the cmake based packages to use the new $(CMAKE) command: https://bitbucket.org/muellni/mingw-cross-env-cmake/changeset/f523181e2974 At last I wrote cmake config files for the packages ffmpeg, openssl, libxml2 and libmng which use our pkg_config: https://bitbucket.org/muellni/mingw-cross-env-cmake/changeset/e8c480a6b98f What do you think? Would you accept this new cmake approach for mingw-cross-env? I know there doesn't seem to be many cmake users on this list, but these changes greatly simplify the use of mingw-cross-env from within cmake. All you need to do now is to call the usr/bin/i686-pc-mingw32-cmake for(Continue reading)
Hi, I use cmake with mingw-cross-env for my project (depending on ffmpeg, glib, gtk2 and some more) and I never had problems with using cmake -G'Unix Makefiles' -DCMAKE_TOOLCHAIN_FILE=../mingw-cross-env/usr/i686-pc-mingw32/share/cmake/mingw-cross-env-conf.cmake ../src make I wonder what kind of problem your approach solves? I can see that for some packages custom Find*.cmake are needed to make static linking work, but why install a custom cmake command? Best wishes Matthias
Hi, Your mingw based cross compiler project looks interesting, particularly with the number of packages alreadly configured and ready to go. However when i tried your release version download from here, following the tutorial here http://mingw-cross-env.nongnu.org/#tutorial when i simply typed make, it got a 404 error trying to get the Mingw runtime (the log file follows at end of this mail) Im guessing that i could probably download a runtime and put it somewhere and have it work from that, but its not immediately obvious to me where to put it. In the meantime, im going to try out the development version, but i figured you should know about this, maybe the download should be updated. thanks Rupert rupert <at> morrigan:~/src/mingw-cross-env-2.21$ more log/mingwrt-download --2011-12-04 21:34:43-- http://kent.dl.sourceforge.net/project/mingw/MinGW/Base System/RuntimeLibrary/MinGW-RT/mingwrt-3.18/mingwrt-3.18-mingw32-dev.tar.gz Resolving kent.dl.sourceforge.net... 212.219.56.167 Connecting to kent.dl.sourceforge.net|212.219.56.167|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://downloads.sourceforge.net/project/mingw/MinGW/BaseSystem/Runtim eLibrary/MinGW-RT/mingwrt-3.18/mingwrt-3.18-mingw32-dev.tar.gz?download&failedmi rror=kent.dl.sourceforge.net [following] --2011-12-04 21:34:44-- http://downloads.sourceforge.net/project/mingw/MinGW/Ba(Continue reading)
Hi Gareth, > Tested the latest patch and it is building successfully. Thanks. > Too bad Qt isn't going to fix the symbol clash in libjscore.a and libQtScript.a. > > MCE/usr/i686-pc-mingw32/lib/libjscore.a(OpaqueJSString.o):OpaqueJSString.cpp:(.text+0xa0): > multiple definition of `OpaqueJSString::ustring() const' > MCE/usr/i686-pc-mingw32/lib/libQtScript.a(OpaqueJSString.o):OpaqueJSString.cpp:(.text+0xa0): > first defined here Recently at least, QtWebKit and QtScript use different versions of java script, but I don't know the details. They come into conflict using static linking. The official "solution" noted in QTBUG-8657 was to "remove support for static linking of QtWebKit". Mingw-cross-env restores support for static linking of QtWebKit, but cannot solve the symbol conflict when using QtWebKit and QtScript in the same application. The libjscore.a library is always built as a static library, but it's normally linked into the shared QtWebKit and not installed. I suppose dynamic linking avoids the problem by not exporting libjscore.a symbols from QtWebKit DLL, or maybe there's DLL magic involved that I don't know about. If you need to link an application statically to both static QtScript and QtWebKit, I wonder if you can get away with linking to either libqtscript.a or libjscore.a, but not both. Perhaps the differences don't matter much to your application. I have more experience building(Continue reading)
Rupert Brooks wrote: > Hi, > > Your mingw based cross compiler project looks interesting, > particularly with the number of packages alreadly configured and ready > to go. However when i tried your release version download from here, > following the tutorial here > http://mingw-cross-env.nongnu.org/#tutorial > when i simply typed make, it got a 404 error trying to get the Mingw runtime There are lots of reports of this kind on the mailing list. The problem is that people sometimes change the URLs where these files are located. In the development and stable mercurial repositories of mingw-cross-env the URLs are updated. If you are just getting started and trying things out, you might want to go ahead and try out the development version. It has more recent versions of many packages and several new packages. If something there doesn't work and you report it, it's likely to get fixed quickly. Mark
RSS Feed55 | |
|---|---|
80 | |
80 | |
95 | |
85 | |
22 | |
45 | |
15 | |
17 | |
31 | |
34 | |
20 | |
20 | |
101 | |
65 | |
158 | |
27 | |
34 | |
55 | |
143 | |
63 | |
58 | |
47 | |
17 | |
60 | |
82 | |
44 | |
138 | |
56 | |
41 | |
108 | |
103 | |
235 | |
222 | |
28 | |
59 | |
173 | |
316 |
