I am trying to build and use the ConnectionKit framework in my code, but compiling it is yielding close to 100 errors, and about as many 'deprecated' warnings. Does anyone still use this framework, or is it too out of date? When I load it into XCode, I have to change it's default SDK from 10.4 to 10.7, could this be the source of my problems? And if so, is there a way to get the 10.4 SDK into Xcode 4? All I want to do is incorporate webdav support into my app. Perhaps a precompiled framework would be easier to work with...
Related
When I build my simple menubar cocoa application written in Swift 4 with Xcode 9, a lot of libswift*.dylib libraries are linked/downloaded/embedded into .app bundle,into Frameworks folder as seen below:
I am only using import Cocoa and import Foundation in my project, and some #objc functions as selector to timer functions. I really don't think my very simple menubar app would need some 3D rendering Metal library functions or any SwiftOnoneSupport, so I would like them to be removed from the .app bundle. (Same libraries are also included in the helper app for launch at login feature, which makes even the helper app over 10 MB)
I would have thought Xcode would just copy whatever is neccessary by default actually. Some similar questions were asked here and here but I don't think there is a fulfilling and up-to-date answer to both.
What I have tried so far
I set ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES to NO in Build Settings. It doesn't seem to have any effect.
I set LINK_WITH_STANDARD_LIBRARIES to NO in Build Settings. It ruined everything and couldn't make it build even though I tried to add some frameworks(Cocoa, Foundation) on my own under Linked Frameworks and Libraries section.
Simply put, it's not possible to exclude the standard libraries that Swift automatically includes with an app and expect it to work. Currently any application created with Swift bundles its own version of the Swift Dynamic Library. Swift doesn’t live on the OS, rather it lives within each app bundle. What this means is that any app that is using Swift 4.1 for example bundles in the Swift 4.1 Dynamic Library (containing the 4.1 ABI), and so forth.
One of the things on the Swift project roadmap is to eventually have ABI Stability. If Swift becomes ABI Stable, Swift will live within the OS and it’s ABI will be compatible with every version of Swift.
From iOS v12.2 ABI[About] Stability for iOS is on. That is why your target will not include Swift standard library[About] because it is a part of OS
I recently had to duplicate my own frameworks to be able to link them from the native watchOS 2 extension, because the platform is different. So for every framework X I have an X-watchos counterpart.
Everything works fine in the simulator and when building directly to my devices, and it wasn't until I tried to archive that I got this linking error:
I ran lipo -i on the built watchOS framework and sure enough, its archs are arm7 and arm64 instead of armv7k.
When I looked further into the built directory I noticed this:
Both versions are symlinks to the same file, and because the have the same product name, they're being overridden. I could make them have different names, but that would make importing them really cumbersome.
Note that this is not a problem for 3rd-party frameworks because Carthage is already building them in separate directories.
EDIT 08/22/2015: I've filed a radar with a sample project: http://www.openradar.me/22392501
EDIT 08/24/2015: This has been acknowledged in Xcode 7 Beta 6 release notes as a known issue:
EDIT 09/9/2015: Xcode 7.1 Beta release notes hint that this is fixed, but I haven't confirmed it yet.
This is working for me in Xcode 7.1.
I’m using a similar configuration with my own frameworks, but I set a different name when creating it in each platform (MyFramework and MyFramework-watchOS). Don't forget to set a common product name manually (mine is MyFramework on both) in the build settings tab of each framework.
i'm trying to make work wxWidgets on OS X 10.8 with XCode 4. So far i've managed to build the library in static mode.
I'm currently trying to add the library to a basic "hello world" sample project.
For that, i follow a tutorial that explain step by step the process.
I'm stuck though on a simple error : can't find "wx/setup.h"
i've check the derivedData folder where is the .a library and there is no setup.h
I had one setup.h created when i compiled wxWidgets using the Terminal (but i had other errors this way after, so i had to switch to XCode wxWidgets generation.)
where is the generated setup.h when building wxWidgets from XCode ? and how do i tell the compiler to use it?
I've never compiled wxWidgets under OS X using Xcode so I can't help you with finding the file (however I do wonder if you tried find . -name setup.h or using Spotlight?), but I can guarantee that the library compiled from the command line is compatible with the applications built using Xcode, provided you use the same compiler and runtime library for both. So if you already have a version built from the Terminal, you really should be able to just use it.
I have a Carbon-based project that compiles on XCode 3, but fails on XCode 4.
It can't seem to find any Carbon or QT functions, even though I've included
and #include
I get lots of errors like this:
No member named 'InitCursor' in the global namespace
I tried re-adding in the Carbon.framework from the System/Library/Frameworks folder
The InitCursor function, along with pretty much everything else in QuickDraw, was removed in Lion. You will need to remove your uses of all removed APIs, and probably replace most of them with more modern replacements.
This is a non-trivial task, but it is necessary if you want to build with modern tools and target current and future versions of Mac OS X.
It's been a long time coming, too; QuickDraw has been deprecated for years.
Much of Carbon is still supported, and you should find that you are not getting errors about those APIs.
You mention Qt; I've heard that there is a Cocoa version of Qt now.
We have multiple development machines, some running Xcode 3.2.5 and others running Xcode 4.2. We have a static library that is referenced by our project. It contains Objective C categories, so we need to use the -force_load flag with the path to the library.
The problem that we are having is that on Xcode 4.2, the library is linked from a different location than the path that we specified in -force_load. This causes duplicate symbol errors since it's trying to link two copies of the same library.
The path Xcode 4.2 links from is:
/Users/USERNAME/Library/Developer/Xcode/DerivedData/PROJECTNAME-ehxeazvigqrpvogkxlkcmdzpisdw/Build/Products/CONFIGURATION-PLATFORM/
whereas the location that Xcode 3.2.5 links from is:
PROJECT_ROOT_OF_STATIC_LIBRARY/build/CONFIGURATION-PLATFORM/
Is there a way to get Xcode 4.2 to use the same locations as Xcode 3.2.5 when linking static libraries so that we can use the force_load linker option? If not, can anyone suggest an alternative solution to get Xcode 3.2.5 and 4.2 to play nicely together?
It sounds to me like you are doing things the hard way.
I've never used -force_load to load static libraries. With the libraries I use, they are all stored as frameworks in a directory on my system which is separate from the project. I then use the XCode standard add frameworks dialogs to bring them into the project and "-ObjC -all_load" to ensure they work and categories are active.
I've successfully move a few projects from XCode 3 to 4 and not had the problem you are mentioning. I suspect that if you can stop using -force_load your problems will go away.