I have some externally pre-compiled libraries for iOS some for debug and some for release
I can just "add new files" to the project with the .a files but this is for all configurations. I want some when Debug is built, and the others when Release is built.
I did it by putting the libraries in the OTHER_LDFGLAGS setting.
They have two fields one for Debug and one for Release I just put the paths to the files in there. Is there a better way?
I had the same issue earlier today - the suggested solution was to add the libraries to the Other Linker Flags setting on a per-configuration basis. The details are here.
Related
I'm importing a newer version of a custom framework LCCommLibrary that creates the LCConnection class and I'm absolutely perplexed why this will build but not archive after trying multiple things.
Making sure the targets are added (4 apps, 1 Test)
Cleaning and Restarting the Project
This does builds and runs to my iOS devices, but none of the targets will Archive.
Archive usually uses the Release build configuration while building/running on the device uses the Debug build configuration, this is the hint that you have an issue there.
I would say in your case you can to go into the target's build settings, then look at Other Linker Flags, Runpath Search Paths and Library Search Paths, expand them to show the Debug and Release configurations and then ensure you have the same settings for both of them, you'll most probably find something missing in release in one of those.
Finally found the issue. The culprit was framework that was included was a debug version of the framework. This causes Archive Schemes to throw this error since the archive uses the Release as the default.
The resolution was to open the LCCommLibrary Project separately, change the Framework Target's Run Scheme to Release, Run and Build, Locate the target framework, import and embed that back into main project file, and archive as usual.
To link binaries to you framework you can from build phase add your needed libraries to your project .. but what if I need to make some thing specific for example I need to customise my framework by adding or deleting binaries.. foe example I want lite version and full version so I need always to delete and add these binaries from "Link binary.." tab
Is there any dynamic way like to make different configuration files or some thing?
You'd need to create 2 Xcode targets, one for lite and one for pro, which compile the same source files and link to mostly the same frameworks etc.
You can also add compiler constants to the Build Settings of these targets, which will allow the common source files to behave differently between these target "products".
I've created an iOS framework project using the famous (and excellent) iOS Universal Framework Xcode template.
But now I've encountered an annoying problem that I can't seem to fix which is that I have an iOS application project that references the framework project and when I run that and have breakpoints set in the framework they don't get it. It seems GDB doesn't have the debug symbols for the framework.
I've made sure that debug symbols are not stripped from the framework and the type is set to "DWARF with dSYM file".
Anyone have any ideas what might be wrong and how to fix it?
My setup:
Xcode 4.2.1
iOS SDK 5.0
I ran into this issue while linking a dynamic framework to a test application in Xcode 7. I was able to avoid the error by ensuring the following in the build settings of my dynamic framework:
"Generate Debug Symbol" - 'Yes'
"Strip Debug Symbols During Copy" - 'No'
Several things comes to my mind regarding your problem. Give them a try and see which ones work for you:
Make sure to have the "Other Linker Flags" on the "Linking" section of the framework's "Build" Info.
Make sure that you have the framework's built in the correct configuration (ie, if you compiled the framework's in Release and are using it with your project set to Debug you might get issues)
Make sure you added the correct framework .a file to your project (actually two issues here: you can have added the Release version - so no debug symbols in there - AND you have to make sure that your projec is not pointing to some old build version)
Check that both the framework's and your project have the "Level of Debug Symbols" on the "Code Generation" section of the "Build" Info set to "All Symbols [full, -gstabs+ -fno-eliminate-unused-debug-symbols]"
If all alse fails try to empty the XCode caches and remove the framework reference from your project. Then clean and rebuild the framework (all configs: device-debug, device-release, simulator-debug, simulator-release, ...) and add it again to you project. Clean and rebuild your project and cross your fingers... :-)
I have also experienced this issue. One way that I have been able to work around this by merging both projects into a single workspace.
Instructions on how to do this can be found at http://developer.apple.com/library/ios/#recipes/xcode_help-structure_navigator/articles/adding_a_project_to_a_workspace.html.
NOTE: I have also experienced a bug adding projects to workspaces where there appears to be no files in the recently added project to the workspace. I have found this is easily remedied by restarting Xcode after all of the projects have been added to the workspace.
I'm having a problem building libraries that have a "configure" script, namely such scripts are not meant for compiling for iOS.
Is there a set of environment variables that I can set to induce "configure" to work for iOS?
I tried setting CC but that was not nearly enough.
Thanks.
Github project with static libraries and headers that build properly for iOS.
From the readme (Nov 2011):
LibArchive Static Library for iOS Unfortunately, while
libarchive.dylib and libbz2.dylib are included in the iOS SDK, the
header files are not. This means that they are private APIs and cannot
be used if you intend to submit to the App Store.
Never fear! This repository contains everything you need to build a
static version of libarchive for iOS. libbz2 is also included for
extra goodness.
To keep naming of things sane, we build the library as libarc.a.
For iOS 4.3+ copy the header files and library from the
build-for-iOS-4.3 directory into your project.
For iOS 4.2 copy the header files and library from the
build-for-iOS-4.2 directory into your project.
If you need to build this for an earlier version of iOS, you can
easily modify the build.sh script to point to whatever SDKs you like.
It should build fine on 3.x.
TO GET IT FULLY LINKING you must also include libz.dylib in your list
of linked libraries. To do this in XCode 4, click on your project,
choose the Build Phases tab, go to Link Binary With Libraries, press
+, and choose libz.dylib from the (long) list of possible libraries to link against. This is because libarc.a links dynamically to libz.dylib
-- this is okay since, for whatever reason, AAPL saw fit to include the libz headers in the iOS SDK.
The current libarchive version is 2.8.4. The bzlib2 version is 1.0.6.
Situation: Linking against an SDK (which I'm building) that has Release, Debug, & Distribution versions of it's static library (.a file). There doesn't seem to be a way in Xcode GUI to indicate that a static library is only used for a given Configuration.
I can use "Other Linker Flags" (OTHER_LDFLAGS) in the Build pane of the target or project settings like this:
-all_load -ObjC "${SRCROOT}/MySDKFolder/${CONFIGURATION}-universal/libMYsdk.a"
which seems to work. Just wondering if anyone knows a better way. ( the -all_load and -ObjC are to get ObjC categories linked in properly).
I'm using gcc 4.2 at this point (SDK default for 4.3 sdk and 3.x.x Xcode).
So, it turns out I was letting the Xcode UI confuse me. If you add the generic search path with the ${CONFIGURATION} variables and then add one of the static library instances to the project and target it'll do the right thing and link with the right one even though if you get info on that library in the project it'll show you the specific path.
However, if you want it to actually have Xcode notice changes made to one of the static libraries, you'll need to add ALL versions of your static library to the project and target (yes, it'll look like it's linking with all three, no worries!).
To have Xcode detect the the .a file changed as the result of a build script phase you have to actually have all the source files that are used to build the .a file in the Run Script Input pane (a pain!) to not have to run your build script every time; And all three variants of the .a file in the output pane so Xcode knows what to check after your script runs to see if it needs to relink the project.