I'm trying to build simplest Boost.Asio tutorial example "timer1" (it's in timer.cpp) with waf on Debian squeeze, python 2.6.6.
root#ds:/var/timer# ls
timer.cpp wscript
wscript here is a config of waf:
#! /usr/bin/env python
top = '.'
out = '.'
def options(opt):
opt.load('compiler_cxx')
def configure(conf):
conf.load('compiler_cxx')
conf.env['LINKFLAGS'] = '--verbose -L/usr/local/lib -lboost_system'
def build(bld):
tgen = bld.new_task_gen()
tgen.features = 'cxx cxxprogram'
tgen.source = 'timer.cpp'
tgen.target = 'timer'
tgen.includes = '.'
tgen.update_outputs = True
waf configure is successfull.
But waf --verbose build finishes with error (I inserted <*> below to mark a line)
Waf: Entering directory `/var/timer'
[1/2] cxx: timer.cpp -> timer.cpp.1.o
[2/2] cxxprogram: timer.cpp.1.o -> timer
timer.cpp.1.o: In function `__static_initialization_and_destruction_0(int, int)':
timer.cpp:(.text+0x103): undefined reference to `boost::system::generic_category()'
timer.cpp:(.text+0x10f): undefined reference to `boost::system::generic_category()'
...
Build failed
-> task in 'timer' failed (exit status 1):
{task 38446736: cxxprogram timer.cpp.1.o -> timer}
<*>
['/usr/bin/g++', '--verbose -L/usr/local/lib -lboost_system', 'timer.cpp.1.o', '-o', '/var/timer/timer', '-Wl,-Bstatic', '-Wl,-Bdynamic']
It seems gcc called by waf didn't find boost_system library during linkage.
But everything works fine if I build example by gcc without waf.
root#ds:/var/timer# /usr/bin/g++ --verbose -I/var/flake/lib/boost timer.cpp -c -o timer.cpp.1.o
...
<**>
root#ds:/var/timer# /usr/bin/g++ --verbose -L/usr/local/lib -lboost_system timer.cpp.1.o -o timer -Wl,-Bstatic -Wl,-Bdynamic
...
root#ds:/var/timer# ls
timer.cpp timer.cpp.1.o timer wscript
As you can see command line used by waf (marked by <*> ) is identical with command line marked by <**>. But the result is completely different. Why? And how can I force waf to build that thing? Solution from here doesn't work for me too. Also tried
...
opt.tool_options('boost')
...
conf.load('compiler_cxx boost')
conf.check_boost()
...
tgen.uselib = 'BOOST'
...
but without any effect
And another question. Output of gcc --verbose is much more extensive than output of waf --verbose. It seemed to me that verbose option must force waf to display all such info. Why isn't that true? waf option -vvv doesn't display this info as well.
If you use the boost tool, you should check the waf boost example in playground/boost, and you will see that check_boost takes arguments. It will solve your issue.
Alternatively if you don't use the tool, and using a real OS where libraries are set up in an accessible folder, you can just do:
conf.env.LIB_BOOST = ['boost_system']
...
bld(
...,
use='BOOST',
...,
)
Note for your future scripts:
avoid using CFLAGS, CXXFLAGS, LINKFLAGS as it's not portable.
don't set out='.' if possible
use bld(...) vs. the old syntax
The reason was that older Boost 1.42 binaries bundled with Debian were in /usr/lib. When I found that I tried to make /usr/local/lib more prioritive (latest Boost binaries built by b2 reside there). But I couldn't make waf to do that and than just uninstalled Boost 1.42 binaries completely and everything worked after that
Related
I want to develop a small program that checks which polygons from a shapefile intersect a given rectangle. This program is to be used in a website (with PHP's exec() command). The problem is, my webserver cannot install GDAL, for reasons unknown to me. So I can't link to the shared libraries. Instead, I must link to static libraries, but these aren't given.
I've downloaded the GDAL source code from here (2.3.2 Latest Stable Release - September 2018), and followed the build instructions from here. Since I already have GDAL working on my Debian, and don't want to mess with it, I followed the "Install in non-root directory" instructions, with some adjusts from the last item in the "Some caveats" section:
cd /home/rodrigo/Downloads/gdal232/gdal-2.3.2
mkdir build
./configure --prefix=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/ --without-ld-shared --disable-shared --enable-static
make
make install
export PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/bin:$PATH
export LD_LIBRARY_PATH=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib:$LD_LIBRARY_PATH
export GDAL_DATA=/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/share/gdal
/usr/bin/gdalinfo --version
build/bin/gdalinfo --version
The first /usr/bin/gdalinfo --version gives 2.1.2 (the previous installed version). The second, build/bin/gdalinfo --version, gives 2.3.2 (the version just built).
By now, my program only uses the ogrsf_frmts.h header, which is in /usr/include/gdal/ or /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/include/ directory, depending on the build. There's no ogrsf_frmts.a file, but only a libgdal.a. Is this the file I should be linking against? If so, how? I've tried so far:
gcc geofragc.cpp -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -Wl,-Bstatic -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp /home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
gcc geofragc.cpp -l:/home/rodrigo/Downloads/gdal232/gdal-2.3.2/build/lib/libgdal.a
but nothing works. What am I missing?
EDIT
The second trial (gcc geofragc.cpp -Wl,-Bstatic -l:libgdal.a) is giving the following error:
/usr/bin/ld: cannot find -lgcc_s
/usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libgdal.a(gdalclientserver.o): In function `GDALServerSpawnAsync()':
(.text+0x1f5e): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
You can use the gdal-config program to get correct options for compilation and linking. This program is a part of the GDAL library and it has its own options:
hekto#ubuntu:~$ gdal-config --help
Usage: gdal-config [OPTIONS]
Options:
[--prefix[=DIR]]
[--libs]
[--dep-libs]
[--cflags]
[--datadir]
[--version]
[--ogr-enabled]
[--gnm-enabled]
[--formats]
You have to make sure this program is on your search path, or you can create an alias - for example:
alias gdal-config='/home/rodrigo/Downloads/gdal232/gdal-2.3.2/bin/gdal-config'
Now your compilation and linking command becomes the following one:
g++ `gdal-config --cflags` geofragc.cpp `gdal-config --libs` `gdal-config --dep-libs`
You have to use the g++ compiler to link with C++-built libraries.
Another option is to create a Makefile with these lines:
CXXFLAGS += ${shell gdal-config --cflags}
LDLIBS += ${shell gdal-config --libs}
LDLIBS += ${shell gdal-config --dep-libs}
geofragc: geofragc.cpp
and just call make with this Makefile.
I hope, it'll help.
i want to run a "make" command in linux terminal in order to use some c++ libs.
Unluckily while running the "make" an error appears saying it cannot find the requested libs.
Here the relevant makefiles:
Here are the files in my filesystem which should be linked.
Why does makefile not find the libraries ?
Thanks for all answers in advance
Try to modify your Makefile for -lgmp rather than -libgmp
In background the compiler adds the 'lib' onto the name as well as the extension .so and similar stuff.
Try running the following to get an overview of what the linker is trying to do:
ld -L [yourincludepath] -lgmp --verbose
Such resolution issues might be due to the fact you are trying to link a 64bit library with a 32bit application? Try installing a proper XX-bits of the lib maybe?
Try to add -m option (machine dependency):
ld -melf_i386 -L /usr/lib/i386-linux-gnu/ -lgmp --verbose
Other values which might be supported on your side:
elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu i386linux elf_l1om elf_k1om i386pep i386pe
More info:
usr/bin/ld: cannot find -l<nameOfTheLibrary>
I've built opencv 3.0 from source and can run a few sample apps, build against the headers ok so I presume it's installed successfully.
I'm also using python3 and I now go to install and build caffe. I set a few variables in Makefile.config as I'm using the CPU due to having an AMD GPU and also Anaconda.
When I run make all I get this error:
$ make all
CXX/LD -o .build_release/examples/cpp_classification/classification.bin
/usr/bin/ld: .build_release/examples/cpp_classification/classification.o: undefined reference to symbol '_ZN2cv6imreadERKNS_6StringEi'
//usr/local/lib/libopencv_imgcodecs.so.3.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Makefile:565: recipe for target '.build_release/examples/cpp_classification/classification.bin' failed
make: *** [.build_release/examples/cpp_classification/classification.bin] Error 1
from searching I think this is something to do with using openCV 3 but I'm not sure where to start looking for a solution. Any help?
And yes I'm one of the horde of inexperienced users looking to fiddle with the Google Inception learning technique.
You can also add the opencv_imgcodecs to the MakeFile in line 187, see this pull.
It could be that you are using OpenCV version 3. If yes just uncomment the following line in your Makefile.config:
# OPENCV_VERSION := 3
So it will look like
OPENCV_VERSION := 3
You could verify the version currently in use by doing:
$ python
>>> import cv2
>>> cv2.__version__
'3.1.0-dev'
The problem report is very clear. There is a problem with linking library libraries.The reason may be the difference between 3.0 and 2.x.
You need to add
opencv_core opencv_highgui opencv_imgproc opencv_imgcodecs
into LIBRARIES +=.
I used cmake instead with the -DBUILD_TIFF=ON flag and got a successful build.
You can edit Makefile.config with the following 2 lines like this and it worked for me. Note that your opencv path must be set before default path!
INCLUDE_DIRS := $(PYTHON_INCLUDE) /home/young/Soft/openCV-3.3.1/include \
/usr/local/include /usr/include/hdf5/serial
LIBRARY_DIRS := $(PYTHON_LIB) /home/young/Soft/openCV-3.3.1/lib \
/usr/local/lib /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/hdf5/serial
A quick workaround is to add -lopencv_imgcodecs flag when you're compiling your code.
This worked for me:
g++ test.cpp -o test <Some flags> -lopencv_imgcodecs
I have built and installed a shared library to do some profiling of my projects via code instrumentation, specifically with the -finstrument-functions switch of gcc.
It is possible to turn the instrumentation on and off with the compiler switch, and hence I'd like to be able to turn the dependency to the profiling library on and off just by reconfiguring.
I can pass -finstrument-functions to gcc via configure's CFLAGS, but when I try to pass -lmylib via LDFLAGS configure fails with
configure:2796: checking whether we are cross compiling
configure:2804: gcc -o conftest -g -Wall -Wextra -Werror -lmylib conftest.c >&5
configure:2808: $? = 0
configure:2815: ./conftest
./conftest: error while loading shared libraries: libmylib.so.0: cannot open shared object file: No such file or directory
The file exists, I have double checked and compiling and linking a dummy example works as expected.
Interestingly, when I pass the full path to the shared library instead of -lmylib, the error persists, but when I pass the full path to the corresponding static library, configure runs smoothly, and everything is built as expected.
My question in a nutshell: Is there a possibility to pass optional shared libraries to autotools-generated configure scripts, without changing configure.ac?
Thanks,
Andy
It looks like your library is not in the compiler's default library search path.
You may also pass library search path through LDFLAGS with the -L switch:
CFLAGS=-finstrument-functions LDFLAGS="-lmylib -L/path/to/mylib" ./configure ....
fixed by running sudo ldconfig
I'll leave this here in case someone else has the same problem.
I'm using Cygwin/Windows and I'm trying to build a native module for node.js. I intend to make use of the OpenSSL Library. I have installed openssl from the Cygwin package manager.
I have the following lines in my .cc file:
#include <openssl/dh.h>
and
DH* public_dh_key = DH_new();
But when I try to link/compile it with node-waf configure build, I get:
undefined reference to _DH_new
Edit:
Part of the build script:
def build(bld):
ppp= bld.new_task_gen('cxx', 'shlib', 'node_addon')
ppp.cxxflags = ["-g", "-D_FILE_OFFSET_BITS=64", "-D_LARGEFILE_SOURCE", "-Wall", "-L/usr/lib", "-lssl"]
...
(I have tried adding -lcrypto but still get the same result. I have also tried various combinations of "-lssl32","-lssleay32","-llibeay32".)
Edit
Output of the build script:
$ node-waf configure build
Checking for program g++ or c++ : /usr/bin/g++
Checking for program cpp : /usr/bin/cpp
Checking for program ar : /usr/bin/ar
Checking for program ranlib : /usr/bin/ranlib
Checking for g++ : ok
Checking for node path : not found
Checking for node prefix : ok /usr/local
'configure' finished successfully (0.330s)
Waf: Entering directory `/usr/src/build'
[1/2] cxx: ppp.cc -> build/default/ppp_1.o
[2/2] cxx_link: build/default/ppp_1.o -> build/default/ppp.node build/default/libppp.dll.a
Creating library file: default/libppp.dll.a
default/ppp_1.o:/usr/src/build/../ppp.cc:289: undefined reference to `_HMAC'
collect2: ld returned 1 exit status
Waf: Leaving directory `/usr/src/build'
Build failed: -> task failed (err #1):
{task: cxx_link ppp_1.o -> ppp.node,libppp.dll.a}
Edit
I have the header file dh.h in usr/include/openssl
And I have the required files (libssl32.dll, libeay32.dll and ssleay32.dll) in /usr/lib/
The answer
jHackTheRipper answered this and got the credit for it, but the final answer is buried in the comments beneath his answer. So to summarise, the waf mantra is
obj.lib='crypto'
Adding -lcrypto should do the trick.
According to the nm output on my system _DH_new and _HMAC seem to be in the libcrypto (part of OpenSSL) dynamic library :
jhacktheripper#macbook-prolocal:~$ nm /usr/lib/libcrypto.dylib | grep _DH_new
0000000000036360 T _DH_new
0000000000036120 T _DH_new_method
jhacktheripper#macbook-prolocal:~$ nm /usr/lib/libcrypto.dylib | grep HMAC
0000000000090d40 T _HMAC
0000000000090c80 T _HMAC_CTX_cleanup
0000000000090910 T _HMAC_CTX_init
00000000000908c0 T _HMAC_CTX_set_flags
0000000000090940 T _HMAC_Final
0000000000090cc0 T _HMAC_Init
0000000000090a10 T _HMAC_Init_ex
0000000000090a00 T _HMAC_Update