I saw them in libc-8XX/pthreads on opensource.apple.com, but since libc-9xx the pthreads folder are gone, so did these two functions. I saw these two functions were used in _Unwind_SjLj_Register in exception handling on 32-bit IOS platform, but where are they now? or am I just misunderstanding something about them?
Related
I support a suite of related iOS apps, some of which make use of extensions (WatchKit and Today Widget). All of these apps and extensions make use of a shared private framework I've built up over time for handling certain workflows around authentication and common business logic. This framework is maintained as a private pod.
Recently, I've run into a problem where I'd like to add a method to the framework that's only really useful for the iOS apps (extensions don't need it) that uses certain APIs that are unavailable to extensions (such as [UIApplication sharedApplicaion]). I'd like to get the usual benefit of shared code, where this is implemented in only one place (the shared framework) for all my various apps to leverage. However, I can't find a way to conditionally include that method for just the apps and not the extensions without getting a compile-time error.
Normal recommendations around this problem usually suggest the use of a preprocessor macro to opt-out around the problematic code if desired, but that doesn't really work for a shared framework situation. Macros are applied at compile-time, so the shared framework is either going to include that method, or not, and there doesn't seem to be a runtime solution to optionally exclude it. If it's included, the extensions can't compile. If it's not included, my apps can't make use of the feature.
I also started investigating if there was some way that Cocoapods could automatically make two versions of the framework, one to be used by the apps, and one by the extensions, but this would seem to introduce problems around duplicate symbols, and generally doesn't seem supported.
Are there any other suggestions for how to handle this, apart from just extracting out the problematic functionality into a different framework? (I really would prefer to just share one)
I recently tried to use Armadillo on iOS to do some matrix computing. The App worked on my development iPhone, but Apple gave me the error message when trying to publish it in the Appstore. It seems that Armadillo calls some BLAS functions which are internal. I searched the web with the message, but had not found anything useful. I also found calling BLAS functions with "cblas_" prefix, e.g. cblas_dgemv, directly from my code would not cause the error. However, that made the use of armadillo meaningless.
I wonder if anyone has encountered the same problem, and what the solution is. I’m suspecting it’s something related to some macro in config.hpp. Thank you very much for your kindly help.
Error message:
Non-public API usage:
• The app references non-public symbols in ***: _sgemm_, _sgemv_, _ssyrk_
The Accelerate BLAS implementation supports a bunch of redundant symbols to facilitate divergent function naming schemes of various fortran compilers. Strictly speaking these are intended to be used (by your fortran compiler) so you probably have some arguing ground that they are not private interfaces. If the AppStore is still giving you trouble, file a bug against Apple and ask them to fix the bookkeeping on the interfaces so they can be used.
It would be simpler to just start using the cblas_ interfaces in the headers though.
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.
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 am trying to port some c++ code to my android application using NDK.
But the c++ code involves calls to some pthread_rwlock functions which is absent in the libc provided with the NDK.
I have found implementations of these functions but including them, it asks for more header files and more implementations and the problem grows.
Does somebody have a solution to this.
Thanks!
I stumbled over the same issue with NDK r5b where rwlock was in the header but not in the lib.
In the latest r5c this seems resolved.
Android's pthread implementation lacks read/write locks. You'll need to use standard locks instead. A work around may be to write some wrappers that simply use the standard locks. Another approach may be to use Android's atomic APIs to roll your own.
Relevant items in the AOSP bug database:
pthread_rwlock functions are missing
pthread_rwlock static init constant is broken