I have a project that I am working on converting over to autotools.
Here are the relevant files
configure.ac
AC_INIT([opengl-es-demo], [1])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_LANG(C++)
AC_PROG_CXX
PKG_CHECK_MODULES(LIBPNG, libpng >= 1.6.34)
PKG_CHECK_MODULES(FREETYPE2, freetype2 >= 21.0.15)
PKG_CHECK_MODULES(EGL, egl > 0)
PKG_CHECK_MODULES(GLES2, glesv2 > 0)
PKG_CHECK_MODULES(PTHREAD, pthread-stubs > 0)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
Makefile.am
bin_PROGRAMS = main
main_SOURCES = main.cpp eglManager.cpp shaderManager.cpp imageUtils.cpp freetypeUtils.cpp texture.cpp shader.cpp camera.cpp
main_CPPFLAGS = $(FREETYPE2_CFLAGS) $(LIBPNG_CFLAGS) $(EGL_CFLAGS) $(GLES2_CFLAGS) $(PTHREAD_CFLAGS)
main_LDFLAGS = $(FREETYPE2_LIBS) $(LIBPNG_LIBS) $(EGL_LIBS) $(GLES2_LIBS) $(PTHREAD_LIBS)
The linker calls this step...
g++ -g -O2 -lfreetype -lpng16 -lz -lEGL -lGLESv2 -o main main-main.o main-eglManager.o main-shaderManager.o main-imageUtils.o main-freetypeUtils.o main-texture.o main-shader.o main-camera.o
...and then fails with a bunch of undefined reference errors to functions found in OpenGL(-GLESv2), png(-lpng16), and freetype(-lfreetype) libraries.
It compiled fine when I wasn't using autotools (only a makefile) so I know the problem is with my autotools usage.
Where did I mess up the configuration?
Changing main_LDFLAGS to main_LDADD solved the problem.
Correcting the GCC command line ordering using Automake
Related
I wrote some C++ files to create a shared library, and here is my Makefile
PYTHON_VERSION = 3.6
PYTHON_HOME_PATH = /Library/Frameworks/Python.framework/Versions
PYTHON_INCLUDE = $(PYTHON_HOME_PATH)/$(PYTHON_VERSION)
BOOST_INC = /usr/local/Cellar/boost/1.67.0_1/include
BOOST_LIB = /usr/local/Cellar/boost/1.67.0_1/lib
BOOST_PYTHON_LIB = /usr/local/Cellar/boost-python3/1.67.0_1/lib/
TARGET = main
EXTEND_FILE = main_ext
$(TARGET).so:$(TARGET).o
g++ -shared depend.o -L$(BOOST_LIB) -L$(BOOST_PYTHON_LIB) -lboost_python3 `python3.6m-config --libs --ldflags` -o depend_ext.so
g++ -shared depend.o $(TARGET).o -L$(BOOST_LIB) -L$(BOOST_PYTHON_LIB) -lboost_python3 `python3.6m-config --libs --ldflags` -o $(TARGET).so
mv $(TARGET).so $(EXTEND_FILE).so
depend.o:depend.cpp
g++ `python3.6m-config --include` -fPIC -c depend.cpp -O3 -std=c++11
$(TARGET).o:$(TARGET).cpp
g++ `python3.6m-config --include` -fPIC -c depend.cpp $(TARGET).cpp -O3 -std=c++11
clean:
rm *.so *.o
The Makefile can generate the .so file. And my CMakeLists.txt is
cmake_minimum_required(VERSION 3.8)
project(Simulator)
set(CMAKE_CXX_STANDARD 11)
set(SOURCE_FILES depend.cpp depend.h main.cpp main.h)
add_executable(Simulator ${SOURCE_FILES})
set(Boost_INCLUDE_DIRS /usr/local/Cellar/boost/1.67.0_1/include)
set(Boost_LIBRARIES /usr/local/Cellar/boost/1.67.0_1/lib)
set(BOOST_PYTHON_LIB /usr/local/Cellar/boost-python3/1.67.0_1/lib/)
find_package(Boost COMPONENTS filesystem system date_time python REQUIRED)
message("--> Include dirs of boost: " ${Boost_INCLUDE_DIRS} )
message("--> Libs of boost: " ${Boost_LIBRARIES} )
find_package(PythonLibs 3.6 REQUIRED)
message("--> Include dirs of Python: " ${PYTHON_INCLUDE_DIRS} )
message("--> Libs of Python: " ${PYTHON_LIBRARIES} )
include_directories(
${Boost_INCLUDE_DIRS}
${PYTHON_INCLUDE_DIRS}
)
target_link_libraries(Simulator
${Boost_LIBRARIES}
${PYTHON_LIBRARIES}
${BOOST_PYTHON_LIB}
)
But running CMake gives the following errors
CMake Error at /usr/local/Cellar/cmake/3.10.2/share/cmake/Modules/FindBoost.cmake:1928 (message):
Unable to find the requested Boost libraries.
Boost version: 1.67.0
Boost include path: /usr/local/include
Could not find the following Boost libraries:
boost_python3
I want to build it with Python3 and I have already install boost.python3. How can I fix it?
I think the problem is that Homebrew installs boost_python under a separate directory (i.e. /usr/local/Cellar/boost-python3/1.67.0_1/) which is different from the rest of the Boost installation (i.e. /usr/local/Cellar/boost/1.67.0_1).
I'm not on a Mac, thus I'm not exactly certain of the actual directory structure and how much can be done with symlinks (symlinking the Boost Python component directories back into the main Boost installation dir).
So, I built and installed (on Ubuntu Linux) from source the latest Boost version (1.68) using
./bootstrap.sh --prefix=/bulk/workbench/boost/install --with-python=python3
All components ended up under the include and lib directories in /bulk/workbench/boost/install. Providing that during CMake configuration as in
cmake -DBoost_ROOT=/bulk/workbench/boost/install [path-to-my-project-source-dir]
and using this in my CMakeLists.txt
find_package(Boost COMPONENTS python REQUIRED)
it was able to find my boost_python module.
Basically, unless you're able to twist the Homebrew installation, it might be more straightforward to build your own Boost.
I am trying to compile my code using mpi on my macbook but I get the following error:
"ld: library not found for -lblacsF77init". I don't understand where I can find this library and how to create a correct path.
This is the makefile: # serial Fortran compiler program
F90 = gfortran -I/usr/local/include
# parallel Fortran compiler program
MPIF90 = /usr/local/bin/mpif90.
# Compiler flags
F90FLAGS =
CFLAGS = -x f95-cpp-input.
# LDFLAGS are the linker flags
LDFLAGS = -L/usr/local/lib
F77LIBS =.
MATLIB = -framework Accelerate
hsl = /usr/local/opt/scalapack/
hb = /usr/local/opt/openblas/
hompi = /usr/local/lib/openmpi/
MPIMATLIB = -L$(hb) -L$(hsl) -lscalapack -L$(hsl) -lblacsF77init -
lblacs -lblacsF77init -L$(hompi) -Wl,-framework,vecLib
Thank you very much for any help you may provide.
If you are on a macbook running OSX, you don't need to build scalapack:
brew install scalapack gcc
I'm been attempting to compile an open-source C++ library (QuantLib-1.7) on my mac for several days but I seem to be encountering some kind of C++11 compatibility issue.
When I run make && sudo make install from the terminal the compilation seems to work except for a bunch of errors of the form
Making all in BermudanSwaption
g++ -DHAVE_CONFIG_H -I. -I../../ql -I../.. -I../.. -I/opt/local/include -g -O2 -MT BermudanSwaption.o -MD -MP -MF .deps/BermudanSwaption.Tpo -c -o BermudanSwaption.o BermudanSwaption.cpp
In file included from BermudanSwaption.cpp:22:
In file included from ../../ql/quantlib.hpp:43:
In file included from ../../ql/experimental/all.hpp:25:
In file included from ../../ql/experimental/volatility/all.hpp:21:
In file included from ../../ql/experimental/volatility/zabr.hpp:31:
In file included from ../../ql/math/statistics/incrementalstatistics.hpp:35:
In file included from /opt/local/include/boost/accumulators/statistics/stats.hpp:14:
In file included from /opt/local/include/boost/accumulators/statistics_fwd.hpp:12:
/opt/local/include/boost/mpl/print.hpp:50:19: warning: in-class initialization
of non-static data member is a C++11 extension [-Wc++11-extensions]
const int m_x = 1 / (sizeof(T) - sizeof(T));
^
1 warning generated.
I'm guessing this has something to do with g++ not being correctly configured for C++11. I'm familiar with the fact that C++11 can be invoked by compiling with g++ -std=c++11. However, despite a lot of googling I can't find a way to modify the makefile such that -std=c++11 is called when I run make && sudo make install.
Any help would be greatly appreciated.
Here is the section of the makefile which I believe is relevant:
BOOST_INCLUDE = -I/opt/local/include
BOOST_LIB = -L/opt/local/lib
BOOST_THREAD_LIB =
BOOST_UNIT_TEST_DEFINE = -DQL_WORKING_BOOST_STREAMS
BOOST_UNIT_TEST_LIB = boost_unit_test_framework-mt
BOOST_UNIT_TEST_MAIN_CXXFLAGS = -DBOOST_TEST_DYN_LINK
CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS = -g -O2
CPP = gcc -E
CPPFLAGS = -I/opt/local/include
CXX = g++
CXXCPP = g++ -E
CXXDEPMODE = depmode=gcc3
CXXFLAGS = -g -O2
Here is the output from running "g++ -v":
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin14.5.0
Thread model: posix
Makefile.am: https://www.dropbox.com/s/v5j7qohwfup81od/Makefile.am?dl=0
Makefile.in: https://www.dropbox.com/s/t92hft9ea2ar1zw/Makefile.in?dl=0
QuantLib-1.7 directory: https://www.dropbox.com/sh/ulj0y68m8x35zg8/AAA-w7L2_YWIP8_KnwURErzYa?dl=0
Full error log: https://www.dropbox.com/s/g09lcnma8skipv7/errors.txt?dl=0
Add something like
CXXFLAGS += -std=c++11
to your Makefile. This will work regardless of the Darwin-specific munging of the g++ executable---it's really clang++.
References:
https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options
https://gcc.gnu.org/projects/cxx0x.html
http://clang.llvm.org/cxx_status.html
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html
As you already have, and are familiar with homebrew, my suggestion would be to use that to install and manage quantlib like this:
brew install quantlib
That will then build and put all the files in /usr/local/Cellar/quantlib under some version number that is not of importance. The important thing is the the tools are then linked into /usr/local/bin so all you need to do is make sure that /usr/local/bin is in your PATH.
That gives you access to the tool quantlib-config which is always linked to the latest version and it knows which version that is. So, if you run:
quantlib-config --cflags
it will tell you what the correct path is for your includes like this:
-I/usr/local/Cellar/quantlib/1.6.1/include
Likewise, if you run:
quantlib-config --libs
it will tell you the correct linking directories and libraries for your latest version.
In short, all you need to do to compile is:
g++ $(quantlib-config --cflags --libs)
and it will always pull in the version you are using.
Note that if you use a Makefile, you will need to double the dollar signs.
This is how I eventually managed to compile the Quantlib library for future reference. It is probably not the most efficient/elegant method but it appears to work.
I followed the steps given in http://quantlib.org/install/macosx.shtml and found that running make && sudo make install led to the error reported in the OP.
Create a new static library C++ project in Eclipse called 'Quantlib'
Copy the ql directory located in the .tar file to the Quantlib Eclipse workspace
Right-click Quantlib > Properties > C/C++ Build > Settings > Cross G++ Compiler: Change the Language standard to ISO C++ 11 (-std=c++0x)
Right-click Quantlib > C/C++ General > Paths and Symbols: Add the following include directories for GNU C++
opt/local/include
/Quantlib (check "Is a workspace directory")
/opt/local/include/boost.
Build the Quantlib project (around 34 min on MacBook Air 1.8 GHz Intel Core i7)
Create a new C++ executable project (e.g. BermudanSwaption) and copy the BermudanSwaption.cpp into the BermudanSwaption Eclipse workspace
Repeat steps 4. and 5. for the BermudanSwaption Eclipse project
Right-click BermudanSwaption > Properties > C/C++ General > Paths and Symbols > References: check Quantlib (the Library Paths tab should now contain the entry '/Quantlib/Debug')
Build and run the BermudanSwaption executable project
QuantLib-1.7
OSX Yosemite 10.10.5
Eclipse C/C++ Development Tools Version: 8.8.0.201509131935
Xcode Version 7.1 (7B91b)
xcode-select version 2339.
EDIT: If its TLDR, just skip to the bottom. Its where I ask: How do I configure an autotools project to use a static library?
I'm working with a couple of open source libraries, and I'm trying to run their test suite under Clang's sanitizers. To run under Clang sanitizers, we need to (1) specify some options, and (2) link static libraries from Clang's Compiler-RT as required. Note: there are no dynamic libraries or shared objects.
Setting the options is easy:
export DYLD_FALLBACK_LIBRARY_PATH=/usr/local/lib/clang/3.3/lib/darwin/
export CC=/usr/local/bin/clang
export CXX=/usr/local/bin/clang++
export CFLAGS="-g3 -fsanitize=address -fsanitize=undefined"
export CXXFLAGS="-g3 -fsanitize=address -fsanitize=undefined -fno-sanitize=vptr"
./configure
However, this will generate some archive warnings (when AR is run) and link errors (when LD is run) with undefined symbols. The message will be similar to:
libjpeg.a(jmemmgr.o): In function `do_sarray_io':
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:695: undefined reference to
`__ubsan_handle_type_mismatch'
/home/jwalton/jpeg-6b/jmemmgr.c:696: undefined reference to
`__ubsan_handle_type_mismatch'
I know the libraries that need to be linked. For the sanitizers that I use, they are libclang_rt.asan_osx.a and libclang_rt.ubsan_osx.a (or libclang_rt.full-x86_64.a and libclang_rt.ubsan-x86_64.a on Linux).
To supply the libraries, I then export the following. Note: it is LIBS, and not LDLIBS as expected by most other make related tools.
export LIBS="/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx.a \
/usr/local/lib/clang/3.3/lib/darwin/libclang_rt.ubsan_osx.a"
This results in a configure problem of:
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
...
Looking at config.log, it looks like two problems are occurring. First, the path is being butchered by changing from /usr/local/... to /Users/jwalton/.... And second, the filename is being butchered by changing from a static lib to a dynamic lib:
configure:3346: ./conftest
dyld: Library not loaded: /Users/jwalton/clang-llvm/llvm-3.3.src/Release+Asserts/lib/clang/3.3/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
Referenced from: /Users/jwalton/libpng-1.6.7/./conftest
Reason: image not found
In another attempt, I tried using LDFLAGS:
export LDFLAGS="-L/usr/local/lib/clang/3.3/lib/darwin/"
export LIBS="libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a"
That results in a similar error:
configure: error: in `/Users/jwalton/libpng-1.6.7':
configure: error: C compiler cannot create executables
And config.log:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c libclang_rt.asan_osx.a libclang_rt.ubsan_osx.a >&5
clang: error: no such file or directory: 'libclang_rt.asan_osx.a'
clang: error: no such file or directory: 'libclang_rt.ubsan_osx.a'
And dropping the lib prefix and .a suffix from the LIBS results in:
configure:3209: /usr/local/bin/clang -g3 -fsanitize=address -fsanitize=undefined -L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c clang_rt.asan_osx clang_rt.ubsan_osx >&5
clang: error: no such file or directory: 'clang_rt.asan_osx'
clang: error: no such file or directory: 'clang_rt.ubsan_osx'
And adding the -l to LIBS results in:
configure:3335: /usr/local/bin/clang -o conftest -g3 -fsanitize=address -fsanitize=undefined
-L/usr/local/lib/clang/3.3/lib/darwin/ conftest.c -lclang_rt.asan_osx -lclang_rt.ubsan_osx >&5
configure:3339: $? = 0
configure:3346: ./conftest
dyld: could not load inserted library: /Users/jwalton/libpng-1.6.7/./conftest
./configure: line 3348: 38224 Trace/BPT trap: 5 ./conftest$ac_cv_exeext
Finally, the -L argument is valid:
$ ls /usr/local/lib/clang/3.3/lib/darwin/
libclang_rt.10.4.a libclang_rt.ios.a
libclang_rt.asan_osx.a libclang_rt.osx.a
libclang_rt.asan_osx_dynamic.dylib libclang_rt.profile_ios.a
libclang_rt.cc_kext.a libclang_rt.profile_osx.a
libclang_rt.cc_kext_ios5.a libclang_rt.ubsan_osx.a
libclang_rt.eprintf.a
After all the background: how do I configure an autotools project to use a static library?
Bonus points: why has something so easy been made so difficult?
You need to add -fsanitize flags to LDFLAGS as well.
Shipping versions of GNU libtool do not pass -fsanitize=... arguments to the linker. You will need to update libtool with the patch from http://savannah.gnu.org/patch/?8775 Specifically:
diff --git a/build-aux/ltmain.in b/build-aux/ltmain.in
index 0c40da0..b99b0cd 100644
--- a/build-aux/ltmain.in
+++ b/build-aux/ltmain.in
## -5362,10 +5362,11 ## func_mode_link ()
# -O*, -g*, -flto*, -fwhopr*, -fuse-linker-plugin GCC link-time optimization
# -specs=* GCC specs files
# -stdlib=* select c++ std lib with clang
+ # -fsanitize=* Clang memory and address sanitizer
-64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*| \
-t[45]*|-txscale*|-p|-pg|--coverage|-fprofile-*|-F*|#*|-tp=*|--sysroot=*| \
-O*|-g*|-flto*|-fwhopr*|-fuse-linker-plugin|-fstack-protector*|-stdlib=*| \
- -specs=*)
+ -specs=*|-fsanitize=*)
func_quote_for_eval "$arg"
arg=$func_quote_for_eval_result
func_append compile_command " $arg"
As for getting libtool to accept a static library, you should be able to just include the full path to the static library on the command line, or you can use options like -L/usr/local/lib/clang/3.3/lib/darwin/ -lclang_rt.ubsan_osx. However, cfe should take care of the library magic for you once libtool tells it to use -fsanitize=... for linking.
As for the undefined symbol issue, if you are linking C++ objects, then you must use clang++ instead of clang. Otherwise you can get error such as:
/bin/bash libtool --tag=CC --mode=link clang-3.6 ... -fsanitize=undefined -o freeswitch ...
libtool: link: clang-3.6 ... -fsanitize=undefined -o .libs/freeswitch ./.libs/libfreeswitch.so ...
./.libs/libfreeswitch.so: undefined reference to `__ubsan_vptr_type_cache'
./.libs/libfreeswitch.so: undefined reference to `__ubsan_handle_dynamic_type_cache_miss'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
In the above case, the atrocious libtool used clang instead of clang++ because automake thought that you wanted to link a set of C objects (it does not understand that linking a libtool archive (libfreeswitch.la) using C++ means that a C++ linker is needed (note the --tag=CC). See also https://lists.debian.org/debian-mentors/2003/06/msg00004.html.
To work around this issue, follow the instructions at https://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html and add a (dummy/real) C++ source to your sources in your Makefile.am:
SUBDIRS = sub1 sub2 …
lib_LTLIBRARIES = libtop.la
libtop_la_SOURCES =
# Dummy C++ source to cause C++ linking.
nodist_EXTRA_libtop_la_SOURCES = dummy.cxx
libtop_la_LIBADD = \
sub1/libsub1.la \
sub2/libsub2.la \
…
Using Qt Creator 2.4.1 (Windows/mingw), I'm trying to compile my project dynamically linking with some Qt image plugins (i.e. the ones in C:\QtSDK\Desktop\Qt\4.8.1\mingw\plugins\imageformats\). In the .pro file:
QTPLUGIN += qjpeg qgif qico qtiff
This is the error:
g++ -Wl,-s -mthreads -Wl,-subsystem,windows -o release\myproject.exe object_script.myproject.Release -L"c:\QtSDK\Desktop\Qt\4.8.1\mingw\lib" -lmingw32 -lqtmain release\myproject_res.o -L. -lswscale-2 -lavcodec-54 -lavdevice-53 -lavfilter-2 -lavformat-54 -lavutil-51 -lusb -lPsapi -lasa047 -lsphinxbase -lpocketsphinx -LC:\QtSDK\Desktop\Qt\4.8.1\mingw\plugins/imageformats -lqjpeg -lqgif -lqico -lqtiff -lQtMultimedia4 -lQtGui4 -lQtNetwork4 -lQtCore4
c:/qtsdk/mingw/bin/../lib/gcc/mingw32/4.4.0/../../../../mingw32/bin/ld.exe: cannot find -lqjpeg
In the above you can see -LC:\QtSDK\Desktop\Qt\4.8.1\mingw\plugins/imageformats specified before -lqjpeg and C:\QtSDK\Desktop\Qt\4.8.1\mingw\plugins\imageformats\qjpeg4.dll exists ... so what gives?
Additional info: I can comment out the QTPLUGIN line in the .pro file and put instead:
LIBS += -LC:\\QtSDK\\Desktop\\Qt\\4.8.1\\mingw\\plugins\\imageformats -l:qjpeg4.dll
This links successfully, but I'm more interested in why QTPLUGIN appears broken out of the box under Windows mingw. What am I missing?
Seems to be a known (unresolved) bug with qmake: https://bugreports.qt.io/browse/QTBUG-24177?focusedCommentId=179693#comment-179693