I'm trying to compile a dependent libraries from the source code and I've got this error:
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS9.0.sdk/usr/include/unistd.h:446:8:
note: 'fork' has been explicitly marked unavailable here pid_t
fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
Is there any way to resolve this issue?
The thing is that I don't actually even need this functionality. When I compile this code for iOS and run it under tvOS then it works.
But I can not submit the application because it contains code compiled for iOS.
What would be the good trick to substitute there a dummy fork() function so it compiles OK (believing that it is not actually used by my specific use-cases).
I don't believe there is a way round this. You cannot create processes under iOS and tvOS is 90% iOS, so the same restriction applies.
You'll have to conditionally compile-out that section of code for iOS/tvOS.
Related
After iPhone app that I'm writing in Swift become quite big (> 150 .swift files + various Objective-C libs), Xcode start behave pretty badly:
every second compilation I get various errors, e.g.:
Command failed due to signal: Segmentation fault: 11
compilation take enormous amount of time (> 2 min on MacBook Pro Retina)
and so on.
I just wonder if everyone has same problems and maybe someone found a way to reduce this nightmare?
What I have done so far — I split project into several dynamic frameworks that I link from main project, it helps to reduce compile time, but introduce some new problems.
I also use iRamDisk to keep DerivedData folder in RAM and periodically delete all files from it, it sometimes helps with SourceKit crashes.
Swift toolchain is still a bit gross, you'll need to use some temporary workarounds until Apple fixes it (see UPDATES below)
Here is a list of items that you can do to keep yourself from going crazy.
Slowness caused by immature Swift compiler
Change your development workflow using Injection for Xcode. Once you installed the plugin, you'll be able to inject code changes in your simulator\device without recompiling. You don't need to hardcode\modify anything in your project. We started using it recently at work and it made a huge impact on our side, even if it doesn't apply to every use case (for example you can't create new functions, you can only modify the existing ones).
Some particular code constructs that the compiler doesn't like and takes too much time to compile. The most common problem is with the Type Checker that slows down compile time exponentially based on how many type checks it needs to do (read more here for practical examples and here for a detailed explanation). In order to identify if you are suffering from this problem you can follow this blog post, you will gather information about the functions that creates slowness by using some compiler additional flags. Alternatively you can use this Xcode plugin to identify the source of the build slowness.
Use dynamic frameworks wisely, where it makes sense. A framework recompilation will be done only when you modify one of its Swift files (dynamic frameworks are only available for iOS >= 7).
Condense code in the same files. Lowering the number of Swift files speeds up the compile process sensibly. You can easily achieve it enabling "Whole module optimization" by adding a user-defined custom flag SWIFT_WHOLE_MODULE_OPTIMIZATION and set it to YES and at the same time set optimization level to none (to disable optimizations that would make it slow) OUTDATED You may consider to use this gist, it's a build script that collapses all your code in a "merge.swift" file.
You'll need to create a new target for it, but it is worth a
try.
Double check things listed here (there are a few some more misc reasons because the compilation is slow)
OUTDATED Try the approach described in this blog post, it involves creating a build script that generates a make file. It requires manual intervention on the build script (it contains the list of swift files).
OUTDATED Try this hacked up incremental compilation technique
UPDATE: Incremental builds introduced on Swift 1.2 (Xcode 6.3)
Apple finally introduced incremental builds with Swift 1.2 (shipped with Xcode 6.3). It's not still perfect, but it's a huge improvement.
From now on a class is recompiled only when it is changed (or when one of the class it depends on has been changed).
However the compiler still can’t understand if the changes to a class are to its interface or not. So any kind of change to a class causes a recompilation of that class and all of its dependencies.
UPDATE: Recompile dependent classes only when public interface changes introduced on Swift 2.1 (Xcode 7.1)
Starting from Swift 2.1 (Xcode 7.1), the dependent classes are recompiled only when you change the public interface of a class, and not at every change. This makes an huge difference in particular for big projects.
Project (mis)configuration (not related to Swift)
Be sure that "Build Active Architecture Only" is YES for debug.
Be sure that you didn't add pre\post compilation scripts that take too much time.
Apple has some advices for speeding up your Xcode build in Technical Note 2190. Have you thought about creating and precompiling an own framework for outsourcing unchanged Swift modules or some/all Objective-C code?
Remove all type inferences in Swift.
This SO topic has some nice ideas and this blog post suggest to
stop generating dSYM bundles and
avoid compiling with -O4 if using Clang.
Although lots of these improvements are related to Objective-C, I am quite sure, that some of them are still relevant for Swift.
The (re)compiling is a known issue that I am sure will be resolved soon. Some recommendations:
Use Objective C where possible - it compiles fast even if it is a part of a Swift project
Split code to frameworks
Specify types instead of leaving it up to the compiler to infer them
Again, there is a good chance that this will be fixed soon, so perhaps it is best not to make big investments in rewriting or reorganizing the code at this point in time.
you could try:
upgrading the amount of RAM in your computer
if you have multiple .swift files that do things on the same view controller, try condensing them into one .swift file per view controller
tweaking the settings under compile sources to see if you have any duplicates or if there are any scripts or settings you can add to make it compile faster...
you can also take a look at this post's answers for some hints as to what you can do to slow down compile time
I've discovered that one of the main causes of segmentation faults and slow compilation is hardcoding big arrays and dictionaries, especially when declaring them as global constants and trying to access values from them from within another .swift file. When I store all that data inside plists, these problems are gone.
In my experience avoid creating the large swift files, when I started a project in my new company, there was a 'UIViewController' with more than 2000 lines, little changes on this file taking much time to build, I made 4 extensions with <500 lines from that class, my speed improvement was incredible.
I have just finished porting a decent amount of c-sources to the iOS platform and packaged them as a universal static framework. I, then, added the framework (not the project) to a sample iOS app in order to test linkage and proper function. That's when I ran into a humbling problem.
In my attempt to solve the problem described here, I also came across some symbols that are composed through the heavy use of macros (i HATE those). Some of those macros use function attributes that are really extensions of gcc rather than of standard C.
Of course I can always add -std=gnu89, but even then, I am not sure it will resolve the original problem of undefined symbols in the static library.
Not only that, I am now worried that my port to iOS of those sources may not be an accurate port and may result in the type of bugs/issues that maybe related to compiler's codeine and/or optimization policies.
If you can share some of your experience/advice in how best to go about that port, I would really appreciate it.
Thanks!
From manual testing with clang 8.0, it seems that both __attribute__((constructor)) and __attribute__((__constructor__)) work for your purpose.
My iOS project uses dlsym to dynamically point to an optional C library. Optional as-in the project can run with our without it, it just adds features.
For background info: Detect and use optional external C library at runtime in Objective-C
The problem is, XCode cleans up libraries that are "not used". Using dlsym means there are no direct references to my 3rd party library and XCode removes it.
I thought I found a solution, in "Other Linker Flags" I added
-force_load "$(SRCROOT)/my_external.a" which worked great in the simulator. (-all_load works fine too but seemed overkill to me).
The problem is when I moved to a real device, this workaround failed and the library is not loaded (same thing with -all_load).
The only thing that worked was to disable in XCode the feature called Dead Code Stripping.
Question is: is it really bad to disable or recommend my customers to disable this feature? If so, is there a better alternative?
I am using an fmod plugin for Unity3D. Compiling to Windows and OSX is fine because I can dynamically load the DLL/dylib.
The problem comes when I compile for iOS. I use
[DllImport("__Internal")]
Because iOS requires statically linked libraries. When I compile though I get a
SystemException: Duplicate native method found : FMOD_System_CreateSound. Please check your source carefully.
I am quite sure I don't duplicate the symbol. I think this might be due to the fact that Unity imports FMODs itself and that the two might be colliding... But if this is the case, I am surprised that FMOD_System_CreateSound is the first one to get caught. Is there a way around this? thx!
As always, I will be happy to provide any additional details!
Here is a sample project that will cause the error:
Sample Unity Project with FMod
EDIT:
The conflict was caused by iOS not allowing functions to have the same name even though they don't have the same signature. After removing the same-named functions (thus removing some FMOD features that I didn't need), I can compile to iOS, but as expected, I still get an error when Initializing because FMOD is already initialized by Unity.
Unity3d already has a limited version of FMOD that is bundled with it, which is causing the conflict you are seeing. Unfortunately, it doesn't seem possible to disable it at this time, so that you can use the full version of FMOD
In reference to your edit and after looking at the sample, it is true that you cannot have two methods of the same name as the compiler will not recognize which to link to.
The easy fix is to obviously name them differently.
As for the initialization, if you can access the FMOD that Unity 3D already created, then you don't have to reinitialize it.
I assume that a pointer to that object will be sufficient to remove the duplicate initialization. Hope this is clear.
I have a code base which compiles fine in all other NEON compilers, ndk-build, RVDS, etc, but under Xcode I get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsics method calls.
It seems like the compiler is barfing on the whole file...
Unknown pseudo-op: .cpu
It lists all of the other settings, like .fpu, etc
Here are my current settings:
(source: wasteonline.net)
(source: wasteonline.net)
(source: wasteonline.net)
After the as tool I mentioned in my last answer turned out to be choking on my syntax as well, I realized there must be something else going on.
I followed the guidelines on the bottom of this post http://www.shervinemami.info/armAssembly.html#template
The changes I needed to make were:
converted my instructions to all lower case
use the naming directives to be compatible with mach-o (solved linker problems)
Try to use GCC4.2. I solved a very similar problem switching to the old, good GCC.
In Build Settings -> Compiler for C/C++/Objective-C, select GCC
Actually, if you check the LLVM ARM status page, you'll see that it cannot yet parse .S files.