How to properly wrap a C library in a Cocoa application - objective-c

I want to include the GNU Scientific Library (GSL) in my Cocoa app so that the user needs not installing it locally first. Like most GNU packages, it's the standard configure / make / make install routine. But this won't work:
./configure --prefix ~/libgsl
make
make install
Since the prefix is local to my computer. And neither is this:
./configure --prefix (path to build folder)/libgsl
make
make install
What I want is essentially the GSL being contained entirely in my application, and I can call its functions without the users downloading anything else.
I'm rather new to Xcode 4 and the build system for Clang/GCC, having coming over from .NET. Any help is much appreciated.

Assuming there is not a framework-style build of the library, the way this is typically done when bundling with 3rd party libraries is to build the package as normal, install it in /usr/local, and configure your project to include and link from there. Building is the easy part though.
The tricky part is bundling up the .app correctly. You need to add a custom build stage (after the others) which first copies all the dependent .dylib files into your app bundle's Frameworks folder (using the environment variables to help; see Xcode docs). Then you need to use install_name_tool to get the app binary to look in the framework dir (as the embedded soname still thinks it is in /usr/local). This part is very fiddly and not well documented.
I've just extracted this from a working project where I use GSL. Just add this as an extra build phase in your XCode project as a Custom Script:
# Framework folder for Example.app
FRAMEWORKS_DIR=${TARGET_BUILD_DIR}/Example.app/Contents/Frameworks
# Create path if it doesn't exsit
mkdir -p ${FRAMEWORKS_DIR}
# Find the original linked path for libgsl
GSLLIB=`otool -L ${TARGET_BUILD_DIR}/Example.app/Contents/MacOS/Example | grep libgsl | cut -d" " -f1`
GSLPATH=`dirname $GSLLIB`
# Copy the dylibs into your app
cp /usr/local/lib/lib{gsl,gslcblas}.0.dylib ${FRAMEWORKS_DIR}
# Update embedded paths
install_name_tool \
-change ${GSLPATH}/libgsl.0.dylib \
#executable_path/../Frameworks/libgsl.0.dylib \
${TARGET_BUILD_DIR}/Example.app/Contents/MacOS/Example
This should work with a simple substitution of your app name.
This is basically the same as what you need to do to build a standalone Qt app, so the docs here are very relevant:
Deploying Qt on the Mac
It is worth reading up on bundles, frameworks and packaging. For example:
Mac OS X Framework Reference
This post is also relevant:
How do I link libraries in Xcode 4?
Note that GSL is published under the GPL, so your app would need to be similarly published in order to respect the license. Shipping the source is necessary, but not sufficient for compliance.

Related

Install jpeg 2000 on Windows 10

I want to investigate a new application for JPEG 2000 encoding and decoding. I downloaded openjpeg-master and managed to cobble together the ability to cmake the files. After a bunch of grinding, this resulted in the following output:
"Build files have been written to: C: openjpeg-master/build
\build> "
Any "normal" Unix installations have a multi-step installation like this:
"UNIX/LINUX - MacOS (terminal) - WINDOWS (cygwin, MinGW)
To build the library, type from source tree directory:
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
Binaries are then located in the 'bin' directory.
To install the library, type with root privileges:
make install
make clean
To build the html documentation, you need doxygen to be installed on your system. It will create an "html" directory in TOP_LEVEL/build/doc)
make doc"
But the Windows 10 equivalent is unclear, to put the most charitable spin on it. You can find it here: "https://github.com/uclouvain/openjpeg/blob/master/INSTALL.md"
Some questions arise:
is there a better starting place for installing JPEG 2000 that actually shows me how to install it and run the tests?
if not, how do I get from the build files to installing the libraries and making the test programs?
Is there more information I can dig out that would help to answer these questions?
Since I'm allergic to Visual Studio, I overlooked a nice tutorial specifying how to install something as complex as openjpeg by direct clone from github. However, in desperation, I found it and it worked. It is Visual Studio Community 2019 Version 16.8.3. I needed only to use -DTHIRDPARTY to get the third party libraries installed. There is a drop-down menu to build and install OPENJPEG. All I need to do now is figure out how to compile and run the utilities that invoke the installed libraries ...
actually, the complete line to add was -DBUILD_THIRDPARTY:bool=true.
Somewhere in my frantic random search for a way forward, I remember seeing the thought that to make the tests work, I merely need to find files like *.vsproj and run them a separate VS solutions. Some random guesswwork with .vdproj files in src/bin/... hasn't produced anything good. Is there not a document somewhere showing how to run the tests?

Built two different Debian packages for different Build Types using CMake

I have a small CMake project with different Build Types debug and release. I'm also providing a Debian package for this project. Building the Debian Package for release and providing it on my own Debian repository works perfect.
Now I also want to provide another Debian package for debug, due to debugging purposes, with a different package name. For example, my project is called myproject, and the debugging package should be myproject-debug.
I already read documentation about how to solve this in the debian/control file. I want to use Replaces: ... on each package vice versa, so that you can install only one of the both packages at a time. So either myproject or myproject-debug, but not both at the same time, to use the exact same files and filenames but only the binary has more debugging informations and debug prints in the myproject-debug package. Everything else should be the same. Same filename, same paths, etc.
Now the problem is that I don't know how the debian/rules file should look like, to first build the myproject package in a folder and then build the myproject-debug with different CMake options (-DCMAKE_BUILD_TYPE=debug) in a different folder, so the filenames can and should stay the same.
There is this CMake tutorial in the Debian documentation, but this doesn't fit my requirements. Because in this tutorial everything will be built in only one folder, and in this one folder there are different files. Then different .install files will be used to copy the needed files to each package. But since I have the same binary filename for each package myproject and myproject-debug this tutorial does not really fit my needs.
I already have the following lines in my debian/rules file:
override_dh_auto_configure:
dh_auto_configure -- -DCMAKE_BUILD_TYPE=release
But how can I run two different builds with two different build types?
For example, something like this, to split it up:
override_dh_auto_configure_release:
dh_auto_configure -- -DCMAKE_BUILD_TYPE=release
override_dh_auto_configure_debug:
dh_auto_configure -- -DCMAKE_BUILD_TYPE=debug
And run both in different folders so I can add both folders to two different packages.
Or maybe there is even a better solution I cannot imagine yet?

How do you build Rebol's "Ren-C" branch with LibFFI support?

I'd like to access a dynamic library using FFI features in the Ren-C Rebol branch. I understand this is possible by building with LibFFI support enabled. What steps do I need to take to enable this?
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
(Note: This is probably the kind of information that should be added to the Wiki, as it is not so much a language question but the kind of thing that is subject to change over time. But, answerable, so...)
If you're using the GNU make method to build (where make -f makefile.boot generates a makefile for you) then you should find some lines in there like:
TO_OS_BASE?= TO_OSX
TO_OS_NAME?= TO_OSX_X64
OS_ID?= 0.2.40
BIN_SUFFIX=
RAPI_FLAGS= -D__LP64__ -DENDIAN_LITTLE -DHAS_LL_CONSTS -O1 ...
HOST_FLAGS= -DREB_EXE -D__LP64__ -DENDIAN_LITTLE ...
Modify the RAPI_FLAGS and HOST_FLAGS lines at the beginning to add -DHAVE_LIBFFI_AVAILABLE. That (-D)efines a preprocessor directive to tell the code it's okay to generate calls to FFI, because you have it available for linking later.
Now to tell it where to find include files. There's a line for includes that should look like:
INCL ?= .
I= -I$(INCL) -I$S/include/ -I$S/codecs/ ...
To the tail of that you need to add something that will look like -I/usr/local/opt/libffi/lib/libffi-3.0.13/include, or similar. The actual directory will depend on where you have libffi on your system. On the OSX system I'm looking at, that has two files in it, ffi.h and ffitarget.h.
(Note: I'm afraid I don't know how these files got on this computer. They didn't ship with the OS, so they came from...somewhere. I don't generally develop on OSX--nor for that matter do I use this FFI. You'll have to consult your local FFI-on-OSX website, or perhaps for support contact Atronix Engineering) who added the FFI features to Rebol.)
Then it's necessary to tell it where you have libffi on your system. You'll find a CLIB line that is likely just CLIB= -lm. You'd change this for example to:
CLIB= -L/usr/local/opt/libffi/lib -lm -lffi
-lffi Tells it to look for the ffi (-l)ibrary, and -lxxx means it assumes the name of the library will be libxxx[something]. -L/usr/local/opt/libffi/lib tells it where to look for it. You'll have to figure out where (if anywhere) you have libffi, and if not get it. If you had it, the directory would have contents something like:
libffi-3.0.13
libffi.6.dylib
libffi.a
libffi.dylib
pkgconfig
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
On Linux it's similar but generally much easier to get the library, as easy as sudo apt-get install libffi-dev. Same step for the RFLAGS and CFLAGS, and it should take care of the location automatically... so you can add just -lffi to CLIB.
Old notes from me:
cat steps-for-lib-ffi-osx
Install libfffi via homebrew
brew install libffi
Add /use/include/libffi to the -I in the generated makefile
Add /usr/local/Cellar/libffi/3.0.13/lib/libffi.a to the OBJS in the
generated makefile
The version 3.0.13 may vary

Empty ${shlibs:Depends} while packaging a Mapnik plugin with cmake-based build system for Debian/Ubuntu

I am creating a Mapnik plugin (https://github.com/rbuch703/coords-mapnik-plugin), and am currently working on packaging it for Debian/Ubuntu. The binary package consists of only a single shared library that is built from C++ code. But being a Mapnik plugin, this library follows conventions quite different from the usual POSIX library conventions:
the file name has to be <name>.input instead of lib<name>.so
the file is installed in the Mapnik plugin directory (usually /usr/lib/mapnik/input)
the file is not supposed to be found by ldconfig, but rather Mapnik tries to find the plugin by itself at runtime
Now the plugin's build system is cmake, which makes most parts of Debian packaging straight-forward: the debian/rules file contains only the basic lines:
#!/usr/bin/make -f
%:
dh $#
However, I am running into problems with the substitution variable {shlibs:Depends}: it is simply not set (in particular, there is no corresponding line in the debian/<package name>.substvars file), and Lintian rightly complains about that fact (Lintian's actual complaint is missing-dependency-on-libc. But when I manually add a libc dependency, Lintian explains package-depends-on-hardcoded-libc, which means "The given package declares a dependency on libc directly instead of using ${shlibs:Depends} in its debian/control stanza."). I would like to satisfy Lintian in than respect, but are unable to do so.
Now I found that I could add the line
dpkg-shlibdeps debian/<packagename>/usr/lib/mapnik/input/coords.input
to my rules file. That will create the correct ${shlibs:Depends} line, but it will create it in the wrong file (debian/substvars instead of debian/<package name>.substvars), where the build system simply ignores it and Lintian keeps complaining about missing dependencies.
I am guessing that the root of my problem is that my Mapnik plugin does not conform to the POSIX library naming conventions (and as a Mapnik plugin cannot do so), and thus the packaging system does not handle it correctly. But I am at a loss as to how to fix this problem.
Additional notes:
the packages are built using debuild. Apart from the Lintian error messages, the build process work fine and correctly creates the .deb package.
my practical goal is for the package to build cleanly on Launchpad, so that I can add it to my Ubuntu PPA.
you can provide an output file for dpkg-shlibdeps with the -T flag.
something like:
override_dh_shlibdeps:
dh_shlibdeps
dpkg-shlibdeps \
-Tdebian/<packagename>.substvars \
debian/<packagename>/usr/lib/mapnik/input/coords.input
if there are multiple *.input files, you could also do something like:
override_dh_shlibdeps:
dh_shlibdeps
find debian/<packagename>/ -name "*.input" -exec \
dpkg-shlibdeps -Tdebian/<packagename>.substvars {} +

Is there any way to change the dynamic library search path in Xcode

Below is my scenario,
In my Application i had to make use of libopus library , i downloaded and install, compile --> install procedure is normal as its for any other open source library,
I linked libopus.a with my application, the way i did is , by default it will get installed in /usr/local/lib, so i drag from there and add it to my application,
Worked fine and no error on my machine,
On Another machine, i was expecting it to be run smoothly as i included this library statically, but its throwing error as
dyld: Library not loaded: /usr/local/lib/libopus.0.dylib
so i concluded, libopus.a somehow including libopus.0.dylib also dynamically,
Now i am able ot add a copy phase in my build setting , so it will get copied in ../Framework folder
if i do otool -L libpus.a then it shows following result
otool -L /usr/local/lib/libopus.a
Archive : /usr/local/lib/libopus.a
/usr/local/lib/libopus.a(bands.o):
/usr/local/lib/libopus.a(celt.o):
/usr/local/lib/libopus.a(cwrs.o):
/usr/local/lib/libopus.a(entcode.o):
/usr/local/lib/libopus.a(entdec.o):
/usr/local/lib/libopus.a(entenc.o):
/usr/local/lib/libopus.a(repacketizer.o):
It doesn't show as its depend upon the dylib library
Now my Question is
How to tell Application to look into this path first
I tried following option,
install_name_tool but it seems it will work on other machine , so the user need to run this script NOT DEVELOPER,
trying to set the some option in the xcode to set the RUNTIME Search path to locate that particular dylib but not getting succeed so far
install_name_tool is run by the developer during the build process, not by the user.
If you're building the library, you should use libtool(1) with the option -install_name #rpath; otherwise, you can use install_name_tool(1) with -id #rpath to do the same thing on the dylib. Then, when you're building your application, set the "Runpath search paths" to the path where you will install the library.
Apple has some good documentation on this in their Mach-O Programming Topics and Dynamic Library Programming Topics.