How do I install numpy on a linux cluster? [closed] - numpy

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I am a user (who is also rather new to this stuff) on a shared linux (RHEL 4) cluster and I am trying to install numpy. The cluster actually does come with it installed, but it uses Python version 2.3 and pretty much all of my scripts only work with Python 2.7. So I downloaded numpy-1.6.1, un-tar'ed it, and ran the setup and got the following (see below). I've also tried the "install" rather the build argument but this doesn't work either. I've been trying for hours to get this to work so I'd really appreciate the help. Any thoughts?
$ Python-2.7.2/python setup.py build --fcompiler=gfortran
Running from numpy source directory.non-existing path in
'numpy/distutils': 'site.cfg' F2PY Version 2 blas_opt_info:
blas_mkl_info: libraries mkl,vml,guide not found in /usr/local/lib64
libraries mkl,vml,guide not found in /usr/local/lib libraries
mkl,vml,guide not found in /usr/lib64 libraries mkl,vml,guide not
found in /usr/lib NOT AVAILABLE
atlas_blas_threads_info: Setting PTATLAS=ATLAS libraries
ptf77blas,ptcblas,atlas not found in /usr/local/lib64 libraries
ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries
ptf77blas,ptcblas,atlas not found in /usr/lib64 libraries
ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 libraries
ptf77blas,ptcblas,atlas not found in /usr/lib NOT AVAILABLE
atlas_blas_info: libraries f77blas,cblas,atlas not found in
/usr/local/lib64 libraries f77blas,cblas,atlas not found in
/usr/local/lib customize GnuFCompiler Found executable /usr/bin/g77
gnu: no Fortran 90 compiler found gnu: no Fortran 90 compiler found
customize GnuFCompiler gnu: no Fortran 90 compiler found gnu: no
Fortran 90 compiler found customize GnuFCompiler using config
compiling '_configtest.c':
/* This file is generated from numpy/distutils/system_info.py */ void
ATL_buildinfo(void); int main(void) { ATL_buildinfo(); return 0; }
C compiler: /usr/bin/gcc4 -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-c' gcc4: _configtest.c /usr/bin/gcc4 _configtest.o
-L/usr/lib64 -lf77blas -lcblas -latlas -o _configtest ATLAS version 3.7.11 built by root on Mon Jun 5 10:14:12 EDT 2006: UNAME : Linux intel1.lsf.platform.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24
16:56:28 EST 2006 x86_64 x86_64 x86_64 GNU/Linux INSTFLG :
MMDEF :
/export/madison/src/roll/hpc/BUILD/ATLAS/CONFIG/ARCHS/P4E64SSE3/gcc/gemm
ARCHDEF :
/export/madison/src/roll/hpc/BUILD/ATLAS/CONFIG/ARCHS/P4E64SSE3/gcc/misc
F2CDEFS : -DAdd__ -DStringSunStyle CACHEEDGE: 393216 F77 :
/usr/bin/g77, version GNU Fortran (GCC) 3.4.5 20051201 (Red Hat
3.4.5-2) F77FLAGS : -fomit-frame-pointer -O -m64 CC : /usr/bin/gcc, version gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2) CC
FLAGS : -fomit-frame-pointer -O3 -funroll-all-loops -m64 MCC :
/usr/bin/gcc, version gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
MCCFLAGS : -fomit-frame-pointer -O -m64 success! removing:
_configtest.c _configtest.o _configtest FOUND:
libraries = ['f77blas', 'cblas', 'atlas']
library_dirs = ['/usr/lib64']
language = c
define_macros = [('ATLAS_INFO', '"\"3.7.11\""')]
FOUND:
libraries = ['f77blas', 'cblas', 'atlas']
library_dirs = ['/usr/lib64']
language = c
define_macros = [('ATLAS_INFO', '"\"3.7.11\""')]
lapack_opt_info: lapack_mkl_info: mkl_info: libraries mkl,vml,guide
not found in /usr/local/lib64 libraries mkl,vml,guide not found in
/usr/local/lib libraries mkl,vml,guide not found in /usr/lib64
libraries mkl,vml,guide not found in /usr/lib NOT AVAILABLE
NOT AVAILABLE
atlas_threads_info: Setting PTATLAS=ATLAS libraries
ptf77blas,ptcblas,atlas not found in /usr/local/lib64 libraries
lapack_atlas not found in /usr/local/lib64 libraries
ptf77blas,ptcblas,atlas not found in /usr/local/lib libraries
lapack_atlas not found in /usr/local/lib libraries
ptf77blas,ptcblas,atlas not found in /usr/lib64 libraries
lapack_atlas not found in /usr/lib64 libraries
ptf77blas,ptcblas,atlas not found in /usr/lib/sse2 libraries
lapack_atlas not found in /usr/lib/sse2 libraries
ptf77blas,ptcblas,atlas not found in /usr/lib libraries lapack_atlas
not found in /usr/lib numpy.distutils.system_info.atlas_threads_info
NOT AVAILABLE
atlas_info: libraries f77blas,cblas,atlas not found in
/usr/local/lib64 libraries lapack_atlas not found in
/usr/local/lib64 libraries f77blas,cblas,atlas not found in
/usr/local/lib libraries lapack_atlas not found in /usr/local/lib
libraries lapack_atlas not found in /usr/lib64
numpy.distutils.system_info.atlas_info FOUND:
libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
library_dirs = ['/usr/lib64']
language = f77
define_macros = [('ATLAS_INFO', '"\"3.7.11\""')]
FOUND:
libraries = ['lapack', 'f77blas', 'cblas', 'atlas']
library_dirs = ['/usr/lib64']
language = f77
define_macros = [('ATLAS_INFO', '"\"3.7.11\""')]
running build running config_cc unifing config_cc, config, build_clib,
build_ext, build commands --compiler options running config_fc unifing
config_fc, config, build_clib, build_ext, build commands --fcompiler
options running build_src build_src building py_modules sources
building library "npymath" sources customize Gnu95FCompiler Found
executable /usr/bin/gfortran customize Gnu95FCompiler using config C
compiler: /usr/bin/gcc4 -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-Inumpy/core/src/private -Inumpy/core/src
-Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/scratch/groups/crabtree/Python-2.7.2/Include -I/scratch/groups/crabtree/Python-2.7.2 -c' gcc4: _configtest.c /usr/bin/gcc4 _configtest.o -o _configtest success! removing:
_configtest.c _configtest.o _configtest C compiler: /usr/bin/gcc4 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-Inumpy/core/src/private -Inumpy/core/src
-Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/scratch/groups/crabtree/Python-2.7.2/Include -I/scratch/groups/crabtree/Python-2.7.2 -c' gcc4: _configtest.c
_configtest.c:1: warning: conflicting types for built-in function 'exp' /usr/bin/gcc4 _configtest.o -o _configtest
_configtest.o(.text+0x5): In function main': /scratch/groups/crabtree/numpy-1.6.1/_configtest.c:6: undefined
reference toexp' collect2: ld returned 1 exit status
_configtest.o(.text+0x5): In function main': /scratch/groups/crabtree/numpy-1.6.1/_configtest.c:6: undefined
reference toexp' collect2: ld returned 1 exit status failure.
removing: _configtest.c _configtest.o C compiler: /usr/bin/gcc4
-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-Inumpy/core/src/private -Inumpy/core/src
-Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/scratch/groups/crabtree/Python-2.7.2/Include -I/scratch/groups/crabtree/Python-2.7.2 -c' gcc4: _configtest.c
_configtest.c:1: warning: conflicting types for built-in function 'exp' /usr/bin/gcc4 _configtest.o -lm -o _configtest success!
removing: _configtest.c _configtest.o _configtest building extension
"numpy.core._sort" sources adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to
sources. adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
to sources. executing numpy/core/code_generators/generate_numpy_api.py
adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h'
to sources. numpy.core - nothing done with h_files =
['build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h']
building extension "numpy.core.multiarray" sources adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to
sources. adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
to sources. executing numpy/core/code_generators/generate_numpy_api.py
adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h'
to sources. numpy.core - nothing done with h_files =
['build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h']
building extension "numpy.core.umath" sources adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to
sources. adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
to sources. executing numpy/core/code_generators/generate_ufunc_api.py
adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h' to
sources. adding 'build/src.linux-x86_64-2.7/numpy/core/src/umath' to
include_dirs. numpy.core - nothing done with h_files =
['build/src.linux-x86_64-2.7/numpy/core/src/umath/funcs.inc',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h']
building extension "numpy.core.scalarmath" sources adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h' to
sources. adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h'
to sources. executing numpy/core/code_generators/generate_numpy_api.py
adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h'
to sources. executing numpy/core/code_generators/generate_ufunc_api.py
adding
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h' to
sources. numpy.core - nothing done with h_files =
['build/src.linux-x86_64-2.7/numpy/core/include/numpy/config.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/_numpyconfig.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__multiarray_api.h',
'build/src.linux-x86_64-2.7/numpy/core/include/numpy/__ufunc_api.h']
building extension "numpy.core._dotblas" sources adding
'numpy/core/blasdot/_dotblas.c' to sources. building extension
"numpy.core.umath_tests" sources building extension
"numpy.core.multiarray_tests" sources building extension
"numpy.lib._compiled_base" sources building extension
"numpy.numarray._capi" sources building extension
"numpy.fft.fftpack_lite" sources building extension
"numpy.linalg.lapack_lite" sources adding
'numpy/linalg/lapack_litemodule.c' to sources. adding
'numpy/linalg/python_xerbla.c' to sources. building extension
"numpy.random.mtrand" sources C compiler: /usr/bin/gcc4
-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-Inumpy/core/src/private -Inumpy/core/src
-Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/scratch/groups/crabtree/Python-2.7.2/Include -I/scratch/groups/crabtree/Python-2.7.2 -c' gcc4: _configtest.c /usr/bin/gcc4 _configtest.o -o _configtest
_configtest failure. removing: _configtest.c _configtest.o _configtest building data_files sources build_src: building npy-pkg config files
running build_py copying numpy/version.py ->
build/lib.linux-x86_64-2.7/numpy copying numpy/config.py ->
build/lib.linux-x86_64-2.7/numpy copying
build/src.linux-x86_64-2.7/numpy/config.py ->
build/lib.linux-x86_64-2.7/numpy copying numpy/distutils/config.py
-> build/lib.linux-x86_64-2.7/numpy/distutils copying build/src.linux-x86_64-2.7/numpy/distutils/config.py ->
build/lib.linux-x86_64-2.7/numpy/distutils running build_clib
customize UnixCCompiler customize UnixCCompiler using build_clib
running build_ext customize UnixCCompiler customize UnixCCompiler
using build_ext customize Gnu95FCompiler customize Gnu95FCompiler
using build_ext building 'numpy.core._dotblas' extension compiling C
sources C compiler: /usr/bin/gcc4 -fno-strict-aliasing -g -O2 -DNDEBUG
-g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC
compile options: '-DATLAS_INFO="\"3.7.11\"" -Inumpy/core/blasdot
-Inumpy/core/include -Ibuild/src.linux-x86_64-2.7/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/scratch/groups/crabtree/Python-2.7.2/Include -I/scratch/groups/crabtree/Python-2.7.2 -Ibuild/src.linux-x86_64-2.7/numpy/core/src/multiarray -Ibuild/src.linux-x86_64-2.7/numpy/core/src/umath -c' gcc4: numpy/core/blasdot/_dotblas.c numpy/core/blasdot/_dotblas.c: In
function 'dotblas_matrixproduct': numpy/core/blasdot/_dotblas.c:239:
warning: comparison of distinct pointer types lacks a cast
numpy/core/blasdot/_dotblas.c:257: warning: passing argument 3 of
'*(PyArray_API + 2240u)' from incompatible pointer type
numpy/core/blasdot/_dotblas.c:292: warning: passing argument 3 of
'*(PyArray_API + 2240u)' from incompatible pointer type gcc -pthread
-shared build/temp.linux-x86_64-2.7/numpy/core/blasdot/_dotblas.o -L/usr/lib64 -Lbuild/temp.linux-x86_64-2.7 -lf77blas -lcblas -latlas -o build/lib.linux-x86_64-2.7/numpy/core/_dotblas.so /usr/bin/ld: /usr/lib64/libcblas.a(cblas_dgemm.o): relocation R_X86_64_32 against
a local symbol' can not be used when making a shared object;
recompile with -fPIC /usr/lib64/libcblas.a: could not read symbols:
Bad value collect2: ld returned 1 exit status /usr/bin/ld:
/usr/lib64/libcblas.a(cblas_dgemm.o): relocation R_X86_64_32 against
a local symbol' can not be used when making a shared object;
recompile with -fPIC /usr/lib64/libcblas.a: could not read symbols:
Bad value collect2: ld returned 1 exit status error: Command "gcc
-pthread -shared build/temp.linux-x86_64-2.7/numpy/core/blasdot/_dotblas.o -L/usr/lib64
-Lbuild/temp.linux-x86_64-2.7 -lf77blas -lcblas -latlas -o build/lib.linux-x86_64-2.7/numpy/core/_dotblas.so" failed with exit
status 1

I had LOTS of compatibilty problems between python 2.7 and the various versions of numpy, scipy, matplotlib ... that I had to install. Finally, the good option was to use (under ubuntu) the apt-get utility, to be sure to have the versions compatible between all them packages.
Now, when reading your log, I see that you do not have LAPACK installed. See the BLAS and/or ATLAS packages to have this first. You also need a fortran compiler to be installed previously. And also the python2.7-dev package which contains the needed headers and statics.
So, the procedure I would follow in your case is as follows :
What is the GCC version you have ?
louis#APS007:~$ gcc -v
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
Check that you have a gcc version 4 at least (able to deal with 64 bit floats as numpy needs them) or update your O.S. Carefull ! Updating the GCC is NOT an innocent package tuning...
Install a Fortran compiler.
Eventually install the LAPACK library. It will seriously speed up the numpy by pre-compiling most of its routines and tuning them for your CPU.
Install python-dev
Then you may python setup build.
Hope this was helpfull !

Related

NDK 25 Did not add optimized level in Build Type Release with CMake

I'm working on a shared library with CMake. Today I try to build it with NDK 25. when build type is "DEBUG", cmake add -O0 in CXX_FLAGS, and it add "-O2" in "RELWITHDEBINFO" build type. but when I changed it to "RELEASE", no optimize level was set.
I looked into the files that CMake generated. I found this in "CMakeCache.txt":
//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=
//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=
//Flags used by the CXX compiler during MINSIZEREL builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG
//Flags used by the compiler during release builds.
CMAKE_CXX_FLAGS_RELEASE:STRING=
//Flags used by the CXX compiler during RELWITHDEBINFO builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g -DNDEBUG
//Libraries linked by default with all C++ applications.
CMAKE_CXX_STANDARD_LIBRARIES:STRING=-latomic -lm
I found "CMAKE_CXX_FLAGS_RELEASE:STRING" is empty, that's why optimize level is not set when buildding "RELEASE".
This is my shell script to run the cmake:
NDK_PATH="~/Library/Android/sdk/ndk/25.0.8775105"
rm -rf buildV7
mkdir buildV7
cd buildV7
../../../../CMake/Mac/CMake.app/Contents/bin/cmake ..
-DANDROID_ABI=armeabi-v7a
-DANDROID_PLATFORM=android-23
-DANDROID_NDK=$NDK_PATH
-DCMAKE_BUILD_TYPE=RELEASE
-DCMAKE_TOOLCHAIN_FILE=$NDK_PATH/build/cmake/android.toolchain.cmake
make VERBOSE=1
cd ..
the final clang command is:
Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=armv7-none-linux-androideabi23 --sysroot=Android/sdk/ndk/25.0.8775105/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -DBianqueLogger_EXPORTS -I/Users/TestProj/build/android/dynamicLib/../../../src -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -march=armv7-a -mthumb -Wformat -Werror=format-security -DNDEBUG -fPIC -std=gnu++11 -MD -MT CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o -MF CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o.d -o CMakeFiles/BianqueLogger.dir/Users/TestProj/src/utils/head.cpp.o -c /Users/TestProj/src/utils/head.cpp
Is This NDK's BUG? Or -O3 is no longer needed in NDK25 and it's clang toolchain?
https://github.com/android/ndk/issues/1740. Will be fixed in r25b.
But typically you don't want to use Release for Android, you want to use RelWithDebInfo or MinSizeRel (it's really unfortunate that cmake doesn't have a MinSizeRelWithDebInfo). Your packaging tools should be stripping any libraries before packing them into an APK, so there is no reason to avoid compiling debug info. All that does is make it so you can't debug.
"Release" - there is no such config by default in NDK since r23. The default configs are: "Debug", "MinSizeRel" and "RelWithDebInfo". Use one of these three.

Meson / Freetype / Harfbuzz : making Harfbuzz's meson script find freetype in /opt

I am trying to build freetype and harfbuzz. The latter depends on the former. Freetype builds with CMake, which I configured to install it in /opt/ossia-sdk.
I tried this as mentioned in Meson: how to make find_library() works with an unusual path? :
export LIBRARY_PATH=/opt/ossia-sdk/freetype
# also tried:
# export LIBRARY_PATH=/opt/ossia-sdk/freetype/lib
meson build -Dbuildtype=release -Ddefault_library=static -Dglib=disabled -Dgobject=disabled -Dicu=disabled -Ddocs=disabled -Dprefix=/opt/ossia-sdk/harfbuzz
Yet it still gets my system freetype, which I do not want.
meson-log.txt has the following:
libraries: =/opt/ossia-sdk/freetype/x86_64-pc-linux-gnu/11.1.0/:/opt/ossia-sdk/freetype/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/:/lib/x86_64-pc-linux-gnu/11.1.0/:/lib/../lib/:/usr/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/../lib/:/opt/ossia-sdk/freetype/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
Build lines look like:
Command line: c++ -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/testfile.cpp -o /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/output.exe -pthread -O3 -march=x86-64 -mtune=generic -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -std=c++11 -fno-rtti -Wl,--start-group /usr/lib/libfreetype.so -Wl,--end-group
Any solution must not patch Freetype or harfbuzz's build scripts, I can only call them.

Why Autotools Ignores Installed Static Library?

I have installed ROHC library (http://rohc-lib.org) using following commands during installation:
autoreconf -if
./configure --enable-static=yes --enable-shared=no --disable-shared --prefix=/usr
make
make install
It successfully installed static (and only static) libraries in /usr/lib directory. It contains librohc.a and librohc.la and no shared-library (i.e. librohc.so*).
I am trying to link this library with OpenVPN. I added following lines in configure.ac of OpenVPN:
AC_CHECK_HEADERS(
[rohc/rohc.h rohc/rohc_comp.h rohc/rohc_decomp.h],
,
[AC_MSG_ERROR([ROHC headers not found])]
)
AC_CHECK_LIB(
[rohc],
[rohc_compress4],
,
[AC_MSG_ERROR([ROHC library not found])]
)
But when I run make in OpenVPN source directory, I get the following error:
/bin/sh ../../libtool --tag=CC --mode=link gcc -DPLUGIN_LIBDIR=\"/usr/local/lib/openvpn/plugins\" -Wall -Wno-unused-parameter -Wno-unused-function -g -O2 -std=c99 -lrt -o openvpn argv.o base64.o buffer.o clinat.o comp.o compstub.o comp-lz4.o crypto.o crypto_openssl.o crypto_mbedtls.o dhcp.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o httpdigest.o lladdr.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o platform.o console.o console_builtin.o console_systemd.o mroute.o mss.o mstats.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o pkcs11.o pkcs11_openssl.o pkcs11_mbedtls.o openvpn.o options.o otime.o packet_id.o perf.o pf.o ping.o plugin.o pool.o proto.o proxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o ssl_openssl.o ssl_mbedtls.o ssl_verify.o ssl_verify_openssl.o ssl_verify_mbedtls.o status.o tls_crypt.o tun.o win32.o rohc.o trunk.o cryptoapi.o ../../src/compat/libcompat.la -lnsl -lresolv -llzo2 -llz4 -lssl -lcrypto -ldl -lrohc
libtool: link: gcc -DPLUGIN_LIBDIR=\"/usr/local/lib/openvpn/plugins\" -Wall -Wno-unused-parameter -Wno-unused-function -g -O2 -std=c99 -o openvpn argv.o base64.o buffer.o clinat.o comp.o compstub.o comp-lz4.o crypto.o crypto_openssl.o crypto_mbedtls.o dhcp.o error.o event.o fdmisc.o forward.o fragment.o gremlin.o helper.o httpdigest.o lladdr.o init.o interval.o list.o lzo.o manage.o mbuf.o misc.o platform.o console.o console_builtin.o console_systemd.o mroute.o mss.o mstats.o mtcp.o mtu.o mudp.o multi.o ntlm.o occ.o pkcs11.o pkcs11_openssl.o pkcs11_mbedtls.o openvpn.o options.o otime.o packet_id.o perf.o pf.o ping.o plugin.o pool.o proto.o proxy.o ps.o push.o reliable.o route.o schedule.o session_id.o shaper.o sig.o socket.o socks.o ssl.o ssl_openssl.o ssl_mbedtls.o ssl_verify.o ssl_verify_openssl.o ssl_verify_mbedtls.o status.o tls_crypt.o tun.o win32.o rohc.o trunk.o cryptoapi.o ../../src/compat/.libs/libcompat.a -lrt -lnsl -lresolv -llzo2 -llz4 -lssl -lcrypto -ldl /usr/lib/librohc.so
gcc: /usr/lib/librohc.so: No such file or directory
Yes, /usr/lib/librohc.so does not exist, but /usr/lib/librohc.a exists. Why is it not linking with the static library /usr/lib/librohc.a at absence of .so ?
You may ask me why I am not installing shared libs of ROHC; answer is that I want to force static linking with ROHC, and when it is done I will uninstall ROHC libs.
If someone could show me how to do this static linking without installing ROHC first (like adding dependency to configure.ac or Makefile.am of OpenVPN), it would be better for me.
Note that, both OpenVPN and ROHC library require autotools.
I specified --libdir=/usr/lib64 with ./configure of ROHC library and finally the build system used the static library librohc.a when linking with OpenVPN. I installed ROHC with:
autoreconf -if
./configure --enable-static --disable-shared --prefix=/usr --libdir=/usr/lib64
make
make install
Now it installs the library as /usr/lib64/librohc.a and Compilation of OpenVPN successfully finds and links to it.
And surely, it took place in a 64 bit machine (CentOS 6). In a 32 bit environment (OpenWrt in a 32-bit MIPS router) where there is nothing like /usr/lib64, the problem in the question does not take place.

Changed include path behaviour from CMake 2.8.x to 3.9.x

I have a fairly large cmake project that exhibits a compiler error when I use Makefiles generated by CMake 3.9.x:
Scanning dependencies of target client
[ 21%] Building C object
src/lib/client/CMakeFiles/client.dir/client.c.o
In file included from <command-line>:0:0:
/usr/include/stdc-predef.h:40:1: fatal error: compiler.h: No such file or directory
#endif
^
This works properly when using Makefiles generated by CMake 2.8.x. Digging in a bit, I can see that a change was made to the flags.make file generated by CMake between these two versions. The older version used to put -I (include) options in the C_FLAGS variable defined in that file:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8
# compile C with /usr/lib64/ccache/cc
C_FLAGS = -Wall -Wextra -Werror -Wformat=2 -Wundef -mcx16 -Werror-implicit-function-declaration -Wno-unused-parameter -D_GNU_SOURCE -include compiler.h -D__BUG_OUT_AUX=pd_trc_ftl -Wstrict-prototypes -Wdeclaration-after-statement -Wno-tautological-compare -g -I/.../src/lib/client ... -fPIC
C_DEFINES = -DBUILD_NUMBER=\"whatever\" -DBUILD_VERSION=\"1.66.0\" -DCOMMIT_HASH=\"f9bf1c93682f\" -DPDDEBUG -D_FILE_OFFSET_BITS=64
In later versions of CMake the -I options are broken out into their own C_INCLUDES variable:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.9
# compile C with /usr/lib64/ccache/cc
C_FLAGS = -Wall -Wextra -Werror -Wformat=2 -Wundef -mcx16 -Werror-implicit-function-declaration -Wno-unused-parameter -D_GNU_SOURCE -include compiler.h -D__BUG_OUT_AUX=pd_trc_ftl -Wstrict-prototypes -Wdeclaration-after-statement -Wno-tautological-compare -g -fPIC
C_DEFINES = -DBUILD_NUMBER=\"whatever\" -DBUILD_VERSION=\"1.66.0\" -DCOMMIT_HASH=\"f9bf1c93682f\" -DPDDEBUG -D_FILE_OFFSET_BITS=64
C_INCLUDES = -I/.../src/lib/client ...
However, in both cases, the including file - build.make - uses only the $(C_DEFINES) $(C_FLAGS), omitting the $(C_INCLUDES) in the newer model:
...
# Include the compile flags for this target's objects.
include src/lib/client/CMakeFiles/client.dir/flags.make
src/lib/client/CMakeFiles/client.dir/client.c.o: src/lib/client/CMakeFiles/client.dir/flags.make
src/lib/client/CMakeFiles/client.dir/client.c.o: ../src/lib/client/client.c
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/.../cmake-build-debug/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building C object src/lib/client/CMakeFiles/client.dir/client.c.o"
cd /.../cmake-build-debug/src/lib/client && /.../contrib/cc/cgcc.sh /.../cmake-build-debug /usr/lib64/ccache/cc sparse ON /.../client-project CMakeFiles/client.dir/client.c.o $(C_DEFINES) $(C_FLAGS) -o CMakeFiles/client.dir/client.c.o -c /.../src/lib/client/client.c
...
Is this a bug in CMake 3.9.x? Has anyone else experienced anything like this when upgrading CMake?
I believe it's possible that we've always done something wrong in our CMakeLists.txt files that just happened to work in the older versions, but that when we upgraded to CMake 3.9.x, suddenly the problem is manifest. Hoping someone has had this issue and figured out what they did wrong.
Thanks in advance!

CMake on Cygwin with clang not creating expected dll.a

I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.