I've been looking for a way to disable the Auto-Linking feature. I am using TwitterCore in my main app but not in the Keyboard nor in the iMessage extensions. I don't want to carry the load of linking the framework into the extensions, but auto-linking is being stubborn. The "Link Frameworks Automatically" project setting for these targets is already set to 'No' but I still receive the warning when the targets are built:
d: warning: Auto-Linking supplied '/Users/user/Documents/Projects/MyApp/TwitterCore.framework/TwitterCore', framework linker option at /Users/user/Documents/Projects/MyApp/TwitterCore.framework/TwitterCore is not a dylib
So other than the setting that should tell Xcode not to auto-link, is there another way to make it ignore this framework? Do I need to put it in a separate place other than with the rest of the frameworks and modify the framework search path for the main app for frameworks that are not used in extensions?
TIA,
Mike
p.s. I already looked at many of the replies to other auto-link related issues but they all address the problem from the standpoint of getting the libs to link. In my case I don't want them to link.
Update added in the name of the setting for auto-link and the p.s.
Related
I am attempting to write a kernel extension (kext) that uses some parts of the Kernel framework.
I added Kernel.framework to the list of Frameworks and Libraries in the target settings.
However, when I try to build my kext and link against it, Xcode refuses to do this and claims to not be able to find the framework, even though it had shown up in the list of available frameworks.
Am I doing this wrong? Is it not possible to use this framework even for kexts?
Edit: I am aware of the user space alternatives to kexts but these don't fulfill my needs.
The Kernel.framework is a header-only "framework". Kext linking is fundamentally different from user space executable linking, as there's no dyld. You don't need to link against any libraries at build time, but you must specify the KPIs to link against in the Info.plist file's OSBundleLibraries dictionary.
You can generate a draft of this dictionary using the following command:
kextlibs -xml -c path/to/your.kext
If using any unsupported KPIs, you'll also want to specify -unsupported. If it's complaining about symbols not being found, adding the -undef-symbols option will help with debugging.
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
When I archived my application I got this error for all my custom frameworks
Warning: Installation Directory starts with '#executable_path' but
Skip Install is disabled.
I added my frameworks to my application my linking to them first and then creating a copy build false to the frameworks directory.
On each framework project I configured the Installation Directory to "#executable_path/../Frameworks" based on several tutorials I searched for on google. I believe this is to avoid installing the frameworks on the user's library (not sure).
Just to be clear, I want my frameworks to ship inside the application bundle, under the frameworks folder.
Now, I see a property named Skip Install on each of the frameworks projects build settings. Here is a description of what it means:
SKIP_INSTALL Description Activating this setting when deployment
locations are used causes the product to be built into an alternative
location instead of the install location. [SKIP_INSTALL]
When I activate this property the warning is gone, but can someone explain to me what this is? Because it implies that the #executable_path/../frameworks/ will be ignored.
In XCode 6.3.1:
Go to Build Settings, turn on 'All' not just 'Basic'
In the 'Deployment' section, set 'Skip Install' to Yes.
This will fix the warning. The thinking behind it is, if you're including the framework in your executable(s), then you don't want to install it separately
I am not sure but you have to set "Framework Search Paths" in Build Settings and remove Preprocessor Macros Debug value..
May you get help..
I know there are several other questions here regarding the Linker and Xcode 4, but they don't really relate to my problem.
I've built Allegro 5.1 and it took me a while because of FreeType, but eventually it worked. Now I've written a little Space Invader game using Allegro. But somehow the linker can't find the framework.
What I've done so far:
The Frameworks are located at /Library/Frameworks/ and they have the same structure like all the other frameworks in that place
I've added the frameworks to the "Link Binary With Libraries" tab of my target
I've added them in a "Copy Files" tab on my target with Destination "Frameworks"
I've added the correct path settings in the Build Settings, so the header files can be found
I've done all the right steps, but still I get:
ld: framework not found Allegro-5.1
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I already had a working framework, but it was installed as shared libs and not in "framwork mode". But adding the framework components to the project was kinda hard because they were stored in /usr/local/lib, which can't be selected with the file dialog...
So... I have no idea what else there should be to do. When I had the shared libs it worked, but now with the same setting but different location it doesn't anymore. Tell me if you need more information, I'll provide it!
So, in case someone lands here, with the help of elias in the Allegro IRC I've found the "error":
In my targets Build Settings I had to specify the Framework Search Paths as /Library/Frameworks.
This doesn't really make sense to me, since this is the default directory for the Frameworks on Mac OS X, but whatever...
The documentation for the project says just add the framework and the linker flags and you are good to go. Hours and hours of wasted time later, I have figured out that that's not true. If you do that, the project does not see the header files. You have to put the framework somewhere were the compiler will find the headers. In my case, that worked when I dropped the framework into /Developer/Library/Frameworks and then told it to recurse in searching that framework directory (do not fiddle around with the headers search directories).
Then the problem I get is that the link fails with the message:
ld: framework not found OCHamcrestIOS
I noticed that the documentation for the project says that it was updated for Xcode 4. I pulled down the binary of the framework after checking out the code and wasting a ton of time unable to build the IOS version of the framework.
The documentation is here.
I also noticed in that documentation that the cocoa instructions tell you to put a copy files phase into the build. I tried that. Didn't change the outcome.
The last time I fell into a sink hole it was because the library was C++ code. Maybe that's still the problem.
Barring a rapid solution here, I am going to go back to using STAsserts, as sickening as that prospect is, this is far, far worse.
Update: reinstalled Xcode. Still doesn't work. There are cheap ways to make this work, like add the header files to the project. Did a blog post about this that brought out a person with the same experience.
I use a number of frameworks in my projects. Some from other people and some are mine. Looking at the documentation I would suggest that the copy phase stuff is not for iOS development. So I would not do that. I downloaded the latest zip from https://github.com/jonreid/OCHamcrest and it appears to contain a ready to go iOS static library. (Not on my mac so I cannot test to confirm).
Anyway, the way I include static libs is to
Select the project (XCode 4).
Select the target I want to add the library to.
Select the Build phases tab.
Expand Link binary with Libraries.
Click the [+] button to add a framework.
Click the [Add Other ...] button and navigate to the directory containing the <lib>.framework directory and select that.
Thats all. The targets search paths will be updated to include the framework directory and the framework will be listed on the left under the project. Expanding it will show the headers.
The problem you mention sound like a couple of things. Firstly the framework not found sounds like the framework has not been included in the target. When you select the framework in the project list on the left, you should be able to see it's Target Membership displayed on the right. Check it's on for the target you are compiling.
Secondly building frameworks is not a trivial task so don't attempt it unless you have the scripts to do it. I say this because building a iOS static framework means compiling for both simulator and devices, combining the compiled lib files into a universal one, and then storing it and the header in a specific directory strucuture.
The downloaded zip from OCHamcrest though, appears to have the correct OCHamcrestiOS.framework in it. So if you store that directory somewhere and link to it using the steps I've outlined above it should work just fine.
So the solution I adopted for now, after much thrashing around, was to include the framework in the project.
Create a group inside the Xcode project called Third Party.
Link it to a folder called thirdparty.
Go to the Add Files in Xcode and pick the framework.
Drag it over to the dependencies.
Run the tests, they pass!
This is maybe preferable anyway because referencing it in /System/Library/Frameworks would present some versioning issues, and this can be setup very quickly. Furthermore, we have a continuous integration server, and having to get in there and sync versions whenever something changes is not so great.
Thanks for checking it out, Derek.