Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-22541

Qt not building when using a custom Xcode location

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Not Evaluated
    • 5.1.0
    • 4.8.0
    • Build System
    • None
    • Mac OS X (10.6.x in casu), Xcode 3.x or 4.x.

    Description

      Note: we're currently having the same issue with the 4.7.x releases, so the problem is not new. It would be great to have this fixed in 4.8 though, so we don't have to patch releases ourselves.

      Setup: a recent Mac OS X - 10.6.7 in my case, but that's not too relevant. Install a somewhat recent Xcode, for instance 3.2.x, but make sure to install it in a custom location like /Xcode-3.2 or something (not in /Developer!) and with the option "UNIX Development" disabled. Note that if you have another Xcode on the system already, the last option will probably not have the desired effect since your previously installed Xcode already put tools like gcc, g++, make etc in /usr/bin and headers in /usr/include. In that case you might need a clean Mac OS X system. You can try the Xcode uninstall script, but I noticed not all versions are cleaning up everything nicely...

      We are using this setup on our Mac build systems, because those tend to have several Xcode versions installed, and we want to be sure that only files from the selected Xcode are used for a particular build, instead of files "randomly floating around on the system, put there by who knows what Xcode version".

      Now, I got myself a Qt 4.8 source tree from git and started building and checking the configure step.

      We use a shadow build, and with the target directory as working directory, the command executed by our build system boils down to something like this:

      CC=/Xcode-3.2.1/usr/bin/gcc-4.2 CXX=/Xcode-3.2.1/usr/bin/g++-4.2 MAKE=/Xcode-3.2.1/usr/bin/make ../../Qt/qt/configure -debug -arch i386 -platform macx-g++42 -shared -opensource -stl -nomake demos -nomake examples -plugin-sql-sqlite -plugin-sql-odbc -qt-zlib -qt-libpng -qt-libmng -qt-libtiff -qt-libjpeg -no-dbus -carbon -no-framework -sdk /Xcode-3.2.1/SDKs/MacOSX10.5.sdk -confirm-license 

      These were the issues I've found so far:

      1. The configure script has hard coded "/Developer" parts in it, in some 10.4 SDK checks. We're not installed in /Developer, so neither are the SDKs. So the check is wrong in this case.

      2. After fixing that, we run into these errors:

      Preparing build tree...
      /Users/development/Qt/qt/config.tests/mac/xcodeversion.cpp:42:20: error: stdlib.h: No such file or directory
      /Users/development/Qt/qt/config.tests/mac/xcodeversion.cpp:43:19: error: stdio.h: No such file or directory
      /Users/development/Qt/qt/config.tests/mac/xcodeversion.cpp:44:43: error: CoreFoundation/CoreFoundation.h: No such file or directory
      /Users/development/Qt/qt/config.tests/mac/xcodeversion.cpp:45:27: error: Carbon/Carbon.h: No such file or directory
      ...
      

      The reason is that the UNIX tools are not installed, so the compiler can't find those headers in /usr/include etc. As a result, the associated dwarf2 test will fail, and the configure step thinks there's no DWARF2 support. The cause is clear: this test is not taking into account the custom setting for the SDK, and it's not using -isysroot or -syslibroot to reflect that.

      3. After fixing that, we get similar problems:

      floatmath auto-detection... ()
      ...
      /Users/development/Qt/qt/config.tests/unix/floatmath/floatmath.cpp:42:18: error: math.h: No such file or directory
      /Users/development/Qt/qt/config.tests/unix/floatmath/floatmath.cpp: In function 'int main(int, char**)':
      /Users/development/Qt/qt/config.tests/unix/floatmath/floatmath.cpp:46: error: 'ceilf' was not declared in this scope
      /Users/development/Qt/qt/config.tests/unix/floatmath/floatmath.cpp:47: error: 'floorf' was not declared in this scope
      ...
      make[1]: *** [floatmath.o] Error 1
      floatmath disabled.
      
      mmx auto-detection... ()
      ...
      g++-4.2 -headerpad_max_install_names -o mmx mmx.o     -mmmx 
      ld: library not found for -lcrt1.o
      collect2: ld returned 1 exit status
      make[1]: *** [mmx] Error 1
      mmx disabled.
      

      And many more. Again, the cause is those compile tests are not using -isysroot or -syslibroot properly to find the files they need.

      I fixed these issues locally and I'll try to get them in git, so I can ask for a review/merge request. Consider this logged so I can refer to all the details in it later. If you prefer a patch here, just ask

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            vestbo Tor Arne Vestbø
            dannyb dannyb
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes