I'm trying to load a custom .dylib library via the dlopen() function (in a Swift iOS app). It requires a path to the library.
Where to put the library in the project structure?
What will be the library's path on the iOS device?
Also, a tangential question, it seems more usual to include the library's sources directly into the project and let Xcode build it. Is that a preferable approach for some reason?
1 )
If you include the .dylib library in with your list of files and resources in your project, you can use the "Copy Files" build phase to copy the dylib into your shipping app.
A tutorial can be seen here.
2 )
For dlopen, try using just the .dylib name before you try to use relative paths including the "#executable_path" or "#rpath" run time variables. An example can be seen here in this related question.
As for why some developers prefer to include the library source code in a project, I believe it's mostly just a preference by folks who aren't comfortable with the "Copy Files" build phase or in using dlopen.
Related
I must have read over a dozen posts on possible techniques to link a local library into my Swift Package. Specifically, my package depends on libturbojpeg.a, which most users won't have installed anywhere. Even if they did install it (there is a DMG), I'd have to go through hoops to make sure I was linking in the correct version. I finally found a post in the Swift Forums that basically says you can't do it now.
It appears that the only way to link it now is using .linkerSettings(LinkerSetting.unsafeFlags(..., but if you use that your package can't be managed by Xcode (see above link, and I even tried it and verified it cannot be used).
Is there some kind of workaround that allows me to distribute my Swift Package with the library?
In my Package, I created a directory "Libraries" and added my library there.
I discovered that Xcode 11 places included Swift Packages in a specific location in the Derived Folders directory. This means that it is possible to tell Xcode where to find it during the link phase.
My Package has these instructions in it for users:
1) Add the Package using Xcode->File->Packages with the URL of https://github.com/dhoerl/
2) Open the app's Project Build Phases, and from the Package shown in the left file pane, drag the Libraries/.a file into the link phase. It will appear just above the that should already be there
3) In Application Build settings, under library search paths, add:
"$(BUILD_DIR)/../../SourcePackages/checkouts//Libraries"
Build and run! Voíla - works like a charm!
Note: obviously this is somewhat fragile, Xcode 12 could change how packages are managed, but its possible by then that the Swift Package Manager will support linking of local libraries (its mentioned in the above link.)
I have a C++ lib as a separate project that I'm trying to use in a Swift iOS app.
The approach I'm pursuing right now is:
Compile the lib into .dylib. This happens outside of Xcode.
In Xcode, add the lib to Build Phases -> Link Binary With Libraries.
Add the (C compatible) header to Bridging-Header.h.
Now, build succeeds but it crashes on simulator (something like ".dylib not found"), because the .dylib is not added to the app package.
Unfortunately I couldn't add the .dylib to "Embedded Binaries". I guess it must be somehow packaged into a framework (no idea how)?
How to make this work? Is including the sources into the project a better approach?
I am currently building a library which should be used internally in a few iOS projects but should also be distributed to customers accessing our services with the library. The Library itself consists purely of C++ code and I am basically able to create Apps with it on iOS which work fine. My problem is creating a single, easily distributable file that can be given out to customers which can easily install them, use the provided headers and don't need to have the headaches that I am currently facing when it comes to linking.
Our code depends on two other projects, namely boost and websocketpp. For boost there is the script on github which I took to generate a framework. For websocketpp, I imported it into XCode and used the scripts from this github project to build a framework. I added both frameworks to my (potential) framework as dependencies and used the same script to build one.
I have an app using my library as a sub-project working fine. Even including the framework into the project and running it on a device works fine. So far so good.
However, trying to create an archive of the App project lead to several questions and headaches.
My library did not seem to contain the code for all architectures. So I tried to archive the Framework projects, which after small modifications in the build scripts to use different locations to search for headers worked fine.
It does not seem to contain all binary code or references to local files (i.e. my specific location of boost). I gathered that from Linker errors that I still get that tell me that some boost calls could not be satisfied.
The second issue made me think that I am must be doing something fundamentally wrong and my intuition tells me that it can't be that difficult and "hackish" to create frameworks or libraries for others for iOS development.
As you probably have found out by now, I am not very experienced when it comes to iOS and I am wondering if I am missing something fundamentally. So, I am sure that this question is rather broad, so some more concrete questsions:
Is there a(nother) way to generate some kind of distributable (preferably a framework) which contains: my public headers, my binary code compiled for all platforms supported for iOS development, the binary code of dependencies?
Is the only way to do that by adding some handwritten scripts to the build process?
I have the feeling that the information I found is quite outdated since it's older than a year and mostly refers to Xcode 4.2 or 4.3 -- so has there anything changed in this regard recently?
For example one error I get is:
File is universal (2 slices) but does not contain a(n) armv7s slice: <file>
The <file> slice is the path to the file in the framework in the Products folder of a different XCode workspace (the library was build in a different workspace then the app). I dropped the framework folder into the project for this test from a completely different location.
What is going on here?
Why does it keep referencing to some internal XCode directory?
How do I properly export it?
Since I guess my setup is probably skrewed up and weird from all the different things I tried up to now: How does this setup look like in a ideal situation?
Yes, there are some questions regarding this on SO already, however, either I don't see or don't understand in those replies:
...how to handle depencies of my code to other third-party code properly.
...how to generate a distributable file.
Have you checked your project build phase under Compile Sources and Copy Files to see if you are including your framework source files in your build?
You may also try the C/C++ Library template under OSX -> Framework & Library.
Finally, there's also kstenerud’s iOS Universal Framework, which I found very useful. I wrote a few articles in my blog on using it.
I used to copy/paste my IOS plugin files inside Plugins/IOS folder on my Unity project, but it doesn't work for bundles (as it has directory structure).
I can't beleave there is no way to generate xcode project from unity with .bundle inside?
Any help appreciated
Unity3D will not contains folders in the Plugins/iOS to Xcode project. In fact Unity3D will only auto merge source file and .a library for you, as described by Unity3D's doc:
Automated plugin integration Unity iOS supports automated plugin
integration in a limited way. All files with extensions
.a,.m,.mm,.c,.cpp located in the Assets/Plugins/iOS folder will be
merged into the generated Xcode project automatically. However,
merging is done by symlinking files from Assets/Plugins/iOS to the
final destination, which might affect some workflows. The .h files are
not included in the Xcode project tree, but they appear on the
destination file system, thus allowing compilation of .m/.mm/.c/.cpp
files.
Note: subfolders are currently not supported.
But you can use the PostprocessBuildPlayer attribute to implement this yourself. I made a tool for this purpose called XUPorter, which can make exporting and libraries setting easier from Unity3D to Xcode. You may want to see it on GitHub. There is a demo in the package and you may set your bundle under the 'folders' tag.
First, please forgive and point out if I am to use some other protocol for referencing another thread/post.
There was a previous thread how to compile spatialite for iOS where the top answer partly described building spatialite as a static library for iOS. The answer included the text:
"Once you've drag n drop the .a (both are required to work in the simulator AND on the real hardware), you can initialize spatialite by just invoking spatialite_init(1)."
I am guessing this is translated to some version of the following?
Xcode 4
File->New->New Target->iOS->Framework & Library->Cocoa Touch Static Library
Name the library - libSpatialite_TedS
Drag the header files to libSpatialite_TedS -> Copy Headers (question here ... there is a spatialite.h file in the 'headers' directory of the 'spatialite2.3.1.zip' download. Then in the subdirectory 'spatialite' there is another spatialite.h that is not an identical file and is obviously needed. Do we just drag the header files from 'headers' directory, then drag the directory 'spatialite' as a directory into 'Copy Headers' area of our Xcode static library 'myNewLibrary'?)
Drag the '.a files' libSPATIALITE2.3.1_arm.a & libSPATIALITE2.3.1_x86.a
Shouldn't we have some '.m' files to go with these headers in the 'Compile Sources' field?
Now, without referencing the libSpatialite_TedS in my project, when I 'Command-B' to build, the project build succeeds. However, when I look for the compiled product in
/Users/Admin/Library/Developer/Xcode/DerivedData/MyProject-gutnkbwqqonzgxbcmfzzzkadqhid/Build/Products/Release-iphonesimulator
I see build's products, but they do not include libSpatialite_TedS.
Is this because the compiler is 'smart' and recognizes that none of the header/.a files are referenced in the project so it does not bother compiling them?
And, is this the correct way to go about achieving the objective of the original poster how to compile spatialite for iOS?
Many thanks,
Ted S
I was running into linker errors with the original poster too, but solved it by including libsqlite3.dylib, libstc++.dylib, and libiconv.dylib in the target.
Hope this helps!
Ted, I believe that the .a (static library) files and headers are meant to be used in a project right away, rather than in another static library as you've described. They are the result of a project's output. I think you can find the project that built them, here:
http://lionel.gueganton.free.fr/spatialite/
And a little more on static library files:
What is a .a (as libcrypto.a) file?
EDITED
Here's another link that you might find helpful. It s a summary of the Static Library build process in iOS:
http://www.icodeblog.com/2011/04/07/creating-static-libraries-for-ios/