When adding gcov to an Xcode project, I'm getting linker errors: the symbols __gcov_init and __gcov_merge_add are not found.
This is on Mac OS X 10.5 and Xcode 3.1.4, it's a Quartz Composer Plugin project and I'm trying to add gcov to the OCUnit test cases target. The Base SDK and Deployment Target are both set to Mac OS X 10.5. The GCC version is set to 4.0.
I was able to successfully create another (very simple) Quartz Composer Plugin project with gcov and OCUnit. I may be missing something but the build settings between the two projects seemed identical in anything that could possibly affect gcov linkage. (The only differences I see are the C Language Dialect, some extra settings in the not-working project for Interface Builder Compiler, and a user-defined setting that runs Clang.)
Any suggestions would be appreciated.
Shaggy Frog had the right idea-- the -lgcov flag was not appearing in the output. My project had a unit testing target and separate configurations for with and without coverage. The Other Linker Flags setting was different in the unit testing target and the coverage configuration, with -lgcov being set in only one of those. Instead of adding in all of the flags, Xcode was overriding one set of flags with the other.
Related
After updating to Xcode 12.2, my project started failing to compile because of Apple Silicon-related linking errors. I seem to have most of them fixed, but one sub-project that builds a statically-linked framework is giving me problems. And yet a sibling sub-project with apparently identical build settings doesn't.
During linking, I get this warning about the one framework:
ld: warning: ignoring file ...Build/Products/Debug-maccatalyst/TCSiOSC.framework/TCSiOSC, building for Mac Catalyst-x86_64 but attempting to link with file built for Mac Catalyst-arm64
I'm building on an Intel Mac, to boot (so "build active architecture only" is not a factor). I can't find any build setting that would address this problem, and a Web search turns up no hits on this exact error. Any ideas appreciated!
I consulted Apple for this one, and their engineer recommended some things:
Turn any Swift sub-projects into Swift packages, not embedded Xcode projects. So, I deleted one library's Xcode project from the parent project, and dragged its top-level directory into the parent project to include it as a Swift package. Now... this particular sub-project (SQLite.swift) already had a Swift package defined. I haven't generated a Swift package myself before, so I can't help with that. Also, don’t forget to add it to the Frameworks, Libraries, and Embedded Content list on the app’s target.
Go into your project's build settings and delete the "Supported platforms" setting. If you click on the "levels" button above the build-settings list, you can see where each setting is coming from. "Supported platforms" should be non-bold. Highlight the line and press Delete if it's bold. Then go into your target and do the same thing: delete "Supported platforms."
Set the Base SDK at your project (top) level to iOS; this is a must. Delete it from the target level, so it inherits from the project; I don't know if this holds true for multiple kinds of targets or all projects, but it's working for me.
Remove the VALID_ARCHS build setting from all targets, if it's present. That setting is deprecated.
The "build active architecture" setting doesn't make any difference after these changes in my case. The project now builds and runs under Catalyst just fine.
I have the same issue and found this question. In my case, building on Debug succeeds but on Release fails. The reason is exactly the "build active architecture only" option. It is an option can be found in your PROJECT - "Build Setting" Tab then "Architectures" section. There is a setting for "Build active architecture only". By default, the Debug mode it is Yes while Release mode it is no. That caused my build to fail in release.
Why do our CocoaPods targets have different build settings than our actual project target settings? Shouldn't it just have project target settings? How does it work when our project is being compiled; does the compiler look at the CocoaPods settings or just our project target settings? If so, then what is the purpose of CocoaPods having its own build settings?
CocoaPods generally are built as a framework in iOS, and frameworks can have different settings than the main application, and are built as a separate bundle. Every compile-unit (more or less "source file") can also have its own settings (at least in ObjC; I've never tried that in Swift).
There are lots of reasons to have different compile settings for different parts of the program, and specifically for third-party code. For example, you might want to compile third-party code with a higher optimization level and debug stripping if you don't plan to debug that portion. I personally turn off all warnings in third-party code.
It's not as common anymore, but during the ARC transition it was very common to compile some of the program with ARC and some without. As Swift evolves, you should expect it become more common for libraries to be written in source-incompatible versions of Swift that require different settings.
Today I checked out a new copy of stable project from gitHub to my home computer using Xcode 6.1. After doing so, I see that many of the frameworks and libraries, including XCTest, are missing (shown in red). I have added Framework and Header Search Paths, but they are still not found.
To make things stranger, I can build the project to a simulator or device, but when I try to run an individual test, I get clang or missing file error for the libraries/frameworks shown in red.
As it turns out, the reason for my errors was that I had not run "Build for Testing" before trying to run the individual Unit Tests. As such, the proper library dependencies had not been generated.
I'm creating a static lib on Mac OS X for one of our customers, as well as a small cmd line app to test the static lib. The cmd line project has 2 extra library search paths, which meant I was linking to the Debug version in Release mode and just about went crazy, so I tried to get rid of these two paths, but I couldn't find where they were specified. I was looking in the project info, but it turns out they were specified in the target info.
I don't understand the distinction?! Why there are 2 sets of settings, which are essentially the same?! Can someone please enlighten me?
A project can contain multiple targets. For example, an app I write has four - the app itself, a Quick Look plugin, a framework and a bundle that contains Mac OS 10.6-specific functionality that can be dynamically loaded in.
Project settings apply to every single target in the project. Each target can then override individual settings if they need to - for instance, my project's Target SDK is set to 10.5, but the 10.6-specific bundle has it's Target SDK set to 10.6.
In some instances, some settings don't make sense to be in Project Settings - one of these, I guess, is search paths.
You often have multiple targets in a single project - for instance, you might have a framework project with a target for building as a dynamic .framework bundle, and a target for building a static lib. Or your app might have a target for building the app itself, and a target for building some helper command-line tool that it needs to install.
Wherever possible, I'd suggest changing settings at the highest level (in the project settings, and simultaneously changing debug & release configurations), and only customizing the target settings when necessary. Even better, move as many settings as possible into xcconfig files, which seem a much more explicit way of specifying your build setup.
Preface: you ship targets. Your end products are targets. Not projects. Think of a project as the umbrella above multiple targets.
For a more realistic example assume both Uber and Lyft were being developed by the your (umbrella) company.
The company has the following three environments:
Debug
QA
Release
The Debug and Release configs come out of the box with every new project you create. You can create as many additional configs as you want
This would require 3 configurations. To add a QA configuration follow the tutorial here
Did I apply this to the target or project?
I applied it to the project.
Ok so configs are only for projects and not for targets. Right?
Incorrect! It's confusing I know. You have to think of the project as a big container where you create your configs in there.
Then for each target (not project), for following tabs:
General, Resource Tags, Build rules, Info:
There is no difference between different configs
Signing and Capabilities tab:
You can switch between teams and sign it with a different team. This is useful if you want to sign your beta builds with your enterprise certificate but sign your Appstore build with app store certificate.
Build Settings tab:
For almost every variable in this section you can give a different value based on the config. Common Build Settings to customize are:
Architectures - 'Build Active Architecture only'
Build Options 'Debug Information Format'
Packaging
Set the plist you want per configuration.
Change the bundle identifier (Packaging >> Product Bundle Identifier). If you switch values for a field then in the plist you'll see as:
Signing
Code Signing identity
Code Signing Style (Manual or Automatic)
Development team
Provisioning Profile
Apple Clang - Optimization Level
If the values are different then the row's value would be
<Multiple values>
and you basically have to expand that value to see what value is given for debug and what value is given for Release or QA config.
If all the values are the same then you'll just see the value that is given to all of them. By default the values are the same.
Build Phases:
There's no out GUI way of switching based on configuration. However you can still do run certain commands based on the configuration. Example:
if [ "${CONFIGURATION}" = "Debug" ]; then
"${PODS_ROOT}/SwiftLint/swiftlint" autocorrect
"${PODS_ROOT}/SwiftLint/swiftlint"
fi
Summary
Long story short, this allows you to have 2 different apps (targets) with the same code (project), in 3 different environments (dev, QA, release). You create the different environments using configurations.
To learn more on this I highly recommend you to read more about this in depth and understand what configuration files (xcconfig) is. It's much more simpler than you think. It's mainly a key value pair:
AppCoda - Using Xcode Configuration (.xcconfig) to Manage Different Build Settings
NSHipster - Xcode Build Configuration Files
I have an Xcode project (A) referencing another project (B). By default (as far as I understand it) Xcode will implicitly build the configuration for the B dependency that matches the configuration of the A's target (e.g., "Debug"). But what if I want, say, A to build as "Debug" and the B to build as "Release"? How would I go about specifying that in Xcode?
I don't know of any easy approach, but you can brute-force it by calling xcodebuild directly for the dependency with a "Run Script" build phase.
I know it was just an example, but if your real goal is that the sub-project be a Release (no symbols) build, then you may have a better experience by just building the sub-project into a library or framework and checking the resulting binary into your version control system. Whenever I have a piece of the system that seldom changes and that I don't want debug symbols for, I go ahead and build it as a static library and check it in. I often go ahead and move the code elsewhere as well (with a README file with the .a that says where the code is and how it was built). This saves time on both build and checkout and is invaluable for large projects in my experience.
This might help: if the configuration of the project A is not found, Xcode will build Release config as a fallback (or maybe the first config of the list).
Then you can "force" the link using this tip: Xcode custom build configuration causes "library/file not found" for static libraries
Yes, this is not naturally supported by Xcode; when you build a target, it builds one configuration of itself and of all dependent targets.
The workaround, as Rob mentioned, is to have a dependent target that's an Aggregate Target type that comprises a single Run Script build phase, which simply invokes xcodebuild -configuration Release (or whatever).
You can specify the default 'fallback' configuration in the project info.
Change from:
Use 'Release' for command-line builds.
to:
Use 'Debug' for command-line builds.
And default will be 'Debug'.
Diffs of project file: