I am trying to compile the freetype2 library for arm7, using Xcode's command line tools in OSX. I am using the following parameterisation of the project's configure script:
Compiling FreeType for iPhone?
These errors were produced when running the script:
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E conftest.c
In file included from conftest.c:10:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/include/limits.h:15:25: error: limits.h: No such file or directory
configure:3426: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/gcc -E -traditional-cpp conftest.c
conftest.c:12: error: assert.h: No such file or directory
configure:3426: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
configure:3465: result: /lib/cpp
configure:3485: /lib/cpp conftest.c
/Volumes/DATA/filestore/development/libs/c/freetype2/extract/2.5.3/builds/unix/configure: line 1600: /lib/cpp: No such file or directory
I can see that the missing files actually do exist in the directories output in the error messages.
CFLAGS and LDFLAGS contain the following parameter, which should allow for the inclusion of system header files:
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/
The other odd thing that I noticed with these error messages, is that the architecture identifier in the directory structures is i686-apple-darwin10. The -arch armv7 compiler flag is being used, so why are i686-apple-darwin10 directories being inspected at all?
* UPDATED *
I also tried parameterising the configure script as per another example:
https://stackoverflow.com/a/12594507/1704014
The following error terminated its execution:
checking for suffix of native executables... ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
configure: error: native C compiler is not working
This also indicates that a different target architecture (OSX 10.6) is being built against, not arm7.
Any help much appreciated.
The problem in my OSX build environment was the Xcode command line tools installation. I reinstalled the latest distribution of the tools, and was able to compile successfully from then on.
To build the freetype2 library for arm7 and arm7s architectures, I found the following suggested commands useful:
https://stackoverflow.com/a/12594507/1704014
Related
I'm trying to compile a very small amount of C source into a library that I can use in XCode for an iOS application.
The files are a single .c file and three header files. I'm very new to C, and no matter what I try I can't seem to get them to compile into a library that supports iOS architectures.
The files depend on the openssl library, and I've got that installed and working fine.
I just need to know the process of compiling these four files into a single library. I've found a plethora of information on the subject online, but I can't decipher which parts are necessary for what I'm trying to do.
I've tried the following:
gcc -fPIC -c main.c
gcc -shared -o mylib.so main.o -lcrypto -lssl
which seems to compile it for x86_64, (I've not tested the resulting file, just checked it's arch).
I've also tried
./configure --disable-shared --enable-utf8 --host=arm-apple-darwin CFLAGS="-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk" CXXFLAGS="-arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk" LDFLAGS="-L." CC="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc" CXX="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++"
which only gives me errors
checking for arm-apple-darwin-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/Users/nathanf/compilec':
configure: error: C compiler cannot create executables
I've been scouring the internet for the last few days trying to figure this out, but it's so convoluted to cross compile just a few files and I'm frustrated so I came here for some input.
Any help would be greatly appreciated.
I am targeting the Cortex-A7 (ARMv7-A)
As a test:
bootstrap.s
.globl _start
_start:
mov sp,#0x00010000
bl main
hang: b hang
main.c
int main(void) { return 0; }
Trying:
$ as -arch armv7 -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 bootstrap.s -o bootstrap.o
$ file bootstrap.o
bootstrap.o: Mach-O object arm
$ clang -c -arch armv7 -march=armv7-a -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 main.c -o main.o
$ file main.o
notmain.o: Mach-O object arm
Confirms the compilation of Mach-O arm object files (also verified using hexdump, otool, gobjdump)
But now we try to link them together:
$ ld -e _start -arch armv7 bootstrap.o main.o -o foo
ld: warning: -ios_version_min not specified, assuming 6.0
ld: building for iOS, but linking in object file built for OSX, file 'bootstrap.o' for architecture armv7
And we have some issues. Not sure what's going on here. I haven't asked to link-in any iOS-related stuff. Using the -t linker flag confirms that no other objects are being linked in. Not sure why it thinks bootstrap.o is built for OS X when it clearly is a Mach-O arm file. Not sure if I'm passing the right flags to the assembler (pretty much all of them are undocumented?) or the linker
Note that this is for a bare-metal mini-project running on RPi2. I'm going to gobjcopy the linked executable object to a flat binary anyways. I'm just working with Mach-O since that's the only object type the system linker on OS X is capable of working with (and fat Mach-O). If I built a separate cross-compiler, I would be doing the exact same thing, instead I'd be linking ELF files before converting them to flat binary (I can output ELF32 files using clang/llvm anyways, I just cant link them). Seems silly to build a separate cross-compiler when clang/llvm is a perfectly suitable cross-compiler that's able to target my microarchitecture
Here's the error:
Undefined symbols for architecture armv7:
"___udivmodsi4", referenced from:
_sqlite3BitvecSet in libmergDropboxSync.a(sqlite3.o)
_sqlite3BitvecClear in libmergDropboxSync.a(sqlite3.o)
_sqlite3BitvecTest in libmergDropboxSync.a(sqlite3.o)
ld: symbol(s) not found for architecture armv7
collect2: ld returned 1 exit status
lipo: can't open input file: /var/folders/np/1scdfrdd7kx64bbykn22wj200000gn/T//ccvBM79H.out (No such file or directory)
error: linking step of external dylib build failed, probably due to missing framework or library references - check the contents of the mergDropboxSync.ios file
Command /bin/sh emitted errors but did not return a nonzero exit code to indicate failure
When I build for the simulator it builds fine. My library is compiling fine. It's only at the linking stage for the dylib that is documented in lclink.sh as only for a dependency check for device builds that there's an issue:
# Build the 'dylib' form of the external - this is used by simulator builds, and as
# a dependency check for device builds.
"$PLATFORM_DEVELOPER_BIN_DIR/g++" -dynamiclib $ARCHS -isysroot "$SDKROOT" -o "$BUILT_PRODUCTS_DIR/$PRODUCT_NAME.dylib" "$BUILT_PRODUCTS_DIR/$EXECUTABLE_NAME" $SYMBOL_ARGS $SYMBOLS $DEPS
if [ $? != 0 ]; then
echo "error: linking step of external dylib build failed, probably due to missing framework or library references - check the contents of the $PRODUCT_NAME.ios file"
exit $?
fi
I tried skipping this step using the following:
if [ "$EFFECTIVE_PLATFORM_NAME" == "-iphonesimulator" ]; then
# Build the 'dylib' form of the external - this is used by simulator builds, and as
# a dependency check for device builds.
"$PLATFORM_DEVELOPER_BIN_DIR/g++" -dynamiclib $ARCHS -isysroot "$SDKROOT" -o "$BUILT_PRODUCTS_DIR/$PRODUCT_NAME.dylib" "$BUILT_PRODUCTS_DIR/$EXECUTABLE_NAME" $SYMBOL_ARGS $SYMBOLS $DEPS
if [ $? != 0 ]; then
echo "error: linking step of external dylib build failed, probably due to missing framework or library references - check the contents of the $PRODUCT_NAME.ios file"
exit $?
fi
fi
This allowed the script to continue on and build the object files for static linking in the device builds. They built fine but then when I went to build the standalone the dependency check blocked it. Is there any workaround anyone can recommend?
Note that I use a slightly modified lclink.sh which adds weak linking support and optional framework inclusion depending on the SDK you're building against. It can be found here if that helps:
http://repo.goulding.ws/livecodeiossdk/src/b570507fe48274cc4c0f90102809194eafe5225d/lclink.sh?at=master
EDIT
Given that the error was clearly armv7 related I tried a build against armv7s and it builds fine. I'm coming to the conclusion that the the new dropbox sync sdk may have some armv7s only code. It appears to be sqlite related based on the error. Not sure what else to try at this stage...
EDIT
It appears to be a toolchain issue caused by the Dropbox sync api being compiled with Apple LLVM and LiveCode externals and device builds being compiled with Apple GCC.
Does this help any? I wrote this up when I was having a somewhat similar problem.
runrev lesson on linking to a dylib library
I was working on a project and all were going well until I decide to clean my project.
The following errors appears only when I run my app on simulator (working fine on a real device) :
Libtool /Users/Yaman/Library/Developer/Xcode/DerivedData/Homeless-gujyzhsiwenufvedlinbbtrizcpd/Build/Products/Debug-iphonesimulator/libShareKit.a normal i386
cd "/Users/Yaman/Documents/iOS - App à vendre/Homeless/Submodules/ShareKit"
setenv IPHONEOS_DEPLOYMENT_TARGET 4.0
setenv PATH "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only i386 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -L/Users/Yaman/Library/Developer/Xcode/DerivedData/Homeless-gujyzhsiwenufvedlinbbtrizcpd/Build/Products/Debug-iphonesimulator -filelist "/Users/Yaman/Library/Developer/Xcode/DerivedData/Homeless-gujyzhsiwenufvedlinbbtrizcpd/Build/Intermediates/ShareKit.build/Debug-iphonesimulator/Static Library.build/Objects-normal/i386/ShareKit.LinkFileList" -ObjC -all_load -lCopy -lDelicious -lDiigo -lEmail "-lEvernote SDK" -lEvernote -lFacebook "-lFlickr SDK" -lFlickr -lFoursquareV2 "-lGoogle Reader" -lInstagram -lInstapaper -lJSONKit -lKippt -lLinkedIn -lLogout -lOAuth "-lOpen in Safari" -lPinboard -lPrint -lReachability "-lRead It Later" "-lSave to Album" -lShareKitCore "-lSina Weibo" -lSSKeyChain "-lText Message" -lTumblr -lTwitter -lVKontakte -o /Users/Yaman/Library/Developer/Xcode/DerivedData/Homeless-gujyzhsiwenufvedlinbbtrizcpd/Build/Products/Debug-iphonesimulator/libShareKit.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified, -all_load invalid
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: -dynamic not specified the following flags are invalid: -ObjC
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lReachability
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lReachability is not an object file (not allowed in a library)
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1
I got these errors when running command xcodebuild directly from a terminal :
** BUILD FAILED **
The following build commands failed:
Libtool "build/ShareKit.build/Release-iphoneos/Static Library.build/Objects-normal/armv7/libShareKit.a" normal armv7
Libtool "build/ShareKit.build/Release-iphoneos/Static Library.build/Objects-normal/armv7s/libShareKit.a" normal armv7s
(2 failures)
Someone can figure out what's happened here ?
I just got this error. The project works very well, you add a new lib and BAM, build failed.
I my case, Xcode5 had added some special \" around my header search paths values.
Like that :
\"$(SRCROOT)/myproject/Libraries/lib\"
Quite impossible to find out, but when spending hours to find where is the problem, I finally tried to change to
$(SRCROOT)/myproject/Libraries/lib
And the build success came back... thanks Xcode!
The first error note says that compiling ShareKit failed, because Reachability is missing. I'd propose that you check your compiling environment has latest (or compatible) version of the library.
That's why libShareKit.a mentioned in last error note is missing and compiling your app failed. Try to compiling ShareKit alone and when it's done, try again the whole app.
Starting from some point in the past xCode 4 in complaining about linker problems:
ld: warning: building for MacOSX, but linking against dylib built for
iOS:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/System/Library/Frameworks//CoreGraphics.framework/CoreGraphics
I have checked everything but still nothing suspicious in the config and it compiles and runs.
The only thing that I see it is double slashes before CoreGraphics.framework, why I do not know. Tried remove and add again library on "Build phases" that did not help.
Sometimes it's easier to debug Xcode problems by looking at the build log for the command lines it's using.
If you're building from the command line, you can get that message if you don't specify -miphoneos-version-min=
This compiles:
(where conftest.c just contains int main() {})
/Applications/Xcode5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -miphoneos-version-min=6.0 conftest.c
And this gives the error:
/Applications/Xcode5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk conftest.c
ld: building for MacOSX, but linking against dylib built for iOS Simulator file '/Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/usr/lib/libSystem.dylib' for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Check your Framework Search Paths for your Main target and your test Target.
I had a lot of crap in mine.
had old project written in XCode 4 and just started to use Unit Tests in XCode 5.
Here's the minimum I have to get my test project to run
Project Navigator > click on project at top >
Targets > Build Settings > Framework Search Paths
TARGET:my_project
$(inherited)
"$(SRCROOT)"
"$(SRCROOT)/my_project"
TEST:my_projectTests
"$(SDKROOT)/Developer/Library/Frameworks" <<XCTest.framework is here
"$(DEVELOPER_LIBRARY_DIR)/Frameworks"
"$(SRCROOT)/.."
"$(SRCROOT)" << Documents/my_project
"$(SRCROOT)/my_project" << Documents/my_project/my_project
where directory structure is
Documents/my_project
my_project.xcodeproj
/my_project
Note: If you drag a framework into XCode. XCode 5 has bad habit of hardcoding the path
/Users/gbxc/Documents/my_project
should be
"$(SRCROOT)" << Documents/my_project
"$(SRCROOT)/my_project" << Documents/my_project/my_project
so if you moved your project might get problems
Best way to check whats correct is to create a new single view project that runs tests ok.
Run the Test action
By default it fails but at least testing is running
then compare the Framework Search Paths.
If you're using Carthage and compiling a Mac app, search on your project's Framework Search Paths you might find something like $(PROJECT_DIR)/Carthage/Build/iOS.
Removing that fixed my issue.
This issue is due to include a wrong framework version in Xcode. The project is built for Mac OS X, but it uses iOS version's framework.