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.