GCC 4.2.1 Compiling on Cygwin(Win7 64bit) for iPhone - iphone

This is going to take a long while to explain, but the short version is that I am currently attempting to compile the LLVM GCC frontend for ARMv7 to compile apps for the Cortex-A8(iPhone 3GS). I'm running into an error from LD when compiling libgcc(part of the gcc compilation process) that has been driving me mad!
The command is this:
/usr/llvm-gcc-4.2-2.8.source/build/./gcc/xgcc \
-B/usr/llvm-gcc-4.2_2.8.source/build/./gcc \
-B/usr/local/arm-apple-darwin/bin \
-B/usr/local/arm-apple-darwin/lib \
-isystem /usr/local/arm-apple-darwin/include \
-isystem /usr/local/arm-apple-darwin/sys-include \
-O2 -g -W -Wall -Wwrite-strings -wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-inline -dynamiclib -nodefaultlibs -W1,-dead_strip \
-marm \
-install_name /usr/local/arm-apple-darwin/lib/libgcc_s.1.dylib \
-single_module -o ./libgcc_s.1.dylib.tmp \
-W1,-exported_symbols_list,libgcc/./libgcc.map
-compatibility_version 1 -current_version 1.0
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc \
... long list of .o files ... \
-lc
And the result is typically a lot of undefined references to malloc, free, exit, etc. which typically indicate that libc is not getting compiled in. After going through the list of errors that ld is throwing, I see at the top that it is attempting to pull in /usr/lib/libc.a and complains that it is not the correct platform. Okay, that makes sense, so I spent 5 minutes on google and found an answer. Turns out that if I copy the libSystem.dylib and rename it to libc.dylib, that should solve the problem, but it doesn't. I couldn't find a copy of that file on my phone, so I pulled it directly from the SDK. I then get this strange error:
ld64: in /usr/local/arm-apple-darwin/lib/libc.dylib, can't re-map file, errno=22
At this point, I did everything I could think of. I grabbed a fresh copy of my /usr/lib folder from my iphone and confirmed that libSystem.dylib(and libSystem.B.dylib) wasn't there. I unpacked the raw .ipsw package for iOS 4.2.1 and once again, I could not find a copy of libSystem.dylib there either. I unpacked the iPhoneSDK and MacOS SDK and I managed to find a copy of it in both, but that error just kept persisting. I copied libSystem.dylib, libSystem.B.dylib, tried all sorts of combinations of renaming to libc.dylib and still nothing but errors. I can't find a way to get it to recognize the file and link against it. I also tried linking against the libc.a located in the iphone SDK and that didn't work either. I checked what ./xgcc was firing off, and it was my freshly built copy of arm-apple-darwin-ld64 which should be fine.
A little bit of background here. I built LLVM+Clang 2.8 with no errors, and I rebuilt the ODCCTools with some light modifications to get it to compile on Cygwin(I'll post my changes in a patch along with a tutorial if I can get this to work). I also grabbed the iphone-dev "includes" and "csu" project and those completed successfully, although there really is no point to them since I can't get it to link against crt0.a. I'm running out of ideas here.
Can anyone help me out on this?

I think I may have found out the error. Deep inside ODCCTools, inside ld.cpp on line 2905 it was failing to re-map the file(hence the wonderful message). Since the file was small enough to not worry about it, I just temporarily removed that remapping and just re-addressed the pointer. I'll spend a little time and come up with a better fix for long term solution(and a patch for ODCCTools to work under Cygwin).
If everything goes as planned, then I'll have the GCC compiler cross compiling for iPhone under Cygwin later tonight.

Related

Using -fsanitizer on vscode

Using -fsanitizer while compiling programs helps in finding location of memory leaks easily. But how to use this with vscode.
I only know that for compiling a program in vscode through terminal we need to type in g++ file_name.cpp -o executable_name.exe and for running .\program_name
Adding -fsanitizer to this command as an argument does not work for me. How to compile your program using fsanitizer on vscode?
Edit: I have been trying to use it as
g++ -std=c++17 -O2 -Wall -fsanitize=address
tempCodeRunnerFile.cpp -o tempcodeRunnerfile.exe
But this keeps giving me some kind of error:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lasan: No such file or directory
collect2.exe: error: ld returned 1 exit status
This is unrelated to VSCode. The problem is your platform - MinGW traditionally has poor sanitizer support.
Your MSYS2 environment, MINGW64, only supports UBSAN (with stripped-down error reporting, compile with -fsanitize=undefined -fsanitize-undefined-trap-on-error).
There's also CLANG64 environment, which does have ASAN. Install its Clang (pacman -S mingw-w64-clang-x86_64-clang), and compile using clang++ located at C:\msys64\clang64\bin. If you're compiling from MSYS2 terminal, make sure you start the right one: launch it with clang64.exe, or the "MSYS2 Clang x64" shortcut (I don't remember the exact name).

Building Swift on CentOS

I am building Swift compiler from source on CentOS 6, and am running into a library issue. After fighting with the build script for a while I have got where running ./utils/build-script eventually gives:
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake --build /home/src/swift/build/Ninja-DebugAssert/cmark-linux-x86_64 -- all
ninja: no work to do.
llvm: using standard linker
+ cd /home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64
+ /home/src/cmake-3.4.1-Linux-x86_64/bin/cmake -G Ninja -DCMAKE_C_COMPILER:PATH=clang -DCMAKE_CXX_COMPILER:PATH=clang++ '-DCMAKE_C_FLAGS= ' '-DCMAKE_CXX_FLAGS= ' -DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE -DLLVM_TOOL_SWIFT_BUILD:BOOL=NO '-DLLVM_TARGETS_TO_BUILD=X86;ARM;AArch64' -DLLVM_INCLUDE_TESTS:BOOL=TRUE -LLVM_INCLUDE_DOCS:BOOL=TRUE -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINTERNAL_INSTALL_PREFIX=local /home/src/swift/llvm
CMake Error at cmake/modules/CheckAtomic.cmake:36 (message):
Host compiler appears to require libatomic, but cannot find it.
Call Stack (most recent call first):
cmake/config-ix.cmake:296 (include)
CMakeLists.txt:403 (include)
-- Configuring incomplete, errors occurred!
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeOutput.log".
See also "/home/src/swift/build/Ninja-DebugAssert/llvm-linux-x86_64/CMakeFiles/CMakeError.log".
./utils/build-script: command terminated with a non-zero exit status 1, aborting
(gcc-4.8.2 was what I compiled llvm with)
libatomic is there:
$ locate libatomic
/opt/gcc-4.8.2/lib64/libatomic.a
/opt/gcc-4.8.2/lib64/libatomic.la
/opt/gcc-4.8.2/lib64/libatomic.so
/opt/gcc-4.8.2/lib64/libatomic.so.1
/opt/gcc-4.8.2/lib64/libatomic.so.1.0.0
I just don't know how to tell the build system where to look. I have tried the usual CMAKE_LIBRARY_PATH (exporting on the command line - I am not sure if cmake works like the way LD_LIBRARY_PATH, LIBRARY_PATH work) but it can't seem to find it.
I also don't have root on the machine.
I had not tried building from source on CentOS 6 until I saw this question, but I have been able to build Swift 2.2 on CentOS 7.1 and Ubuntu 14.04, with partial success. A few things to think about:
You will need numerous dependencies required to build Swift, and unless
they happen to be already on the system, you will need root access to
install them.
Use -R flag with the build-script to create a release build.
Building in DebugAssert (the default) will require a lot of memory. In my case even 14 GB was not sufficient. A release build
can be done with about 6 GB.
As for your specific problem, it is related to Clang's dependency on GCC-related packages for headers and libraries. See, for example, Fedora 21 with clang, without gcc.
Even if you installed GCC 4.8.2 and adjusted the path to use gcc and g++ from 4.8.2, Clang may still be looking in the old GCC directories for headers and libraries. CMake first tries to compile a C++ test file that includes the header atomic, which does not exist in the old GCC. So, it then tries to link a C test program that uses the library libatomic, which again doesn't exist in the old GCC. You can see this by looking at llvm/cmake/modules/CheckAtomic.cmake mentioned by usr1234567. CMakeError.log and CMakeOutput.log can also provide valuable insight. BTW, when I was building Swift on CentOS 7.1, I didn't run into this problem because GCC 4.8.2 was used by Clang for headers and libraries and the atomic header was found, so the C++ file got compiled. However, had the libatomic check been done, it would have failed, because libatomic.so in the repository-provided 4.8.2 has INPUT ( <name of some non-existent file> ), so trying to link with libatomic errors out.
I'm sure there are various ways of dealing with this issue, but what solved the problem for me was setting the following environment variables, please adjust to your specific setup:
export CPLUS_INCLUDE_PATH=/opt/gcc-4.8.2/include/c++/4.8.2:/opt/gcc-4.8.2/include/c++/4.8.2/x86_64-unknown-linux-gnu
export LIBRARY_PATH=/opt/gcc-4.8.2/lib64:/opt/gcc-4.8.2/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
Also make sure that your 4.8.2 version of libstdc++.so is available to the dynamic linker at runtime. Since you don't have root, do
export LD_LIBRARY_PATH=/opt/gcc-4.8.2/lib64
If you had root, you could use ldconfig.
Before you start building Swift, you may want to try building, using Clang, a simple C program linking it with libatomic (the code doesn't actually have to use any symbols from the lib) and a simple C++ program that includes the <atomic> header. When compiling the C++ program, use the -std=c++11 compiler flag. If the C++ program compiles successfully, then it is not necessary for the libatomic linking test to be successful.
Interestingly, the CMakeOutput.log file still did not report finding GCC 4.8.2 as a candidate GCC installation, but the configuration/build worked well past the error.
Hopefully this helps. Please let us know if you run into something else.
CheckAtomic.cmake seems to be part of LLVM. I found a file at Github and it tries to find '__atomic_fetch_add_4' from libatomic
check_library_exists(atomic __atomic_fetch_add_4 "" HAVE_LIBATOMIC)
This fails for you. Check CMakeFiles/CMakeError.log to get more details why this test failed. Or try this line in a new project.

gcc linker can't find library (openNI)

Can anybody give me some hints for solving this?
I'm trying to compile "Kinect Matlab" (on Mac OS 10.7), in the compile script is the following line:
mex('-v','-L/usr/lib/','-lOpenNI',[...],Filename);
This is the full command run by mex: (1)
gcc-4.2 -O -Wl,-twolevel_namespace -undefined error -arch x86_64 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -bundle -Wl,-exported_symbols_list,/Applications/MATLAB_R2011a.app/extern/lib/maci64/mexFunction.map -o "mxNiChangeDepthViewPoint.mexmaci64" mxNiChangeDepthViewPoint.o -L/usr/lib/ -lOpenNI -L/Applications/MATLAB_R2011a.app/bin/maci64 -lmx -lmex -lmat -lstdc++
Then I'm getting the following error:
ld: library not found for -lOpenNI
collect2: ld returned 1 exit status
mex: link of ' "mxNiChangeDepthViewPoint.mexmaci64"' failed.
There is most definitely a file at /usr/lib/libOpenNI.dylib.
What kinds of things cause ld to throw this error?
What I tried:
I have tried creating a symlink called libOpenNI.so, like jmlopez suggested, no effect.
Could it be that libOpenNI is a 32bit library, and ld is not seeing it for that reason? Or would the error then be different?
Regarding the point above, it says that the build is "universal x86/x64"
Env vars:
I've tried to add the library to the environment variables using the following command, from the matlab terminal. No effect.
setenv('DYLD_LIBRARY_PATH', [getenv('DYLD_LIBRARY_PATH') ':/usr/lib/']);
In bash:
Just calling gcc as suggested here https://serverfault.com/questions/54736/how-to-check-if-a-library-is-installed gives no problems.
$ gcc -lOpenNi
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
However, if I run g++ first, then gcc as in (1), same error as before. (library not found). How come gcc can find the library, but when matlab adds the stuff in (1) it messes things up?
So, related to what is said above, I started removing all arguments from (1) until I got a different error. I removed the -Wl,-syslibroot, meaning that -syslibroot would no longer be passed to ld, this seems to have fixed it. So -syslibroot is messing up the library search directory! Now to find a way to remove this argument from the mex() call.
Did you trying adding OpenNi to your LIBRARY_PATH ?
export LIBRARY_PATH=$LIBRARY_PATH:/YOUR-PATH/OpenNi
First option: if libOpenNi isn't of the same architecture as the binary you're compiling, the whole compiler suite will likely ignore it. If you did manage to get it to link anyway, it would probably crash. Find a native 64 bit library and link against that.
Second option: I'm not 100% sure on this, but whenever I've tried doing linking on some esoteric linux projects, I start with a .a object archive in the path specified by -L. If it links, then I'll add -fPIC -shared on x86_64 to get it to compile against the shared library. I'm not sure if this will work on OSX: I've never done development on that platform yet.
BOOM! IT WORKS!
Okay, here it is:
The -Wl,-syslibroot option in the gcc call (1) is sending a -syslibroot option to the linker, and somehow that gets prepended to the library search path (even though it shouldn't according to cannot specify root sdk directory with syslibroot when linking)
So, removing this -syslibroot can solve our problem, this can be done in mexopts.sh. Copying matlab's version from the default location:
cp /Applications/MATLAB_R2011a.app/bin/mexopts.sh ~/.matlab/R2011a/
And then changing this line (201):
LDFLAGS="-Wl,-twolevel_namespace -undefined error -arch $ARCHS -Wl,-syslibroot,$SDKROOT -mmacosx-version-min=$MACOSX_DEPLOYMENT_TARGET"
Removing the -Wl,-syslibroot,$SDKROOT argument.
Additionally, I could remove the -L/usr/lib argument from the call to mex, making it simply:
mex('-v','-lOpenNI',['-I' OpenNiPathInclude],Filename);

Cross-compile libgcrypt for the iPhone? Linker error... can't seem to find "fwrite" and "strerror"?

I have successfully cross-compiled the Apache Portable Runtime (APR) for the iPhone, using a set of configure scripts that invoke the GNU Autotools "./configure" with the necessary cross-compilation options.
I am now attempting to cross-compile GNUTLS which depends on libtasn1 and on libgcrypt, which in turn, depends on libgpg-error. This is where I am running into trouble and could use your help...
I am currently trying to cross-compile libgpg-error. The configure scripts that I used before are working beautifully; the "./configure" process completes cleanly. The problems occur when I run "make". When I run make, everything seems to compile, but then I get the following nasty linker error at the end:
/bin/sh ../libtool --tag=CC --mode=link /Users/michaelsafyan/Downloads/libgpg-error-1.7/compile /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -std=c99 -arch armv6 -pipe -no-cpp-precomp --sysroot='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk' -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/gcc/arm-apple-darwin9/4.2.1/include/ -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include -isystem /Developer/Platforms/iPhoneOS.platform/Developer/usr/include -isystem /opt/iphone-3.0/include -isystem /usr/local/iphone-3.0/include -arch armv6 --sysroot='/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk' -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib -L/opt/iphone-3.0/lib -L/usr/local/iphone-3.0/lib -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o ./libgpg-error.la
/Users/michaelsafyan/Downloads/libgpg-error-1.7/compile /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -std=c99 -arch armv6 -pipe -no-cpp-precomp --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib/gcc/arm-apple-darwin9/4.2.1/include/ -isystem /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/include -isystem /Developer/Platforms/iPhoneOS.platform/Developer/usr/include -isystem /opt/iphone-3.0/include -isystem /usr/local/iphone-3.0/include -arch armv6 --sysroot=/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk -o gpg-error gpg_error-strsource-sym.o gpg_error-strerror-sym.o gpg_error-gpg-error.o -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib -L/Developer/Platforms/iPhoneOS.platform/Developer/usr/lib -L/opt/iphone-3.0/lib -L/usr/local/iphone-3.0/lib ./.libs/libgpg-error.a
Undefined symbols:
"_fwrite$UNIX2003", referenced from:
_main in gpg_error-gpg-error.o
"_strerror$UNIX2003", referenced from:
_gpg_strerror in libgpg-error.a(libgpg_error_la-strerror.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[3]: *** [gpg-error] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Any ideas on how to get this to work? The versions of the software that I am compiling are:
libgpg-error: 1.7
libgcrypt: 1.4.4
libtasn1: 2.2
gnutls: 2.8.4
Please help. Thank you.
Update
As per initial feedback, each SDK has a copy of "libSystem.dylib" in "$SDKROOT/usr/lib". There is no copy of libSystem in "$DEVROOT/usr/lib", where:
$DEVROOT = "/Developer/Platforms/iPhoneOS.platform/Developer"
$SDKROOT = "$DEVROOT/SDKs/iPhoneOS$VER.sdk"
The "libSystem" libraries contain the ordinary, undecorated versions, of each symbol, but do not contain the "$UNIX2003" variants of the symbols. I suspect that GPG-ERROR is defining "_POSIX_C_SOURCE", "_UNIX", or another UNIX feature test macro, and that a rogue header that is appending "$UNIX2003" to the functions when these feature test macros are present is being included. Removing "$DEVROOT/usr/include" from the list of include directories has no effect with regard to removing this error message.
As a last resort, I see that "ld" accepts an "-alias_list" option that allows one to specify a file with entries like "_fwrite _fwrite$UNIX2003" to forcibly resolve these undefined symbols to their undecorated variants. If possible, I would like to avoid this option, since it seems hackish and potentially dangerous.
Usually an unresolved symbol$UNIX2003 means that you're linking against an older SDK than the one the existing object files were built against.
One strange looking include path to me, and please note that I'm only vaguely familiar with Mac developement and not at all with iPhone developement, is the path
/Developer/Platforms/iPhoneOS.platform/Developer/usr/include
which is not actually in the SDK folder. Is it possible that you've picked up the rogue symbols, if they are that, from there? Seems unlikely since it occurs later in the command line than the SDK include paths.
Perhaps instead the symbols are the expected versions of _fwrite and _strerror and so gpg_error-gpg-error.o and libgpg-error.a are okay and it's really a linking issue although again unlikely as you have
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/usr/lib
as a -L option. I'm assuming there's a libSystem dylib in there somewhere?
I guess the first thing to do is ascertain whether the UNIX2003 version of the symbol is what you expect or not. My guess is it is, but as I say I could be completely wrong. :)
Secondly you could try getting verbose output from ld to see where it is finding symbols. I'm sure there is an environment variable you can set to make this happen but I can't see any listed in the on-line man page for ld. (Update: The two env variables are LD_TRACE_ARCHIVES and LD_TRACE_DYLIBS but perhaps they give the same as -t?).
Edit:
OK, so I was completely wrong about the UNIX2003 symbols being the ones that were required. lol.
When you built libgpg-error I think it will have created a file
src/.deps/gpg_error-gpg-error.Po
which contains header dependencies (at least it did on my Linux system). This might give a clue as to where it picked up the wrong header when building gpg_error-gpg-error.o.
BTW, it looks as if the libgpg-error configure script accepts both an -isysroot and -archoptions. Can you not use those instead of your own version of the configure script?
Edit2:
Okay, let's have another go :) Here are some things to try, starting from a clean source folder:
use -isysroot instead of --sysroot
use -isysroot as well as --sysroot
temporarily make your normal system headers unavailable by, for example, renaming the folder. Hopefully the build will fall over failing to find a header and it'll tell you exactly where.
Try to preprocess gpg_error-gpg-error.c with -E then search the missing symbols. You should find from where there are inclued (something like asm ("_" "nice" "#UNIX2003").
Then, modify this header (unistd.h for example to add a #warning "HERE").
Now, recompile, and you should find the include stack.
The $2003 suffix is generated by the compiler under some circumstances which you can find fully documented in the manual entry for compat
man compat
I wrestled with this for some time before finally fixing it by setting
-mmacosx-version-min=10.3
Any version prior to 10.4 will do the job. I suspect that given Troubadour's answer I may be better off searching for erroneously linked libraries using the -t option of ld
Hope this helps.

iPhone static library distribution and release build errors (but not for debug)

Update
Daniel was close, it just wasn't the search path. The Prefix Header under GCC 4.2 was set to:
$(SYSTEM_LIBRARY_DIR)/Frameworks/AppKit.framework/Headers/AppKit.h
I missed that when I was combing through the first 2 times.
I removed it and now all is well.
Original Question
I have been using/building products with a static libraries for about a week now with no issues.
For the first time, I tried to make a distribution build (for ad hoc testing) and I am getting errors all over the place.
The errors, strangely say that it can't find Appkit headers. Which is odd because it is an iPhone app and shouldn't be linking to Appkit headers
Additionally, the library name, "libFJSCodeDebug.a" turns red while when I switch from debug to distribution/release. I figure this must be a big clue.
To test, I duplicated the debug configuration and renamed it release. This built fine. So it seems the problem is somewhere in the configuration. Below is a snippet of what I get in Xcode when I build. (Note: I named my target FJSCodeDebug even though it will be used for both debug and release builds)
Building target “FJSCodeDebug” of project “FJSCode” with configuration “Release” — (169 errors)
Checking Dependencies
cd /[redacted]/FJSCode
setenv PATH "/DeveloperBeta/Platforms/iPhoneOS.platform/Developer/usr/bin:/DeveloperBeta/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/DeveloperBeta/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc-4.2 -x objective-c-header -arch armv6 -fmessage-length=0 -pipe -std=c99 -Wno-trigraphs -fpascal-strings -fasm-blocks -Os -Wreturn-type -Wunused-variable -isysroot /DeveloperBeta/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk -gdwarf-2 -mthumb -miphoneos-version-min=3.0 -iquote /[redacted]/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/FJSCodeDebug-generated-files.hmap -I/[redacted]/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/FJSCodeDebug-own-target-headers.hmap -I/[redacted]/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/FJSCodeDebug-all-target-headers.hmap -iquote /U[redacted]/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/FJSCodeDebug-project-headers.hmap -F/[redacted]/build/Release-iphoneos -I/[redacted]/build/Release-iphoneos/include -I/Users/coreyfloyd/Xcode/ProductionProjects/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/DerivedSources/armv6 -I/[redacted]/build/FJSCode.build/Release-iphoneos/FJSCodeDebug.build/DerivedSources -c /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h -o /var/folders/R+/R+ofDLtuH1GOYQ1ZQ2C5mk+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/AppKit-gihvhjsfuggoevbehiszhgrzcska/AppKit.h.gch
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:11:33: error: AppKit/AppKitDefines.h: No such file or directory
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:12:32: error: AppKit/AppKitErrors.h: No such file or directory
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:13:37: error: AppKit/NSGraphicsContext.h: No such file or directory
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:14:35: error: AppKit/NSAccessibility.h: No such file or directory
/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:15:32: error: AppKit/NSActionCell.h: No such file or directory
...... (continues for everything in AppKit)......
Build failed (169 errors)
I'm looking for 1 of 2 solutions:
Obviously, fix the release build to not get these errors
OR
Tweak the debug configuration to have all the important settings that a release configuration requires.
Any ideas??
This
-c /System/Library/Frameworks/AppKit.framework/Headers/AppKit.h
leads me to believe your build target is trying to compile AppKit.h for some reason (while I don't think it should be doing that at all), and/or it's looking for it in the wrong place (i.e. in the root /System instead of in the SDK /Developer/Platforms/...).
You should double check your build settings library/frameworks search paths, and that AppKit.h isn't in the compile phase.
Does your project include Mac OS products? Are you sure you haven't accidently included a Mac library/framework in your frameworks group?
In SDK2.2.1, I don't know why, but the thing that always gets me is when "Active SDK" and "Active Executable" become out of sync (in the build configuration dropdown). This leads to weird linker errors where the iPhone tries to dynamically link against its libraries. This setting seems to occasionally go out of sync whenever I switch from debug/release or device/simulator.
Perhaps its a similar case, its hard to tell without seeing the actual project settings.