Compiler failures when checking framework targets

Issue #38 resolved
mcdonaldryan NA
created an issue

When a CocoaTouch Framework Target is added to the project FauxPas encounters errors when checking code:

ERROR: FATAL: Unrecoverable compiler error: translation unit is NULL: /Users/ryanmcdonald/Documents/Development/iOS/MyDemoApp/MyDemoApp/main.m

Comments (15)

  1. Ali Rantakari repo owner

    Thanks for reporting this.

    • What version of Xcode are you using?
    • On what version of OS X?
    • What (iOS/OS X) SDK is your project using?

    Please try clearing the project caches in Faux Pas (via the Project > Clear Project Caches menu item), and let me know if that helps.

  2. Tai Heng


    I'm running into this issue now with a dynamic framework target. I've created a clean project with a single source file which will build and run on its own. This repo has the Faux Pas config that I used which fails for me on my machine.

    • Xcode: Version 6.4 (6E35b)
    • OSX: 10.10.5 (14F27)
    • iOS: 8.4 (latest)
    • Faux Pas: V 1.5
  3. Ronak Patel


    This is still happening with XCode 7. Is there any reason why this won't be fixed? If not, it really diminshes the value of this tool. I am on Faux Pas 1.6.


  4. evgenykarkan

    Same issue is actual for me too. In my case - I'm working on cross-platform app - Mac/iOS, I have a complex workspace with 8 targets (2 - framework targets, 2 - framework unit tests, 2 - apps, 2 - unit tests for apps).

    When I try to check my Mac.framework target with FauxPas tool - I've got an error message - "ERROR: Initialization: Error parsing precompiled header # 1: Translation unit is NULL."

    Xcode v7.0.1, FauxPass v1.6, El Capitan. Hope this info will be useful to fix the issue.

  5. Ali Rantakari repo owner
    • changed status to open

    Thanks for reporting this. I am guessing that this has to do with the version of Clang Faux Pas 1.6 is using (OSS 3.7-release) but I will try my best to find a workaround until Apple releases the sources for the "Xcode 7" version of Clang.

  6. Ali Rantakari repo owner

    Okay, here is a potential workaround:

    Add the value DEFINES_MODULE=NO to the “Additional xcodebuild arguments to use” (--extraXcodebuildArgs) option.

    This seems to work around this issue for the Stripe project (ping @Jack Flintermann) — @evgenykarkan and @ronak2121 please let me know if this works for you, too.

  7. mildm8nnered

    I'm seeing this exact same problem. DEFINES_MODULES=NO fixes the immediate problem, but also affects various CocoaPods in my workspace, and so my build simply breaks later on.

    Am trying to see if I can work around this somehow, but is there any news on a more permanent fix @Ali Rantakari?

  8. Log in to comment