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

extern'd symbols in main.cpp, other than main(), fail to link when compiling iOS target

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.2.0
    • 5.2.0 RC1, 5.2.0
    • QPA
    • None
    • Build environment: Mac Mini running OS X 10.8.5 (12F45) targeting iOS iphonesimulator for Qt-5.2.0-RC1
    • iOS/tvOS/watchOS

    Description

      When compiling a project with Qt-5.2.0-rc1, using the prebuilt qt-mac-opensource-5.2.0-rc1-android-ios-x86_64-offline.dmg package, targeting iOS for the iphonesimulator, any symbols in main.cpp that are extern'd to be visible by other parts of the application will fail to link with the following error:

      Undefined symbols for architecture i386:
      ...
      ld: symbol(s) not found for architecture i386
      clang: error: linker command failed with exit code 1 (use -v to see invocation)

      See attached example (iOSTest_01.zip) where a function named "myFunction()" is located in main.cpp and extern'd for use elsewhere in the app. Moving this function to another code file solves it (as illustrated in iOSTest_02.zip). Static symbols within main.cpp are OK.

      It seems to be an issue with the build wrapper script that replaces the main() in main.o to wrap it with a Qt outer wrapper. It is somehow losing those symbols in the process. They are still visible when you run "nm" on the object file, both in main.o and main.o.original, but may be somehow hidden.

      Conversely, on my larger project that I'm working on porting to iOS, it started out with this same error and moving things in main.cpp out to another code file worked to link my symbols, but then causes:

      ld: illegal text-relocation to '__stack_chk_guard' in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/libm.dylib from '_ZN14CMyApplication18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv' in /Users/dewhisna/Documents/programs/Bible/KingJamesPureBibleSearch/build-KJVCanOpener-iphonesimulator_clang_Qt_5_2_0_rc1_ios/Release/KingJamesPureBibleSearch.build/Release-iphonesimulator/KingJamesPureBibleSearch.build/Objects-normal/i386/moc_myApplication.o for architecture i386

      Adding the following to the .pro file will let it build:

      x86:QMAKE_LFLAGS += -read_only_relocs suppress

      But then when it deploys to the simulator, it crashes with the following:

      Starting remote process.
      2013-12-11 23:37:29.044 KingJamesPureBibleSearch[35560:a0b] *** Assertion failure in int UIApplicationMain(int, char **, NSString *, NSString *)(), /SourceCache/UIKit_Sim/UIKit-2903.23/UIApplication.m:2380
      2013-12-11 23:37:29.047 KingJamesPureBibleSearch[35560:a0b] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Unable to instantiate the UIApplication subclass instance. No class named NSApplication is loaded.'

          • First throw call stack:
            (
            0 CoreFoundation 0x027425e4 __exceptionPreprocess + 180
            1 libobjc.A.dylib 0x039e78b6 objc_exception_throw + 44
            2 CoreFoundation 0x02742448 +[NSException raise:format:arguments:] + 136
            3 Foundation 0x02140720 -[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 101
            4 UIKit 0x0119ba80 UIApplicationMain + 526
            5 KingJamesPureBibleSearch 0x001a5d9a main + 1242
            6 KingJamesPureBibleSearch 0x000049a5 start + 53
            )
            libc++abi.dylib: terminating with uncaught exception of type NSException

      This seems like it's still related to the whole wrapping of main() by the iOS build system. The code that's in myApplication.cpp/.h was originally in my main.cpp/.h because it's my own subclass of QApplication needed for my app.

      To see that code, visit:
      http://sourceforge.net/p/purebiblesearch/code/HEAD/tree/trunk/programs/KJVCanOpener/

      You'll find myApplication.cpp and .h down near the bottom of the page...

      Is the QApplication object somehow getting hijacked by the main.o wrapper as well that's causing issues when subclassing it? Or is this something different entirely?

      Attachments

        1. iOSTest_01.zip
          2 kB
        2. iOSTest_02.zip
          3 kB

        Activity

          People

            vestbo Tor Arne Vestbø
            dewhisna Donna Whisnant
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: