I need ICU library for iPhone. I have tried to build it from souce, however, I am getting this erros:
clang++ ... /Users/petr/Development/icu-cross-compile-master/icu-60-2/source/tools/pkgdata/pkgdata.cpp
/Users/petr/Development/icu-cross-compile-master/icu-60-2/source/tools/pkgdata/pkgdata.cpp:544:18: error: call to unavailable function 'system': not available on iOS
int result = system(cmd);
^~~~~~
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.2.sdk/usr/include/stdlib.h:195:6: note: candidate function has been explicitly made unavailable
int system(const char *) __DARWIN_ALIAS_C(system);
sh ${ICU_SOURCE}/configure --host=arm-apple-darwin --with-cross-build=${PREBUILD_DIR} ${PREFIX}
My PREFIX configuration is as:
--enable-extras=yes
--enable-tools=yes
--enable-icuio=yes
--enable-strict=no
--enable-static
--enable-shared=no
--enable-tests=yes
--disable-renaming
--enable-samples=no
--enable-dyload=no
--with-data-packaging=static
Or is there any other way, how to generate libicudata.a? The similar build script works OK for Android, Mac and Win. Only iPhone is problem.
The problem is that system() is deprecated for iOS 11.
I think quick fix for you will be in using Xcode 6, instead of Xcode 9, so you can compile for iOS 7 as a target, where system() wasn't deprecated.
Or, if you really need iOS full compatible solution, you need to re-write ICU source code to use posix spawn functionality instead of system(). Check this answer for more details: How do you use posix_spawn to replace the deprecated 'system' to launch opendiff in Objective-C?
Another solution to successfully build ICU on iOS as a library is to build without tools with the configure flag --build-tools=no. The following is the complete set of configure flags I'm using to build for various platforms, android and ICU included.
--enable-static=yes
--enable-shared=no
--enable-extras=no
--enable-strict=no
--enable-icuio=no
--enable-layout=no
--enable-layoutex=no
--enable-tests=no
--enable-samples=no
--enable-tools=no
--enable-dyload=no
--with-data-packaging=archive
I've just made a makefile which will download the ICU source and create a universal framework for Mac, Catalyst, iOS Simulator and iOS. This can then just be drag-and-dropped into your project.
https://github.com/dbquarrel/icu4c-xcframework
Might help you (though many years late).
My use was to enable the icu tokenizer in sqlite for iOS.
Related
I've been trying to cross compile jlibtorrent for the raspberry pi which uses boost build for compiling. I am using the officially provided cross compiler with the following config.jam:
import os ;
using gcc : arm : arm-linux-gnueabihf-g++ :
<cxxflags>-fPIC
<cxxflags>-std=c++14
<cxxflags>-fno-strict-aliasing
<cxxflags>-fvisibility=hidden
<linkflags>-m32
<linkflags>-static-libstdc++
<linkflags>-static-libgcc
<linkflags>"-z noexecstack"
# debug information
<cxxflags>-g
<cxxflags>-gdwarf-4
<cxxflags>-ggdb
;
I basically copied the existing configuration for linux-x86 and replaced the compiler, but I'm getting the following compilation error:
libtorrent/src/entry.cpp: In member function 'libtorrent::entry& libtorrent::entry::operator[](libtorrent::string_view)':
libtorrent/src/entry.cpp:86:33: error: no matching function for call to
'std::map<std::basic_string<char>, libtorrent::entry, libtorrent::aux::strview_less, std::allocator<std::pair<const std::basic_string<char>, libtorrent::entry> > >::find(libtorrent::string_view&)'
auto const i = dict().find(key);
My only guess is that the version of the cross compiler (4.9.3) is not compatible with libtorrent, because I saw in the linux-32-config.jam that it uses g++-5. Is there anything else I am missing?
You can find the modified repository in my github repositories. I am using swig/build-linux-armv7.sh for building.
that call (std::map::find()) was added in C++14 (see docs). I see you pass in -std=c++14 on the command line as well. Are you sure your GCC supports C++14? It seems a bit old for that.
The current stable branch of libtorrent only requires C++11 support, if that is the branch you're building, there may be something wrong with the compiler support detection here. If you are building from libtorrent master, it requires proper C++14 support. So in that case you may want to use the stable release.
Thanks to #Arvid I managed to compile it using the current stable branch for libtorrent (RC_1_2) and the following jam file, which you can find here.
import os ;
using gcc : arm : arm-linux-gnueabihf-g++ :
<cxxflags>-fPIC
<cxxflags>-std=c++11
<cxxflags>-fno-strict-aliasing
<cxxflags>-fvisibility=hidden
<linkflags>-static-libstdc++
<linkflags>-static-libgcc
<linkflags>"-z noexecstack"
# debug information
<cxxflags>-g
<cxxflags>-gdwarf-4
<cxxflags>-ggdb;
Yet another linux build newb here, struggling to build mariadb-client for Android using the NDK.
I have already succesfully built openssl and libiconv, which are perquisites.
Here is what I am doing:
export ANDROID_NDK_ROOT="/home/dev/android-ndk-r12b"
SR="$ANDROID_NDK_ROOT/platforms/android-16/arch-arm"
BR="$ANDROID_NDK_ROOT/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-"
mkdir build && cd build
PKG_CONFIG_PATH=$SR/usr/lib/pkgconfig cmake -DCMAKE_AR="$BR"ar -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER="$BR"gcc -DCMAKE_C_FLAGS=--sysroot=$SR -DCMAKE_INSTALL_PREFIX=$SR/usr -DCMAKE_LINKER="$BR"ld -DCMAKE_NM="$BR"nm -DCMAKE_OBJCOPY="$BR"objcopy -DCMAKE_OBJDUMP="$BR"objdump -DCMAKE_RANLIB="$BR"ranlib -DCMAKE_STRIP="$BR"strip -DWITH_EXTERNAL_ZLIB=ON -DICONV_INCLUDE_DIR=$SR/usr/include -DICONV_LIBRARIES=$SR/usr/lib/libiconv.a -DZLIB_INCLUDE_DIR=$SR/usr/include -DZLIB_LIBRARY=$SR/usr/lib/libz.so ../
make install
To break down that last part so it is more readable:
PKG_CONFIG_PATH=$SR/usr/lib/pkgconfig
cmake
-DCMAKE_AR="$BR"ar
-DCMAKE_BUILD_TYPE=Release
-DCMAKE_C_COMPILER="$BR"gcc
-DCMAKE_C_FLAGS=--sysroot=$SR
-DCMAKE_INSTALL_PREFIX=$SR/usr
-DCMAKE_LINKER="$BR"ld
-DCMAKE_NM="$BR"nm
-DCMAKE_OBJCOPY="$BR"objcopy
-DCMAKE_OBJDUMP="$BR"objdump
-DCMAKE_RANLIB="$BR"ranlib
-DCMAKE_STRIP="$BR"strip
-DWITH_EXTERNAL_ZLIB=ON
-DICONV_INCLUDE_DIR=$SR/usr/include
-DICONV_LIBRARIES=$SR/usr/lib/libiconv.a
-DZLIB_INCLUDE_DIR=$SR/usr/include
-DZLIB_LIBRARY=$SR/usr/lib/libz.so
The first error I got was that program_invocation_short_name was undefined in this bit of code:
#elif defined(_GNU_SOURCE)
const char * appname = program_invocation_short_name;
#elif defined(WIN32)
I couldn't find why this is and how to fix, so I decided to cheat my way through by assigning an empty string to it. Possibly with negative repercussions, but I noticed the source doing the same thing a few lines down so I decided to give it a go nonetheless.
Another build attempt, and now I am getting undefined references for iconv functions:
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv_open'
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv'
CMakeFiles/mariadb_obj.dir/ma_charset.c.o:ma_charset.c:function mariadb_convert_string: error: undefined reference to 'iconv_close'
CMakeFiles/mariadb_obj.dir/ma_context.c.o:ma_context.c:function my_context_spawn_internal: error: undefined reference to 'setcontext'
CMakeFiles/mariadb_obj.dir/ma_context.c.o:ma_context.c:function my_context_continue: error: undefined reference to 'swapcontext'
The libraries are definitely there, as defined in the configuration above. Maybe that's a side effect of the above cheat?
Or maybe something else entirely is going wrong?
Once again, a complete newb in this regard, but I get a newb hunch that it may have something to do with cmake. Is it possibly using the host machine cmake but should be using some "android toolchain" cmake instead? I couldn't find much info on that either, but it could explain why it isn't picking the program_invocation_short_name thingie and the libs.
So, any ideas what is going wrong and how to fix it?
The build env should be clear by the first few lines of code but just in case, it's Ubuntu 16.04 x64, using NDK r12b and the GCC 4.9 toolchain. I am using the following versions of the libraries: libiconv 1.15, openssl 1.1.0f and mariadb_connector_c 3.0.3.
Currently MariaDB Connector/C doesn't support Android NDK, this is planned for the upcoming 3.0.3 release.
To build MariaDB Connector/C with Android NDK you need to checkout the 3.0-portable branch of MariaDB Connector/C.
Iconv support currently doesn't work, same is valid for Kerberos/GSSAPI authentication plugin.
For building MariaDB Connector/C with Android NDK you have specify additionally the following CMake parameters:
-DWITH_ICONV=OFF -DWITH_DYNCOL=OFF -DAUTH_GSSAPI_TYPE=OFF
If you don't need SSL/TLS support, you can disable it by specifying
-DWITH_SSL=OFF
I am currently installing the HDF5 library, more precisely the hdf5-1.10.0-patch1, on Cygwin, as I want to use it with Fortran. Following the instructions from the hdfgroup website
(here is the link), I did the following:
./configure --enable-fortran
make > "out1_check.txt" 2> "warn1_check.txt" &
make check > "out2_check.txt" 2> "warn2_check.txt" &
The execution of the last command (make check) proceeds as it should, until it gets stuck. The process does not stop and something is happening (8-12% CPU are in use by sh.exe, already 39 hours of CPU time) but "out2_check.txt" looks like
Making check in src
...
[many successful checks]
...
============================
No need to test testlinks_env.sh again.
============================
============================
Testing testswmr.sh
Unfortunately, I do not have the output file from the first run of make check, but it did not contain more information on Testing testswmr.sh. There was never any error message.
So, what is this testswmr.sh, why does it get stuck and how can I finalize the installation process? Maybe I can skip the remaining checks and just proceed to make install?
Important note: an older version of HDF5 is already installed from the Cygwin repo. It does not seem to support Fortran however, so I decided to install the current version myself.
Available (and used) compilers are gcc and gfortran.
As far as I can tell, only Intel Fortran is supported on Windows. There is no Cygwin download here https://support.hdfgroup.org/HDF5/release/obtain518.html and I have never come across a report of experience for Cygwin/Fortran/HDF5.
Your options:
Use Intel Fortran
Use Linux or Mac
Sorry
I would like to build a cross-platform cxx_library with buck. I have different cpp files for the different platforms. According to the docs, I can handle this using platform_srcs, which is:
...a list of pairs where the first element is an un-anchored regex (in java.util.regex.Pattern syntax) against which the platform name is matched".
What do these platform names look like?
What are some example regexes I could use for OSX, Windows and Linux?
Android: android
iPhone: iphoneos
iPhone Simulator: iphonesimulator
Linux: Unsure
OSX: Unsure
Windows: ^windows.*
I am using the following:
Android: android.*
iPhone: iphoneos.*
iPhone Simulator: iphonesimulator*
Linux: linux.*
macOS: macos.*
Windows: windows.*
Don't forget to turn on should_remap_host_platform in order to avoid 'default' platform weirdness. In your .buckconfig:
[cxx]
should_remap_host_platform = true
See: https://github.com/facebook/buck/issues/2073
Is there a way to compile with MingW with CodeBlocks in Windows so they can be used in Ubuntu or Centos distros?
I've tried compiling with GNU GCC option then got the output file with .o extensions under obj/Release/ folder.
When I run I get this error under my Vagrant Ubuntu machine:
-bash: ./main.o: cannot execute binary file
How can I compile it so it runs on my Linux machines?
The technical term for what you're trying to accomplish is cross-compilation. For that, you need to build a specific cross-compiler using GCC sources. If you still want to keep MinGW, there is a page explaining the steps needed to create a ARM cross-compiler : http://www.mingw.org/wiki/HostedCrossCompilerHOWTO. (you'll have to modify the target)
List of targets supported by GCC :
armv5te-android-gcc armv5te-linux-rvct armv5te-linux-gcc
armv5te-none-rvct
armv6-darwin-gcc armv6-linux-rvct armv6-linux-gcc
armv6-none-rvct
armv7-android-gcc armv7-darwin-gcc armv7-linux-rvct
armv7-linux-gcc armv7-none-rvct
mips32-linux-gcc
ppc32-darwin8-gcc ppc32-darwin9-gcc ppc32-linux-gcc
ppc64-darwin8-gcc ppc64-darwin9-gcc ppc64-linux-gcc
sparc-solaris-gcc
x86-android-gcc x86-darwin8-gcc x86-darwin8-icc
x86-darwin9-gcc x86-darwin9-icc x86-darwin10-gcc
x86-darwin11-gcc x86-darwin12-gcc x86-linux-gcc
x86-linux-icc x86-os2-gcc x86-solaris-gcc
x86-win32-gcc x86-win32-vs7 x86-win32-vs8
x86-win32-vs9
x86_64-darwin9-gcc x86_64-darwin10-gcc x86_64-darwin11-gcc
x86_64-darwin12-gcc x86_64-linux-gcc x86_64-linux-icc
x86_64-solaris-gcc x86_64-win64-gcc x86_64-win64-vs8
x86_64-win64-vs9
universal-darwin8-gcc universal-darwin9-gcc universal-darwin10-gcc
universal-darwin11-gcc universal-darwin12-gcc
generic-gnu
There is only one big caveat : since Windows is not POSIX compliant, I don't think you can use signals or pthreads.
Finally, brace yourself because it's a tedious task to build a cx-compiler (lots of obscure bugs). That's why profesionnal devs pays $$$ for "plug'n'play" solutions.
EDIT : this MXE project can be useful to you