How can I wrap a static library (C++) into an XCFramework for use in Swift? - c++

I have been given a static library libExample.a together with a bunch of C++ headers, which I need to use in an iOS app. The binary is fat, containing objects for iphoneos-arm64/e and iphonesimulator-x64.
I have done some research on the subject and came to the conclusion, that using a XCFramework would be the best thing to do. Still, I feel completely out of my depth, since this is my first time trying anything of the sort.
What I have done so far
1. Creating the XCFramework from library files
lipo -extract architectures from fat binary
xcodebuild -create-xcframework -library LIB-arm64.a -headers HEADERS -library ...
Importing the XCFramework into my Swift project didn't yield any usable modules. Also the folder was missing a lot of the files, I've seen in examples. It seemed like the wrong way to go about it, so I tried...
2. Creating a Framework and then a XCFramework from it
Files
Create new Objective-C Framework project ExampleFramework
Pull all my headers and the fat binary into the project
Add all my headers to the ExampleFramework.h umbrella header
Create the following ExampleFramework.modulemap:
framework module ExampleFramework {
umbrella header "ExampleFramework.h”
link "Example"
export *
module * { export * }
}
Settings
General:
1.1. Add libExample.a to Frameworks & Libraries
Build Phases:
2.1. Make all headers public
2.2. Add libExample.a to Link Binary with Libraries
2.3. Add libExample.a to Copy Bundle Resources
Build Settings:
3.1. Skip Install : No
3.2. Build Libraries for distribution : Yes
3.3. Module map file: ExampleFramework/ExampleFramework.modulemap
3.4. Defines modules: Yes
3.5. Compile Sources As: Objective-C++
I then archived the framework, for iphoneos and iphonesimulator respectively:
xcodebuild archive \
-scheme "ExampleFramework" ONLY_ACTIVE_ARCH=NO \
-archivePath "path/to/ExampleFramework_${SDK}.xcarchive" \
-sdk ${SDK} \
SKIP_INSTALL=NO \
BUILD_LIBRARIES_FOR_DISTRIBUTION=YES
...and generated a XCFramework from the outputs:
xcodebuild -create-xcframework \
-framework "path/to/ExampleFramework_iphoneos.xcarchive/Products/Library/Frameworks/ExampleFramework.framework"
-framework ...
-output "path/to/ExampleFramework.xcframework"
Build Errors
The folder structure I got from this looked promising, so I tried adding the XCFramework to my iOS project. The module was being found now, but XCode stopped compiling at the first #include, saying it wasn't able to find stdexcept, from which I concluded it was missing the C++ standard library headers.
I tried setting Header Search Paths in Build Settings. Looking for the right path I found a couple, that looked relevant to me:
/Applications/Xcode_13.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1
/Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/include
/Applications/Xcode_13.2.1.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/include
Depending on which one I choose and whether I clean before building, I'm getting a bunch of different errors (it seems random). Mainly:
Unknown type name 'namespace'
and lots and lots of others, that lead to me believe XCode doesn't recognize the headers as C++.
Or:
Cyclic dependency on module 'Darwin' : Darwin -> std -> Darwin
I really have no idea at this point, so any solutions or suggestions pointing me into the right direction, would me much appreciated. I'd also be open to some completely different approach, I just want to use the library somehow.
Thanks!

For reference from module.modulemap
framework module GoogleAppMeasurement {
umbrella header "GoogleAppMeasurement-umbrella.h"
export *
module * { export * }
link framework "Security"
link framework "SystemConfiguration"
link "c++"
link "sqlite3"
link "z"
}

Related

Build protoc for C++ with CMake

I'm currently working on a C++ project that reference gRPC as a git submodule and I'm using CMake to compile the dependencies and my sources. For that I basically have this in my CMakeLists.txt:
ADD_SUBDIRECTORY(lib/grpc)
Then I run:
make grpc_cpp_plugin
make my_project
Even though I specify cpp_plugin here, when it's time to compile protoc I'm actually compiling for all the languages supported, eg (Java, Csharp, ...) :
/src/google/protobuf/compiler/csharp/csharp_source_generator_base.cc.o
/src/google/protobuf/compiler/csharp/csharp_wrapper_field.cc.o
/src/google/protobuf/compiler/java/java_context.cc.o
/src/google/protobuf/compiler/java/java_doc_comment.cc.o
After looking around for some info on how to build protoc only for C++, I found that someone opened an issue on the github protobuf directory (link). However, it doesn't seem to give a clear answer.
Is there a 'clean' way to only compile the c++ dependency here ?
After doing tons of grep in gRPC's CMake files I finally compiled only the c++ version of protoc, protobuf and gRPC. And I did it in 3 steps:
go to grpc/third_party/protobuf/cmake/libprotoc.cmake and remove the lines including csharp, java, ruby, ... (Be careful to keep cpp and the langage agnostic ones)
go to grpc/CMakeLists.txt and you should be able to find this:
add_library(grpc_plugin_support
src/compiler/cpp_generator.cc
src/compiler/csharp_generator.cc
src/compiler/node_generator.cc
src/compiler/objective_c_generator.cc
src/compiler/php_generator.cc
src/compiler/python_generator.cc
src/compiler/ruby_generator.cc
)
so remove what's not needed.
and finally, grpc/third_party/protobuf/src/google/protobuf/compiler/main.cc and remove all the references to the other langage.

OCaml: using Oasis with multiple-level src folders

I am trying to use oasis to compile my project, and my project is organized in this way:
_oasis
src/
main.ml
core_a.ml
core_b.ml
type.ml
plugins/
plugin_a.ml
plugin_b.ml
Note that in the plugin_a.ml, it refers to module type.ml (i.e., open Type).
When I use oasis to compile the project, it reports:
Unbound module Type
Here is the simplified version of my _oasis file:
....
BuildTools: ocamlbuild
BuildDepends: deriving, deriving.syntax, core, batteries
Executable "main"
Path: src
MainIs: main.ml
CompiledObject: best
Install: false
BuildDepends: deriving, deriving.syntax, core, batteries
Am I doing anything wrong here? Or what I am doing is not the best practice to organize a project like this?
I think your project structure is a bit strange. You have a sub directory for plugins, but you should note that there's no namespace or package hierarchy so this is not really useful in practice.
As for whether this is possible, the answer seems to be mixed:
It's not possible to do it with just oasis because it doesn't let you specify multiple values for the Path option.
It should be easily done with ocamlbuild however by tagging everything you need with include (but I don't recommend this).
As your oasis project grows, you should look into defining library sections in oasis and using those to organize inter project dependencies. E.g., in this case you could create a "plugins" library where you include plugin_a and plugin_b. But without some planning ahead here, you will quickly run into circular dependencies.

How to add depdency in waf builder's wscript script

In my project (which uses waf/wscript based build system), I am now adding mongodb c++ driver APIs. I figured out that 'libmongoclient.a' is not getting added as a linker option (at compile time) and I get all undefined reference to the mongodb c++ driver API calls.
I want to understand, how do I modify my wscript so that it picks up the mongoclient related library by itself and links it properly. It perhaps involves updating the configuration function of wscript. I am new to the waf build system, and not sure how to change it.
I have built and installed the mongodb c++ driver as follows:
- INCLUDE: /usr/local/include/mongo/
- LIB: /usr/local/lib/libmongoclient.a
I posted a similar question earlier in this regard, and the above one is more specific problem statement.
https://stackoverflow.com/questions/30020574/building-project-with-waf-script-and-eclipse
Since I am just invoking ./waf from within eclipse, I believe, the options that I specify into Eclipse's build environment are not being picked up by the waf (and hence the library option for mongoclient).
I figured this out and the steps are as follows:
Added following check in the configure command/function.
conf.check_cfg(package='libmongoclient', args=['--cflags', '--libs'],
uselib_store='MONGOCLIENT', mandatory=True)
After this step, we need to add a package configuration file (.pc) into /usr/local/lib/pkgconfig path. This is the file where we specify the paths to lib and headers. Pasting the content of this file below.
prefix=/usr/local
libdir=/usr/local/lib
includedir=/usr/local/include/mongo
Name: libmongoclient
Description: Mongodb C++ driver
Version: 0.2
Libs: -L${libdir} -lmongoclient
Cflags: -I${includedir}
Added the above library into the build function to the sepcific program which depends on the above dependency (i.e. MongoClient).
mobility = bld(
target='bin/mobility',
features='cxx cxxprogram',
source='src/main.cpp',
use='mob-objects MONGOCLIENT',
)

boost 1.53 python fatal error LNK1104 boost_python-vc110-mt-gd-1_53.lib

I'm trying (for a few days now) to build a DLL generated from C++ code with boost/python to be used by python. I am a Student from Germany and had mostly to do with Java until now (I wrote some basic OpenGL and gimp filter stuff before in C++). So pardon me in advance for bad english or C++ beginner mistakes. I mean, programming with Java really is a lot more comfortable in comparison to C++. But enough of the skirmish.
The error:
LINK : fatal error LNK1104: File "boost_python-vc110-mt-gd-1_53.lib" could not be openend
My presets:
-using MS Visual Studio 2012 (11.0)
-using boost_1_53_0
-using python2.7 (I heard 3.3 may cause some Problems)
What I did:
Installed python and added it to PATH. Then created a new empty project in VS and a class file "Test.cpp" with following content as described on the boost tutorial page:
char const* greet()
{
return "hello world";
}
#include <boost/python.hpp>
BOOST_PYTHON_MODULE(Test)
{
using namespace boost::python
def("greet", greet);
}
Then came the new part for me, in VS Project Properties:
Configuration Properties > General > Configurationtype > Dynamic Library (.dll)
C/C++ > General > Addition Includedirectories > C:[..]\boost_1_53_0
Linker > General > Additional Library Directories > C:[..]boost_1_53_0\stage\lib
From the error I am assuming i did something wrong with Linker or Include. I also changed the Linker > General > Additional Library Directories to boost_1_53_0\libs because i wasn't sure, but the same error occured. And yes, I correctly included python. I am also not sure if i have to put something else beside python into Linker > Input for boost.
Then I build boost with bjam with no options except msvc-11.0 to be sure to have everything i need (though I read that boost/python doesn't need an extra build) and still got the same error. Can someone help me? I would love to have a step by step description of what to do. I am really despairing of this.
Btw.: I had the same error as this guy a few days before Linker error LNK1104 with 'libboost_filesystem-vc100-mt-s-1_49.lib' then stopped working on it and as I started again I got my brand new error (I can't tell you how this happened).
Since it is looking for a static library, add BOOST_PYTHON_STATIC_LIB flag, go to VS properties -> Preprocessor -> Processor definition, add BOOST_PYTHON_STATIC_LIB flag.
You need to create a "user-config.jam" file that indicates where the python headers and libs can be found by Boost.Build. You can create it in your boost_1_53_0/ directory with the following contents:
# Configure specific Python version.
using python : 2.7
: C:/Python27/python.exe
: C:/Python27/include #directory that contains pyconfig.h
: C:/Python27/libs #directory that contains python27.lib
: <toolset>msvc ;
Then from that boost_1_53_0/ directory you need to invoke b2 like this in order to build the missing library:
b2 toolset=msvc-11.0 --with-python variant=debug runtime-debugging=on link=shared --user-config=user-config.jam stage
(although I would recommend b2 toolset=msvc-11.0 --with-python --user-config=user-config.jam --build-type=complete stage so you can get in one step all the configurations that you might need in the future)
Once you have the libraries you need to add the directories to Visual Studio ( both to boost and to python).
Once you have successfully built the module you need to rename it to Test.pyd (exact name you used in BOOST_PYTHON_MODULE. If you have the python and Boost.Python libraries in your PATH or in your current directory you will be able to use the script in the tutorial:
import Test
print Test.greet()
and get the familiar "hello world".
Note that I'm very thankful for your tries but none of your answers helped. A fellow student then gave the hint for the right answer to me and some steps are really easy, others I don't understand, but it works now.
First Problem was: The new boost 1.53.0 does not work with Python27 or older. I then linked it with Python33 and had the build error removed.
But of course the build version didn't work without an error. As I tried to start my helloboost.py which imports from the .pyd built by VisualStudio and invokes the greet method, the following error occured:
ImportError: DLL load failed: The specified module could not be found.
As i checked the hello_ext.pyd with the dependency walker and wildly copy pasted around, I found out it needs the boost_python-vc110-mt-gd-1_53.dll (probably depending on what you need and built with bjam before) in the same folder. It worked then. Maybe someone can explain why nowhere was explained that I need this dll in the same folder as the pyd (or did I miss something? Is it just because I made a mistake before?)
Anyhow, I'm very glad it works now and hope it helps other people.
You probably will have worked this out by now - however:
When a .exe looks for a .dll to load no path is specified. Therefore a .dll must be in the search path for the file.
Also: I was trying to build 1.49 libs for Visual Studio 2013 - and kept getting the LNK error from my project. I don't know who suggested it on stackoverflow but someone\something gave me the idea to copy build system from a more recent boost which knows how to make .libs for more recent environments. (thank you)
I had to copy the boost build system from a 1.58 after running bootstrap in 1.58, copy b2, bjam and boost-build.jam to the earlier boost folder root to replace the same named files there. Also you will need to copy the later tools\build folder to support the build system.
Noting here in the hope it might help someone else in a similar cituation I found myself in.
See: Search Path Used by Windows to Locate a DLL

Autotools: Including a prebuilt 3rd party library

I'm currently working to upgrade a set of c++ binaries that each use their own set of Makefiles to something more modern based off of Autotools. However I can't figure out how to include a third party library (eg. the Oracle Instant Client) into the build/packaging process.
Is this something really simple that I've missed?
Edit to add more detail
My current build environment looks like the following:
/src
/lib
/libfoo
... source and header files
Makefile
/oci #Oracle Instant Client
... header and shared libraries
Makefile
/bin
/bar
... source and header files
Makefile
Makefile
/build
/bin
/lib
build.sh
Today the top level build.sh does the following steps:
Runs each lib's Makefile and copies the output to /build/lib
Runs each binary's Makefile and copied the output to /build/bin
Each Makefile has a set of hardcoded paths to the various sibling directories. Needless to say this has become a nightmare to maintain. I have started testing out autotools but where I am stuck is figuring out the equivalent to copying /src/lib/oci/*.so to /build/lib for compile time linking and bundling into a distribution.
I figured out how to make this happen.
First I switched to a non recursive make.
Next I made the following changes to configure.am as per this page http://www.openismus.com/documents/linux/using_libraries/using_libraries
AC_ARG_WITH([oci-include-path],
[AS_HELP_STRING([--with-oci-include-path],
[location of the oci headers, defaults to lib/oci])],
[OCI_CFLAGS="-$withval"],
[OCI_CFLAGS="-Ilib/oci"])
AC_SUBST([OCI_CFLAGS])
AC_ARG_WITH([oci-lib-path],
[AS_HELP_STRING([--with-oci-lib-path],
[location of the oci libraries, defaults to lib/oci])],
[OCI_LIBS="-L$withval -lclntsh -lnnz11"],
[OCI_LIBS='-L./lib/oci -lclntsh -lnnz11'])
AC_SUBST([OCI_LIBS])
In the Makefile.am you then use the following lines (assuming a binary named foo)
foo_CPPFLAGS = $(OCI_CFLAGS)
foo_LDADD = libnavycommon.la $(OCI_LIBS)
ocidir = $(libdir)
oci_DATA = lib/oci/libclntsh.so.11.1 \
lib/oci/libnnz11.so \
lib/oci/libocci.so.11.1 \
lib/oci/libociicus.so \
lib/oci/libocijdbc11.so
The autotools are not a package management system, and attempting to put that type of functionality in is a bad idea. Rather than incorporating the third party library into your distribution, you should simply have the configure script check for its existence and abort if the required library is not available. The onus is on the user to satisfy the dependency. You can then release a binary package that will allow the user to use the package management system to simplify dependency resolution.