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

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.

Related

xcodebuild -create-framework error: unable to read the file

I have watched "binary framework in swift" and tried to build xcframework using xcodebuild -create-framework but it is not working properly.
I enabled "Build libraries for Distribution", then I archived and then used the command
xcodebuild -create-framework -framework /path/sample.xarchive -output sample.xcframework
But it is showing an error "unable to read the file at /path/sample/sample".
I am not sure what I am missing.
Sysytem Info:
MacOS: Catalina beta 1
Xcode 11
Here are step by step instructions, I think you might be missing step 2:
1) Set Build Library for Distribution in the build settings for the target framework to YES
2) Again in the build settings, set Skip Install to NO otherwise the framework won't show up in the Archive output folder.
3) Archive from the Xcode Product menu after selecting your Generic iOS Device the output will appear in the Organizer. Control-Click on the Archive. Select Show in Finder Drag that to the terminal to get the path to the archive and append the path (yellow part is the dragged path, gray is navigated in subfolders). In this case it looks like this, I used the ~ to avoid showing entire path.
~/Library/Developer/Xcode/Archives/2019-06-22/Output\ 6-22-19,\ 11.50\ AM.xcarchive/Products/Library/Frameworks/MyFramework.framework
4) Then create the XCFramework by inserting the command in front of the above path:
xcodebuild -create-xcframework -output Output.xcframework -framework ~/Library/Developer/Xcode/Archives/2019-06-22/Output\ 6-22-19,\ 11.50\ AM.xcarchive/Products/Library/Frameworks/MyFramework.framework
5) You then should see the output:
xcframework successfully written out to: ~/Project/Output.xcframework
I expect that someday soon Xcode will add a the ability to directly create the XCFramework without the command line.
You have to do a two step process via the command line.
xcodebuild archive
This will archive the framework and stick it likely in the build directory of your project.
xcodebuild -create-xcframework -output FrameworkName.xcframework -framework build/Release-iphoneos/ArchivedFramework.framework
This should successfully generate the XCFramework.
You typed the command wrong:
xcodebuild -create-xcframework -framework /path/sample.xarchive -output sample.xcframework
In my case it was failing for iPhone as arm64 architecture was added in the Excluded Architecture in Build Settings

facebook ios sdk build fails on device, works on simulator

I am trying to build an app (with ARC) that uses the facebook_ios_sdk (the latest version on github).
As recommended by Facebook, I used the build script to create a static library and then added it to the project.
Now when I build the project for an iPhone 5.1 Simulator, it works fine. However, on running it for an actual device (which is running 5.1), it gives the following build error -
ld: in ../facebook-ios-sdk/libfacebook_ios_sdk.a, file is universal but does not contain a(n) armv7 slice for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any suggestions on how to resolve this?
You could modify the build script for static library (which was too complicated for me), or just skip the library approach:
add the Facebook sources from SDK to your project
if using ARC, go to "target->build phases->compile sources" and mark all the Facbook source files with the--fno-objc-arc flag
That's it, works for me.
One work around that worked was to change the Valid Architectures from"armv6 armv7" to just armv6

Xcode 4 - clang error

I'm migrating from Xcode 3.5 to Xcode 4 and
while I'm trying to Archiving my app for AdHoc distribution.
I received this error
Precompile MyApp_Prefix.pch
ProcessPCH /Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/Build/PrecompiledHeaders/MyApp_Prefix-crxrbmeralwexyefvuwvzexquuin/MyApp_Prefix.pch.pth MyApp_Prefix.pch normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
cd /Users/return/Projects/iphone-MyApp
setenv LANG en_US.US-ASCII
setenv PATH "/Xcode4.2/Platforms/iPhoneOS.platform/Developer/usr/bin:/Xcode4.2/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
/Xcode4.2/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -x objective-c-header -arch armv7 -fmessage-length=0 -fdiagnostics-print-source-range-info -fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -std=c99 -Wno-trigraphs -fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -DFAVOURITES_ENABLED=0 -isysroot /Xcode4.2/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk -gdwarf-2 -fvisibility=hidden -Wno-sign-conversion -mthumb "-DIBOutlet=__attribute__((iboutlet))" "-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))" "-DIBAction=void)__attribute__((ibaction)" -miphoneos-version-min=3.0 -iquote "/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/MyApp-generated-files.hmap" "-I/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/MyApp-own-target-headers.hmap" "-I/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/MyApp-all-target-headers.hmap" -iquote "/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/MyApp-project-headers.hmap" "-I/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/BuildProductsPath/Distribution-iphoneos/include" "-I”/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp" -I- "-IDistribution/BuildProductsPath/Distribution-iphoneos/../three20″" "-I“/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp" -I- "-IDistribution/BuildProductsPath/Distribution-iphoneos/../../three20″" -Ithree20/Build/Products/three20 -I/Xcode4.2/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/include/libxml2 "-I/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/DerivedSources/armv7" "-I/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/IntermediateBuildFilesPath/MyApp.build/Distribution-iphoneos/MyApp.build/DerivedSources" "-F/Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/ArchiveIntermediates/MyApp - Distribution/BuildProductsPath/Distribution-iphoneos" -c /Users/return/Projects/iphone-MyApp/MyApp_Prefix.pch -o /Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/Build/PrecompiledHeaders/MyApp_Prefix-crxrbmeralwexyefvuwvzexquuin/MyApp_Prefix.pch.pth -MMD -MT dependencies -MF /Users/return/Library/Developer/Xcode/DerivedData/MyApp-cwtxjgdpsvtoyxcfpytllmzaxceb/Build/PrecompiledHeaders/MyApp_Prefix-crxrbmeralwexyefvuwvzexquuin/MyApp_Prefix.pch.d
**clang: error: '-I-' not supported, please use -iquote instead**
**Command /Xcode4.2/Platforms/iPhoneOS.platform/Developer/usr/bin/clang failed with exit code 1**
Do you know what I should do to fix this?
UPDATE (report result after followed MacMade's suggestions)
So in the Target Build Settings:
I have nothing in Other C flags.
I have nothing in User Header Search Paths
In Header Search Paths, I have:
”$(BUILT_PRODUCTS_DIR)/../three20″
“$(BUILT_PRODUCTS_DIR)/../../three20″
./three20/Build/Products/three20
/usr/include/libxml2
but I'm not sure what to change here.
In Compiler for C/C++/Objective-C setting,
I switched from Apple LLVM compiler to LLVM GCC and get this message:
cc1obj: note: obsolete option -I- used, please use -iquote instead
cc1obj: error: -I- specified twice
cc1obj: note: obsolete option -I- used, please use -iquote instead
UPDATE (report result after followed MacMade's updated suggestions)
So I move:
”$(BUILT_PRODUCTS_DIR)/../three20″
“$(BUILT_PRODUCTS_DIR)/../../three20″
to User Header Search Paths
and it works!!!
(NOTE: I don't move ./three20/Build/Products/three20 because I see
can't find <Three20/Three20.h>
errors while building the project if I do.)
Apparently, you've set custom compiler flags for the include paths.
Go to your target's build settings and check this option:
Other C flags
If you have something in it, you may replace it by the -iquote version.
Otherwise, still in the build settings, check the value of the following options:
Header Search Paths
User Header Search Paths
Try to manipulate these values, if applicable.
Otherwise, you may also continue to use GCC as a fronted, instead of Clang.
You can do this by setting the Compiler for C/C++/Objective-C build setting to LLVM GCC instead of Apple LLVM compiler.
EDIT
Based on your edit, I can see you are using the Three20 library.
Depending on how you include that stuff, you may want to put these search paths to the User Header Search Paths, instead of Header search paths (if you include them with "" instead of <>).
Try to do this for Three20, but leave libxml here...
I tried these solutions. But i couldn't or not working for me.
I solved this problem with this way:
I deleted MuseumTests in targets
When you clicked your project in general tab on left there is targets
You can solve this problem by selecting General tab of AppNameTests and select your app from the drop down list and enable "Allow testing Host Applications APIs"
I just had this problem with an instagram lib, my mistake was that i was importing the files to a target and compiled the other target. It gave me some headaches.
Hi guys we did something that worked...
We had the same problem and it was quite easy to solve...
First you go to terminal type cd
cd (drag the whole folder where your file is in) and press return
after you are inside the folder you have to write:
pod instal and type return
something like that....
Last login: Wed Aug 21 09:19:29 on console
WozMac1:~ KrisBasque$
WozMac1:~ KrisBasque$
WozMac1:~ KrisBasque$
WozMac1:~ KrisBasque$ cd
WozMac1:~ KrisBasque$ cd /Users/KrisBasque/Documents/QUADDRO/medapp
WozMac1:medapp KrisBasque$ pod install
Analyzing dependencies
CocoaPods 0.23.0 is available.
Downloading dependencies
Using AFNetworking (1.3.1)
Installing FMDB (2.1)
Using MBProgressHUD (0.7)
Using PSStackedView (1.0)
Using Reachability (3.1.1)
Installing SDWebImage (3.3)
Using TapkuLibrary (0.2.4)
Installing libwebp (0.3.0-rc7)
Generating Pods project
Integrating client project
WozMac1:medapp KrisBasque$
The way I solved this was my making sure no other implementation files we're linked to your file. Linking interface files is fine though
This error also caused by wrong header import.
For example your class is "yourclass.h", but in wrong way if you import "yourclass.m" it is cause this error.

GCC 4.2.1 Compiling on Cygwin(Win7 64bit) for 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.

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.