Using Google NDK toolchain with NDK21 for 'autoconf' projects says this:
# Check out the source.
git clone https://github.com/glennrp/libpng -b v1.6.37
cd libpng
# Only choose one of these, depending on your build machine...
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/darwin-x86_64
export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/linux-x86_64
# Only choose one of these, depending on your device...
export TARGET=aarch64-linux-android
export TARGET=armv7a-linux-androideabi
export TARGET=i686-linux-android
export TARGET=x86_64-linux-android
# Set this to your minSdkVersion.
export API=21
# Configure and build.
export AR=$TOOLCHAIN/bin/llvm-ar
export CC=$TOOLCHAIN/bin/$TARGET$API-clang
export AS=$CC
export CXX=$TOOLCHAIN/bin/$TARGET$API-clang++
export LD=$TOOLCHAIN/bin/ld
export RANLIB=$TOOLCHAIN/bin/llvm-ranlib
export STRIP=$TOOLCHAIN/bin/llvm-strip
./configure --host $TARGET
make
It seems that this example cannot be used for other 'autoconf' projects like 'libxml2'. Using the lines above will break build process when trying to create a shared library.
'libtool' does not create a 'so' file in this case but only creates a 'la' file.
The reason for that is that the line
export LD=$TOOLCHAIN/bin/ld
is pointed to a non existing file. Because of that libtool does not invoke the linking process. If I change the line to
export LD=$TOOLCHAIN/bin/ld.lld
or do not export 'LD' at all it is working fine.
See the same problem here https://github.com/libexpat/libexpat/issues/312
Question
Is the Google NDK documentation really wrong here or do I miss something?
The docs also say
The tools selected in this sample are correct for NDK r22 and newer. Older NDKs may require different tools.
You're using r21.
I just followed the instructions using r24 and the only issue I ran into was https://github.com/glennrp/libpng/issues/347, which is a libpng issue, not an Android issue. Replacing that #ifdef __clang__ with #if defined(__clang__) && defined(__APPLE__) makes the project compile just fine.
Related
I need to build libpng, but without #define PNG_READ_eXIf_SUPPORTED in pnglibconf.h
I've read comments from pnglibconf.dfa, and here are some ways of disabling features, however I didn't manage to make what I want using them.
The problem is in that, build process is performed on build server, so I can't change any files inside of libpng submodule. Here is how server works:
Download clone sources from git
Generate makefile by running cmake ..
Run make command.
Thus I have libnpg, but with included PNG_READ_eXIf_SUPPORTED option.
Libpng is a submodule of my project, so it checked out by build server automatically so I can't change pnglibconf manually.
As it said in pnglibconf.dfa file:
There are three ways of disabling features, in no particular order:
1) Create 'pngusr.h', enter the required private build information
detailed below and #define PNG_NO_<option> for each option you
don't want in that file in that file. You can also turn on options
using PNG_<option>_SUPPORTED. When you have finished rerun
configure and rebuild pnglibconf.h file with -DPNG_USER_CONFIG:
make clean
CPPFLAGS='-DPNG_USER_CONFIG' ./configure
make pnglibconf.h
pngusr.h is only used during the creation of pnglibconf.h, but it
is safer to ensure that -DPNG_USER_CONFIG is specified throughout
the build by changing the CPPFLAGS passed to the initial ./configure
I tried to do what is written here. I run cmake .. -DCMAKE_C_FLAGS="-DPNG_USER_CONFIG -I/home/me/dev/include" where /home/me/dev/include - is a path to pngusr.h file
Then I run make command. However, PNG_READ_eXIf_SUPPORTED is still present in generated (by make command pnglibconf.h file).
So my main question is how to make libpng without PNG_READ_eXIf_SUPPORTED option?
It remains unclear to me whether and to what extent the specific customization mechanism you are trying to use works in the version of libpng you are trying to use. But it looks like there's a simpler way. Just below the excerpt you posted, in the same file, is the second (of three) alternatives:
2) Add definitions of the settings you want to change to CPPFLAGS;
for example:
-DPNG_DEFAULT_READ_MACROS=0
(lightly formatted). I'm not in a good position to test that on the CMake-based build system, but it seems to work like a charm in the Autotools build system. From examining and comparing the two, I think it will work for CMake, too. In particular, you would want to run
cmake .. -DCMAKE_CPP_FLAGS="-DPNG_NO_READ_eXIf"
for your particular case.
Note, by the way, that the CPP (i.e. preprocessor) flags are the right place for an option such as you are specifying (for -DPNG_USR_CONFIG in your original attempt, too). In practice, though, they probably still work in the C compiler flags.
When using CMake in a regular project, some variables (e.g library paths) can be configured via -D option or by using ccmake or cmake-gui The values are saved in the cache, and this provides for a local configuration that is specific to every user/developer of the code.
In Android Studio, CMake can be configured from Gradle, but I haven't been able to find an equivalent to the options above. The local.properties file can be read from gradle, but it's overwritten by AS.
Is there any way of setting CMake variables to local values from Android Studio?
Example: On a regular CMake project, I can add a line to my CMakeLists.txt like:
set(EIGEN_DIR /usr/local/include/eigen3 CACHE PATH "Eigen path")
And then two different developers may set that value to their particular systems (ie. /usr/local/include/eigen3 or /opt/local/include/eigen3) without affecting the project source code. However, in Android Studio, the only way seems to be from build.gradle, which is part of the project, and will get committed to the repositories.
I found this can be achieved by putting the variables with the desired value in the local.properties file, and then read them with the code from this answer:
Properties props = new Properties()
props.load(new FileInputStream(project.rootProject.file('local.properties')))
String conf_value = props['conf.value']
and then
externalNativeBuild{
cmake {
arguments "-DMY_CONF_VALUE="+conf_value
...
}
}
I need to compile PortAudio's paex_record_file.c file using Eclipse and CDT on Ubuntu 12.04.5 LTS.
Dev libraries (libportaudio-dev) was installed via Synaptic.
I create new Eclipse project and create (copy) this only file to it (so project contains only one user source file 'paex_record_file.c', 1752 2011-09-08 03:21:55).
Then i use Eclipse's Pkg-config to add 'portaudio' (dev) library.
But it not compiles with error
../src/paex_record_file-test.c:47:27: fatal error: pa_ringbuffer.h: No such file or directory
Then source branch taken from git
$ git clone https://git.assembla.com/portaudio.git
./configure
make
sudo male install
But still get same error (no 'pa_ringbuffer.h').
Then during blind trials and errors i use Project - Properties - C build - Settings - Tool settings - Includes, and add '/home/test/portaudio/src/common' path which contains needed .h file, and (this) error disappear.
Question 1: Is this step is correct use of Eclipse settings in this case? (i believe not, because i never need to use this setting before).
But then it shows multiple errors like
/home/doc/prog/paex_record_file-test/Debug/../src/paex_record_file-test.c:110: undefined reference to `PaUtil_GetRingBufferReadAvailable'
and this is unrecoverable.
Question 2. How it can be fixed using Eclipse, BUT without copying all Portaudio source tree to my project?
I have pa_ringbuffer.o file somewhere in system, but no any something like pa_ringbuffer.so files.
I have compiled and running under Eclipse other PA apps which are do not use PA's ring buffer, and just
#include "portaudio.h"
and adding PA lib via PkgConfig is enough.
Thanks.
I had to add those 3 files to source code as well as main.c , then it compiled.
I use Code Block, Mingw c compiler
/portaudio/src/common/pa_allocation.c
/portaudio/src/common/pa_ringbuffer.c
/portaudio/src/os/win/pa_win_util.c
code block IDE view of 3 files added
Please have a look into the portaudio.git :
cd portaudio/
find . -name pa_ringbuffer.h
The reply is : ./src/common/pa_ringbuffer.h
... so you will have to copy the header to a location, where it can be found. But : Do not expect to compile a single file → often not possible with a complex application. I.e. the setup is meant for compiling the complete portaudio/.
I'm downloading on open source Linux tool and trying to build it.
The build guide says that I need to work in a separate prefix to avoid corrupting the system. For that I have created a my_prefix dir and written a setup-env file in it, its as follows : setup-env
PROJECT=~/my_prefix
export PATH=$PROJECT/install/bin:$PATH
export LD_LIBRARY_PATH=$PROJECT/install/lib:$PATH
export PKG_CONFIG_PATH=$PROJECT/install/lib/pkgconfig:$PKG_CONFIG_PATH
export AC_LOCAL_FLAGS="-I $PROJECT/install/share/aclocal $ACLOCAL_FLAG"
After this I do source setup-env
Now whenever I install a new tool using, sudo apt-get install, it should go into my new install dir, but its getting updated in /usr/bin only.
Any idea what could be the reason?
My OS (Ubuntu 12.04) comes with a pre-packaged Qt4 libraries and other relevant stuffs. But I wanted to use the latest vanilla Qt 5.2.1, I have installed it and it's working fine, suppose I have compiled this framework which depends on Qt.
What I had to do is to add the Qt 5.2.1 libraries to the $LD_LIBRARY_PATH. My Qt 5.2.1 home path is /opt/Qt5.2.1/5.2.1/gcc_64, and thus my $LD_LIBRARY_PATH contains /opt/Qt5.2.1/5.2.1/gcc_64/lib (and /opt/Qt5.2.1/Tools/QtCreator/lib for qtcreator related stuffs)
However, recently I am trying to compile the latest gnu octave. It's configure script looks for the Qt cflags (i.e. -l/-I/-L flags) by invoking the pkg-config.
What I came to know that pkg-config looks for the appropriate .pc files to get the exact information related to all compilation/linking flags. My system (Ubuntu) maintains a list of all required .pc file locations in /var/lib/dpkg/info/pkg-config.list. But I do not have any $PKG_CONFIG_PATH environment variable on Ubuntu 12.04 (I am not sure why).
My newly installed Qt5 has a set of .pc files in /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/.
So, how do I make pkg-config to recognize the development libraries in the newly installed Qt 5.2.1 ?
I know that this could be solved by just installing the Qt4 -dev packages from the Ubuntu repo, but I do not want to do that. I need the vanilla Qt 5.2.1 for other purposes.
NOTE:
I have added the the path /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/ to the pkg-config.list but the pkg-config does not update the compilation flags accordingly.
Adding the path (/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/) to $PKG_CONFIG_PATH does not work as well.
Here is the octave configure script output.
This problem is because Octave is searching for QtCore.pc, QtGUI.pc, and QtNetwork.pc but Qt5 seems to have renamed them as Qt5Core.pc, Qt5GUI.pc, and Qt5Network.pc. One solution is to create symlinks for them:
cd /opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
ln -s ./Qt5Core.pc ./QtCore.pc
ln -s ./Qt5GUI.pc ./QtGUI.pc
ln -s ./Qt5Network.pc ./QtNetwork.pc
cd octave_build_dir
export $PKG_CONFIG_PATH="/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/"
./configure # with fingers crossed
I am unsure of the why the reason of name change. I wonder if there should be some sort of mechanism in place where the unversion versions would be in the $PKG_CONFIG_PATH, and changing your preferences would change the link to correct version.
Finally, your config.log and config.status would have been more useful than just the output of configure. The mentioned files will have the actual commands and output of your configure.
The carandraug's answer is correct, but I didn't need to symlink .pc files(Qt 5.9.5). To prevent removing other pkg-config addresses, export PKG_CONFIG_PATH like below:
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
And to execute it at startup and systemwide(no need to export in every terminal session), put these lines at the bottom line in ".bashrc":
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/Qt5.2.1/5.2.1/gcc_64/lib/pkgconfig/
export PKG_CONFIG_PATH