You should be able to build iPhone ARM binaries using the following ‘configure’:

../cutterpillows-qt-iphone-clone/configure -xplatform iphone-device-g++42 -arch i386 -opensource -iphone -no-pch -no-accessibility -no-qt3support -no-xmlpatterns -no-multimedia -no-phonon -no-phonon-backend -no-svg -no-webkit -no-script -no-scripttools -no-openssl -no-sql-mysql -no-sql-odbc -no-cups -no-iconv -no-dbus -no-opengl -static -nomake tools -nomake demos -nomake docs -nomake examples -nomake translations

You’ll need to make sure that “QMAKE_IPHONE_SDK” in qmake.conf (/mkspecs/iphone-device-g++42/…) points to an actual iPhoneOS SDK. We’ll need to make this configurable later, for now it’s hard-coded.

Cheers

looks ok to me, lets wait what others have to say..

The main thing that should be tweaked is the conf files such as /iphone-armv6-g++.conf with DEFINES should be shared with both targets. That way when defined get modified it only has to be modified once for example.

That and the build failed for 64 bit building a 32 bit application. Missing arch tag somewhere.

Comments?

Regards.

Yes, there should be an “iphone-common-g++.conf” or something where the shared defines live. I can make that change.

As for the 64-bit issue make sure you pass “-arch i386” to ‘configure’ otherwise it will default to whatever the system default GCC architecture is – which I think is 64-bit x86. I've used my ‘configure’ parameters above (in the first comment) on a few different machines and haven’t had any problems with it.

The key parameters for ‘configure’ are the “-xplatform iphone-device-g++42” and “-arch i386.” The “-xplatform iphone-device-g++42” indicates that we’re doing a cross-compile using the “iphone-device-g++42” – note the ‘-xplatform’ as opposed to the normal ‘-platform’. ‘-xplatform’ doesn’t seem to be documented as far as I can tell, but that’s the key to doing a cross-compile. The other key parameter is the ‘-arch i386’ which specifies how the native Qt tool binaries should be built (qmake, moc, uic, etc.). Otherwise it would try to build the Qt tools with the system default architecture – 64-bit x86 – and that doesn’t seem to work.

Cheers

I just checked in an update, it changes the following:

• Added a couple of iOS-common…conf files that are now used by the iphone…conf & iphone-armv6…conf files – all of the shared stuff is in here.
  
• Fixed ‘configure’ to work for both Simulator and Device builds – my last checkin worked for Device builds but broke Simulator builds.
  
• Added configure parameters to iPhone.txt for both Simulator & Device builds – to help those new to building Qt.

Please have a look at the changes and let me know what you think.

Cheers

One more (hopefully last) update. Needed to set ‘TARGET_PLATFORM’ to ‘iphone’ in qmake.conf for the iphone-device mkspec. This is needed for the cross-compile, otherwise ‘mac’ is set instead of ‘iphone’.

Cheers

I'm still getting errors on device. First one I get is during configure which shows…

The target system byte order could not be detected!
Turn on verbose messaging (-v) to see the final report.
You can use the -little-endian or -big-endian switch to
../qt-iphone-clone/configure to continue.

I added little-endian to configure then I get other problems.

What I can do is commit what you have then we can work on the remaining build problems. Are you experiencing this problem?

Regards,
Mark Kromis

I haven’t seen that, however in examining the configure tests I noticed that a number of them that should succeed were failing so I looked into it some more. I found that the architecture (armv6) was missing from the QMAKE_LFLAGS. I also found that adding ‘-arch i386’ to the configure parameters was also screwing up the configure tests – they were trying to build a Universal i386 & armv6 binary which won’t work because the libraries to link with are either one architecture or the other. I think the missing ‘-arch armv6’ in QMAKE_LFLAGS was what was causing problems before with building 64-bit tool binaries (qmake, moc, uic, etc.).

So adding the ‘-arch armv6’ to the QMAKE_LFLAGS and removing ‘-arch i386’ from the ‘configure’ parameters should be the right thing to do – the configure tests that were failing before now succeed. That should build the Qt tools (qmake, moc, uic, etc.) with the system default GCC – which will likely be 64-bit GCC 4.2. That’s working for me now whereas previously I had problems building 64-bit tools – which I think is due to the missing ‘-arch’ in the QMAKE_LFLAGS.

I don’t know what the endian issue might be – I haven’t seen that at all. What OS & hardware (PowerPC/Intel) are you building with and against which iPhone SDK?

All of my builds lately have been on 10.6 Intel against the iPhone 3.2 SDK (the one included with the iPhone 4 SDK install).

I’ll be creating a new merge request that addresses the architecture issue above.

Cheers

Here is some more information, the reason the endianess can not be determined is because the test is not passing. Here is the result using the parameters from iphone.txt adding the -v command.

Determining machine byte-order… (//qt-iphone-clone/mkspecs/iphone-device-g++42 yes //qt-iphone-clone //qt-iphone-device-3.2)
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++-4.2 -Wl,-syslibroot,/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.2.sdk -headerpad_max_install_names -o endiantest endiantest.o
ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
gmake: *** [endiantest] Error 1
Unknown byte order!

But this library is not available in the device lib folder, (without a softlink). Otherwise the crt lib that is available is crt1.3.1.o

This was from a fresh install of xcode_3.2.3_and_iphone_sdk_4__final.dmg

Regards,
Mark Kromis

Yeah, the problem there is that it’s trying to link using x86 libraries instead of ARM libraries. That is addressed in my new merge request – “Add missing ‘-arch armv6’ to the QMAKE_LFLAGS.” That should allow the configure tests to proceed properly.

However, I merged in your latest changes (pushing from the latest Qt 4.7 I assume) into my clone and it gave me errors regarding building 64-bit stuff from a 32-bit Qt configuration. I wasn’t getting those previously and I've got a fix for it – add a 32-bit-only Mac mkspec to use as the ‘-platform’ parameter when building for the iPhone device.

Basically you then ‘configure’ using the 32-bit mkspec as the ‘-platform’ and the iphone-device mkspec as the ‘-xplatform’ (cross compile). The Qt tools (qmake, moc, uic, etc.) get built with the ‘-platform’ mkspec and the actual libraries get built with the ‘-xplatform’ mkspec.

I'd like to add those to the other merge request but I'm very new to Git and not very familiar with it. If I try to edit the merge request then it is forcing me to add the all of the changes from my clone – including the merge I did from your clone (qt-iphone-clone) into mine. That doesn’t seem like the right thing to do – I just want to merge my new changes into yours. Any hints on how to do that?

Cheers

Just stay on the current patching (this) branch, and make all of the necessary changes. I’ll merge in as needed. So basically act like I never pushed those changes. if you don’t know how to revert to a revision, you may be able to re-pull this branch.

I was also getting a warning in file iOS-common.conf and iOS-common-g++.conf…
Variable QMAKE_RPATH is deprecated; use QMAKE_LFLAGS_RPATH instead.

The other push is from 4.7-stable. Didn’t know the update was going to cause problems though.

Regards,
Mark Kromis

Just stay on the current patching (this) branch, and make all of the necessary changes. I’ll merge in as needed. So basically act like I never pushed those changes. if you don’t know how to revert to a revision, you may be able to re-pull this branch.

Which branch? I don’t know how to revert the changes, but I could always create a 2nd clone – but that seems excessive…

I'm just not clear on how the workflow works with Git and cloned repositories. How do I stay in sync with your changes? For example, the deprecation warnings were only introduced after the push from 4.7-stable. Also, the 64-bit vs. 32-bit cross compile problems weren’t there before the push either. I've got fixes for both but the fixes weren’t made until after I merged your push because before that there weren’t any issues.

Forgive me as I'm still trying to figure out the update cycle with Git. As far as I understand it, you've got your branch/clone – qt-iphone-clone – and I've got mine – cutterpillows-qt-iphone-clone – which is a clone of yours. Those are both hosted here on gitorious and then we've got our own local clones. We each make changes to our local repositories and then push those changes to the gitorious repositories. Then when I've got changes that I want pushed back into the main repository – qt-iphone-clone – I can create merge requests to do that.

Here’s where it get’s a bit unclear for me. That all handles getting my changes back into your clone but how do I get changes from your clone into mine? The way I thought you do this – and how I actually did it – was to add your repository as a remote for my local Git repository. Then I pulled the changes from your repository into mine and then pushed those changes back to my cutterpillows-qt-iphone-clone repository on gitorious. From what I've read that seems like the right thing to do the only weird thing that I'm seeing after doing that is that the new merge request (that I created to fix the deprecation warnings and 64-bit vs. 32-bit build issues) includes the merge pushed from your clone as well as my other changes. I don’t know if that’s wrong or not, it just seems a little weird to me.

Anyway, let me know if I'm going in the right direction or way off base. You can view my changes in the 2nd merge request.

Cheers,
Dave

OK, I think I've got it figured out. The reason the changes merged from qt-iphone-clone were being included in the other merge request was because I needed to do a rebase after pulling in your changes. After doing that the other merge request looks right – only my changes are there. It took a bit of searching but I finally found this (which was very helpful):

http://qt.gitorious.org/qt/pages/GitIntroductionWithQt

So have a look at it and let me know what you think.

Cheers

Dave

Looks like a good introduction. I'm not the expert on git, but I use it every day. I would like to mention that I use the gui tools mostly.

From terminal you can use “git gui” in the correct folder will bring a unixy (tk/tlc blocky) gui box, or you can use GitX (only for macosx).

GitX does not handle the more complex git stuff, but it is a good start for committing changes.

I like the way git works so much, that I typically use it for a front end to svn as well.

Regards,
Mark Kromis