Building mariadb client with Android NDK - c++

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

Related

Build ICU for iOS

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.

NPM sqlite3 with sqlcipher support

I am trying to cross compile NPM Sqlite3 with sqlcipher support. I am using Ubuntu 16.04 to cross compile for linux armv7 based SOC(system on chip).
So I started with cross-compiling OpenSSL to build sqlcipher for arm. I successfully cross compiled sqlcipher to produce a static library (libsqlcipher.a).
Now I am trying to get the NodeJS side of the project. I need sqlite with sqlcipher support, compiled for arm. I am using SOC SDK to built till now.
I am using node v4.6.1 and npm v2.15.9 to cross compile. I made sure I have the same version installed on Ubuntu as the SOC.
The command I use to cross compile is as follows :
npm install sqlite3 --target_arch=arm --enable-static=yes --build-from-source --sqlite_libname=sqlcipher -fPIC --sqlite=home/onkar/Library/sqlcipher-master/.libs --verbose
I exported the location of the libsqlcipher.a to LDFLAGS. I get the following error when I try to cross compile. Can someone help me with this error?
/home/linuximage/sdk/sysroots/x86_64-angstromsdk-linux/usr/libexec/arm-angstrom-linux-gnueabi/gcc/arm-angstrom-linux-gnueabi/5.2.1/real-ld: error: /home/Library/sqlcipher-master/.libs/libsqlcipher.a(sqlite3.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC
collect2: error: ld returned 1 exit status
node_sqlite3.target.mk:129: recipe for target 'Release/obj.target/node_sqlite3.node' failed
make: *** [Release/obj.target/node_sqlite3.node] Error 1
Please let me know if you require any additional information, I would be more than happy to provide you with the same.
Thanks,
Onkar
In the first instance, you should check if the -fPIC (position independent code) flag was correctly applied when the libsqlcipher.a file was originally created.
In your output above, it looks like the linker is using the file at:
/home/Library/sqlcipher-master/.libs/libsqlcipher.a
Run the command
objdump -r /home/Library/sqlcipher-master/.libs/libsqlcipher.a | more
... and check for a line close to the start of the output beginning with the text
RELOCATION RECORDS FOR
If you see this line, then the library doesn't contain position independent code.

ld: file not found: /usr/lib/crt1.o

When trying to compile Fortran using PGI on Mac OS X Sierra, I get the error
ld: file not found: /usr/lib/crt1.o
I found a workaround for older Mac OS X versions (http://www.pgroup.com/userforum/viewtopic.php?t=4578)
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
However, with Sierra, System Integrity Protection prevents writing in /usr/bin. How can I solve this problem?
I tried linking into /usr/local/bin/ (which is permitted), but then, how can I make sure the compiler searches for library in that path?
Installing just the Command Line Tools for Mac OS X solved the problem. Do this in your terminal:
xcode-select --install
Installing Lazarus on MacOS X :
worked for me
http://wiki.lazarus.freepascal.org/Installing_Lazarus_on_MacOS_X#Xcode_5.0.2B_compatibility_.28Mac_OS_X_10.8_and_10.9.29
Solution for command line programs:
The correct answer for me was as explained in this link:
https://medium.com/#kviat/free-pascal-3-0-2-linking-on-macos-sierra-c40706e86fda
After some googling I realized that most libraries were removed from
/usr/lib in macOS Sierra. However this case is handled in FPC, so we
just need to set internal compiler variable MacOSXVersionMin to 10.8
(or later). There is no standard compiler option for it, but after
some search in source code I found the solution: set the environment
variable MACOSX_DEPLOYMENT_TARGET:
You should give the deployment target of MacOS:
MACOSX_DEPLOYMENT_TARGET= XX.XX #for instance 10.15
Solution for generally:
Linking the necessary file to /usr/bin/crt* . As already stated, this linking will be prohibited by MacOs beginning from 10.10. But there is still a way to accomplish this linking procedure and it solves the problem.
1) Reboot the Mac and hold down Command + R keys simultaneously after you hear the startup chime, this will boot Mac OS X into Recovery Mode
2) When the “MacOS Utilities” / “OS X Utilities” screen appears, pull down the ‘Utilities’ menu at the top of the screen instead, and choose “Terminal”
3) Type the following command into the terminal then hit return:
csrutil disable; reboot
4) When you come back, run the command sudo mount -uw /
5) Just run the linking code you want to:
sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o /usr/lib/crt1.o
sources: http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/
https://www.reddit.com/r/MacOS/comments/caiue5/macos_catalina_readonly_file_system_with_sip/
In my case the problem was actually an error on the PGI installation side. PGI seems to be well aware that newer versions of macOS do not have the /usr/lib/crt1.o and that you can't create files there anymore. But it is possible to setup correct environment variables for the PGI compilers and then the linker should use the correct path to the crt1.o.
This configuration should be done automatically during the installation of the PGI compiler suite by running the makelocalrc command and should generate the file /opt/pgi/osx86-64/$PGIVER/bin/localrc. But in my case this step failed silently.
Reasons for failure seem to be:
license agreement for XCode not (yet) accepted, although this error should leave you with a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error, containing some details
XCode version not supported, which seems to leave you with nothing. This is what I got when I ran the makelocalrc script manually:
makelocalrc -x /opt/pgi/osx86-64/19.10
Error: Unsupported XCode version 11
In my case (PGI 19.10, macOS 10.15, XCode 11.2.1) I manually patched the /opt/pgi/osx86-64/19.10/bin/makelocalrc to not error out on XCode 11:
if test $xcodever -gt 11 ; then # <-- was "-gt 10"!
echo " Error: Unsupported XCode version " $xcodever
exit -1
fi
and then re-ran the script after which compilation with PGI compilers (both pgcc and pgfortran) worked:
sudo /opt/pgi/osx86-64/2019/bin/makelocalrc -x /opt/pgi/osx86-64/19.10
Your case may vary, but you might want to check for a /opt/pgi/osx86-64/$PGIVER/bin/localrc.error or the /opt/pgi/osx86-64/$PGIVER/bin/localrc itself and try to manually (re-) generate it if it is not there or if you upgraded XCode/macOS since the installation of the PGI compilers.

Unable to run Woden Physics Example in Pharo

I am trying to run the Woden Physics Example inside Pharo which involves getting Bullet properly compiled and the smalltalk bindings properly installed in Pharo.
I am using Linux Mint 17 x64.
But NativeBoost seems unable to load the compiled libraries. I have been using the sources provided here:
https://github.com/ronsaldo/bullet-pharo
https://github.com/ronsaldo/swig
I built the modified version of swig as well as the bullet libraries and bindings with the provided build scripts.
I also have doublechecked that the bullet libraries are 32 bit.
Opening up the Woden physics example returns this error:
failed to get a symbol address:
PharoNB_new_BTDefaultCollisionConfiguration__SWIG_1
When examining the call stack in the debugger, it turns out that the module handle is 0.
I verified this by executing the same message as
BulletCInterface nbLibraryNameOrHandle
executes:
NativeBoost forCurrentPlatform loadModule: 'BulletPharo'
This message returns 0. I tried to specify the full path to libPharoBullet.so in the workspace, like:
NativeBoost forCurrentPlatform loadModule:
'/home/martin/.local/share/Pharo/bullet-pharo/libBulletPharo.so'
with the same result. I also verified it with a 32 bit system library of mine (liblzma) and there NativeBoost was able to load it, as it returned a non-zero handle.
So i suspect something during compilation went wrong...
I also did
readelf -h libPharoBullet.so
and its ABI was "UNIX - GNU" while the ABI of pharo-vm is "UNIX - System V"
Could this be the problem here ?
How can i force the ABI to be System V when compiling ? I use gcc 4.8.2
Or what steps could i otherwise perform ?

How to compile CodeBlocks MingW in Windows to Ubuntu or Centos

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