Srt: Compile for iOS

[Gummilion]

Hello
Could anyone tell how to compile SRT project for iOS? I followed instruction for Mac and built code for OS X successfully. But how to build it for ARMv7 - certainly linker can't take libsrt.dylib since it built for x86. I didn't find any options for config or makefile to set target platform to iOS and architecture to ARM.

Thank you.

[ethouris]

If you are using a crosscompiler, I recommend using configure wrapper with a --with-compiler-prefix option (note: it's a prefix, not a path). You may also need --with-compiler-type because the default compiler type is gcc (this is a command used for a C compiler, for clang it will follow a simple adding ++ for having a C++ compiler command).

For the sake of looking for an OpenSSL library to be linked dynamically against, the "root directory" for the foreign-platform libraries (actually needed to look for the *.pc file) can be supplied through --with-target-path (which is first searched in a path derived from --with-compiler-prefix).

[lars18th]

Me too! I'm interested in supporting other platforms beside x86/LinuxPC.

@Gummilion , please if you advance in this point, publish your results.
I'll try to advance in this area when I have sufficient time. My targets are ARM and MIPS in OpenWRT, plus Raspberry Pi (Debian with ARM).

Regards.

[Gummilion]

Sorry, I never perform crosscompiling beyond XCode for iOS before. So I need to setup ARM toolchain for MacOS and build OpenSSL and SRT by gcc-arm, did I get it right?

[nitrat7]

Raspbian GNU/Linux 9 (stretch) worked out of box ...
same for ubuntu@arm for raspberry..

[ethouris]

You just need to know the path for the compiler command line. AFAIR the only compiler on Macs is now clang (it only provides a gcc-named driver for convenience). Note that OpenSSL that is usually installed in the Mac system is inappropriate for SRT, for native Mac I was using the one provided by Brew. Not sure how it should be for iOS.

[Gummilion]

I found a way to compile it: built SSL with OpenSSL for iPhone project and got CMake toolchain for iOS.
Then I prepare it with ./configure --openssl-include-dir=../OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk/include/openssl --openssl-libraries=../OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk/lib/libcrypto.a --cmake-toolchain-file=../ios-cmake/toolchain/iOS.cmake
By the way, configure --help tells about --with-openssl-includedir and --with-openssl-libdir options but seems it's a lie - that options just have no any effect and I figured out to use openssl-include-dir and openssl-libraries instead.

[alexpokotilo]

@ethouris could you please check if it's truth and we need to file pull request to fix this

[ethouris]

Ah, probably. Some changes in the library specifying options have been done over my hand and the options in cmake now are named differently (kinda "cmake way") and this could make options defined in configure no longer valid.

Note that configure is only a user-friendly wrapper that redirects the call to cmake. Not all options that can be used are defined in the help section. It's rather impossible to enumerate all options because what really is honored it depends on what variables are used in cmake - the only way is to manually review these variables and put appropriate option names in the help table manually (the cmake cache can be probably used, but only after it has been at least once generated). The configure handles some options special way, but if an option isn't handled, it's transparently passed to cmake using a transformation --some-c++-option --> -DSOME_CXX_OPTION=1.

I'll review these --with-openssl* options and try to add more options to the help table.

[ethouris]

Ok, added #273 that should fix it.

@Gummilion - when you succeed with compiling SRT for iPhone, please let us know if everything is ok. Note also that if the OpenSSL library contains recognition tools according to the standard (such as *.pc file for pkg-config), and the directory layout is POSIX-like, you may try with --with-target-path option that will lead to root directory if the installation. Mind that "pthread" is another dependency, however I'd expect that on Mac-derived system this dependency should be satisfied out of the box. I added a fix last time that can ignore problems that cmake makes with finding pthread on a crosscompiler environment, but it's currently waiting in the PR schedule.

[alexpokotilo]

Thanks a lot!
Sure, we will provide all necessary details to the community and push config/code changes if necessary.

[Gummilion]

Somehow CMake fails to find openssl library and I failed to solve it, so I need to specify it explicitly with command like:
./configure --with-openssl=$SRC/OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk --openssl-include-dir=$SRC/OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk/include --openssl_ssl_library=$SRC/OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk/lib/libcrypto.a --cmake-toolchain-file=$SRC/ios-cmake/toolchain/iOS.cmake --enable_shared=OFF

CMake also reports
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
But after I tried to specify it explicitly by adding execute_process(COMMAND which pkg-config OUTPUT_VARIABLE PKG_CONFIG_EXECUTABLE) it founds PkgConfig, but still can't find OpenSSL (even when I set OPENSSL_ROOT_DIR):

-- Found PkgConfig: /usr/local/bin/pkg-config
 (found version "") 
CMake Error at /usr/local/Cellar/cmake/3.10.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.10.2/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/Cellar/cmake/3.10.2/share/cmake/Modules/FindOpenSSL.cmake:390 (find_package_handle_standard_args)
  CMakeLists.txt:112 (find_package)

Probably there is some issue with pkg-config, but I can't realize what may be wrong - I installed it with Homebrew, and seems it have recent version: pkg-config --version reports 0.29.2 (while I have 0.29.1 on my Linux machine). I have no idea what can be wrong with it.
Anyway, at least I have workaround with full paths - it produces valid library I can add to Xcode project. And srt_startup() returns 0, so seems it working so far.

[ethouris]

I had something around problem a while ago. For this pkg-config, I believe it should be enough if you simply have PATH to /usr/local/bin so that you can execute pkg-config without explicit path.

If this is crosscompiling and you have some "root directory for target library storage", remember to use --with-target-path option that points to this root directory. When you add this, all other package autodetection things should be done by cmake automatically. This --with-openssl* thing is some remaining garbage from previous versions, don't use it.

Example: If you have your target root directory installed at $HOME/SDK/root (so your openssl library file is e.g. $HOME/SDK/root/lib/libcrypto.so), use --with-target-path=$HOME/SDK/root. With this, cmake should find OpenSSL library by itself, as long as there is $HOME/SDK/root/lib/pkgconfig/openssl.pc file. There's also a fix for a case when the PREFIX entry in this file is incorrect (that is, PREFIX=/usr) - it's ignored then and the target path is used.

I've submitted #273 that adds more precise information about all options that are specifically applicable for configure.

[Gummilion]

@ethouris - since I cross-compile with toolchain, PATH is not searched - I found that toolchain file has set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY) line. But I got your idea that I should put pkg-config to a place where CMake can found it. So I copied pkg-config to bin directory inside of OpenSSL and passed path to CMake by adding --cmake-prefix-path. After that cmake picked up PkgConfig successfully, as well as library and include directrories. So finally it works with this command:
./configure --cmake-prefix-path=$SRC/OpenSSL-for-iPhone/bin/iPhoneOS11.2-arm64.sdk --cmake-toolchain-file=$SRC/ios-cmake/toolchain/iOS.cmake --enable-shared=OFF

[lars18th]

Hi,

I suggest to generate a TXT or WIKI with all the info related to _cross-compile_ the SRT library.
Perhaps, it's now difficult to automate the compilation in such environment. But, probably a simple guide will be sufficient for most people who do this task.

You agree?

[alexpokotilo]

@lars18th yes sure we can do that. I would suggest to separate Android and IOS guides as they differ. We're working to integrate SRT into Android/IOS and looks like we are able to compile on both.
Is there any guide to commit such work ? Should we add README to git repo or file new Wiki page ?
@ethouris what would you suggest ? We are ready to help

[lars18th]

Hi @alexpokotilo ,

t. I would suggest to separate Android and IOS guides as they differ. We're working to integrate SRT into Android/IOS and looks like we are able to compile on both.
Is there any guide to commit such work ? Should be add README to git repo or file new Wiki page ?

My suggestion is then: Update the "README.md" file with two new subsections Cross-Compile\Android and Cross-Compile\iOS. Both can go after the current __Requirements__. I feel it will be required to add an entire new section called __How to Compile__. And inside it add the different subsections: _Native Compile_ (for Linux, Windows, etc.) and _Cross-Compile_ (with sections for Android, iOS and other platforms... OpenWRT, etc.).

If you do in this way, then prepare a PR with your changes.
You agree?

[ethouris]

That's very good idea! If you have something that you can describe in a *.md file, you can add even a new file under docs directory for this, say, Compiling.md. By some reasons we don't prefer Wiki functionality in Github for that purpose, but the *.md files can be read directly by viewing the repository contents. The problem with Wiki is that even though it's versioned, the usual process that includes branching, reviews etc. can't be done just like with the others.

[Gummilion]

The last thing I need to solve is to build shared library. I was able to made iPhone load it by specifying -install_name "@executable_path/Frameworks/libsrt.1.3.0.dylib", otherwise application just failed to find it. But I simply modified link.txt in CMakeFiles directory - definitely it isn't right way to do it. Is there some option I may pass to CMake to setup this path? I was trying to add --installdir to configure options, but it doesn't affect install_name value.

[ethouris]

The --installdir option isn't handled, AFAIK. You only have --prefix which is an alias to --cmake-install-prefix.

I found some documentation here and some stackoverflow question here, should that help anyhow. Might be that some special extra options should be added in cmake specifically for that system.

[ethouris]

Sorry, wrong. The --installdir option is handled, but it's in use only - currently - for generation of the srt.pc file.

You need --installdir to specify the "real installation target", when you'd like to install the library in a temporary directory, which you specify with --prefix. This is useful if you prepare, for example, an RPM package. If you don't specify --installdir, it defaults to --prefix.

[Gummilion]

Thank you, I found a way to specify install_name. I added this to toolchain cmake:

set (CMAKE_INSTALL_NAME_DIR  "@executable_path/Frameworks")
set (CMAKE_BUILD_WITH_INSTALL_NAME_DIR TRUE)

Also it searches for libsrt.1.dylib (instead of 1.3.0) since version suffix is defined by SOVERSION property for shared library and it set to "1" in main CMakeLists.txt file. Don't sure whether it needed to add special handling for iOS version to skip setting SOVERSION, or copying of libsrt.1.dylib is appropriate.

I'm working on how-to for building SRT for iOS, so I will present it soon.

[ethouris]

Great news! Is there a need that anything here has to be configurable by user here?

And - can it work under the definition of DARWIN symbol (see the definition at set_if call)? I'm asking because I haven't tried to compile for that system before, I have only used Mac.

[Gummilion]

I put all iOS-specific settings in separate CMake file (passed with CMAKE_TOOLCHAIN_FILE option), so other platform are unaffected. User just need to specify path to OpenSSL (with CMAKE_PREFIX_PATH) and CMAKE_TOOLCHAIN_FILE. This toolchain file has number of modification from baseline, I suppose it should be included to SRT project.

[ethouris]

If so, put it under scripts directory.

[Gummilion]

I have created pull request, please review it and try to build according to the manual.

[yangxun5075]

When I compile srt on mac for IOS, I have met following error, how can I do?

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(api.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(buffer.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(cache.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(channel.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(common.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(core.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(crypto.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(epoll.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(fec.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(handshake.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(list.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: archive member: libsrt.a(md5.cpp.o) cputype (16777223) does not match previous archive members cputype (16777228) (all members must match)

[ethouris]

Did you try making a clean compile after you upgraded your operating system?

[sunlock21]

I try to compile srt for ios.
configure like this:
./configure --use-openssl-pc=OFF --openssl-crypto-library=/lyh/arm64/openssl_1_1_1e-dev/lib/libcrypto.a --openssl-ssl-library=/lyh/arm64/openssl_1_1_1e-dev/lib/libssl.a --openssl-include-dir=/lyh/arm64/openssl_1_1_1e-dev/include --prefix=/lyh/arm64 --enable-static --enable-shared=0 --with-compiler-type=clang --cmake-toolchain-file=./scripts/iOS.cmake
confige is done,compile is done.
But when I configure ffmpeg, I met this:
...
"___gxx_personality_v0", referenced from:
_srt_sendfile in libsrt.a(srt_c_api.cpp.o)
std::__1::basic_fstream >::~basic_fstream() in libsrt.a(srt_c_api.cpp.o)
_srt_recvfile in libsrt.a(srt_c_api.cpp.o)
_srt_strerror in libsrt.a(srt_c_api.cpp.o)
_srt_listen_callback in libsrt.a(srt_c_api.cpp.o)
non-virtual thunk to std::__1::basic_fstream >::~basic_fstream() in libsrt.a(srt_c_api.cpp.o)
virtual thunk to std::__1::basic_fstream >::~basic_fstream() in libsrt.a(srt_c_api.cpp.o)
...
__ld: symbol(s) not found for architecture arm64__
clang: error: linker command failed with exit code 1 (use -v to see invocation)

In the iOS.cmake arm64 should default.
if (NOT DEFINED IOS_ARCH)
if (${IOS_PLATFORM} STREQUAL OS)
set (IOS_ARCH arm64)

How can I do ?

[ethouris]

This looks like your build environment specific problem.

[sunlock21]

ok,maybe is ffmpeg configure para's problem,lipo can show that libsrt.a architecture is arm64

[sunlock21]

Added --extra-libs="-lstdc++" , done.