My build system has libtiff installed in this path:
/usr/lib/x86_64-linux-gnu/libtiff.so.5.2.4
And I have built a custom libtiff in a local path:
/home/user/libtiff/usr/local/lib/libtiff.so.3.8.2
I want to build a binary linked with libtiff installed on my local path. To do that, I use this command:
cc -o binary \
obj1.o ... objn.o \
-L /home/user/libtiff/usr/local/lib/ \
-Wl,-rpath,L/home/user/libtiff/usr/local/lib/ \
-ltiff
The problem is after linking and generating the binary, ldd shows the binary is not using the local libtiff, but the library installed on the build system:
$ ldd binary | grep libtiff
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007fbaf9ad6000)
I don't understand why the linker is not using the local library.
I have read some related posts talking about setting LD_LIBRARY_PATH, LD_PRELOAD or LIBRARY_PATH, but none of them works as expected.
Modifiying /etc/ld.so.conf is not a nice option.
Remove the spurious L in front of the root slash:
-Wl,-rpath,L/home/user/libtiff/usr/local/lib/
#yugr, thank you for this -verbose tip. It helped me to fix the issue. The problem was with another library compiled locally (spandsp) that depends on libtiff. The configure script of the spandsp was deciding to use libtiff.so.5 (build system) instead of libtiff.so.3 (compiled locally). That was because LDFLAGS was not properly defined before executing the configure script. Defining LDFLAGS as -L/home/user/usr/local/lib/ -Wl,-rpath-link,/home/user/usr/local/lib/ fixed the issue. Thank you very much for your interest in helping with this issue! :)
Related
Hi I'm running devtoolset-3 on centos 6.5.
When I run g++, ld fails because it can't find -lelf
I compiled with the -v flag to find the library path g++ is using to find libraries, and have moved libelf.so into each of these folders however it is still not working.
I was wondering if anyone had any ideas? Is -lelf not libelf.so? Should this file be in some place else besides the library paths?
Thanks!
Finding the package that provides libelf.so : # yum provides libelf.so
# yum install elfutils-libelf-devel
When running configure it fails with
checking for leptonica... yes
checking for pixCreate in -llept... no
configure: error: leptonica library missing
But I have leptonica 1.69 built (downloaded source and ran ./configure && make install)
Edit
I think configure: error: leptonica library missing is a bit misleading, please note that it first says checking for leptonica... yes, and then fails on checking for pixCreate in -llept... no. So maybe the problem is not that the library is missing, but something else.
I finally managed to make it compile, after reading this and this thread. The proper steps for were:
./autogen.sh
export LIBLEPT_HEADERSDIR=/local/include
./configure --with-extra-libraries=/local/lib
make install
for leptonica 1.69, lib renamed to .libs, so, parameters are
export LIBLEPT_HEADERSDIR=<your_path>/leptonica-1.69/src
./autogen.sh
./configure --prefix= --with-extra-libraries=<your_path>/leptonica-1.69/src/.libs
and so on
Maybe this could solve the issue:
export LIBLEPT_HEADERSDIR=/usr-or-other/local/include
I am working on redhat linux 7.2 . None of the solution worked for me I was getting following errors in config.log. Package lept was not found in the pkg-config search path.
Perhaps you should add the directory containing `lept.pc'
to the PKG_CONFIG_PATH environment variable PKG_CONFIG_PATH
configure script uses pkg-config utility to check for packages . It was not able to find lept package ( although i had installed leptonica seperately ) By setting PKG_CONFIG_PATH pointing to the directory where lept.pc is present , i was able to resolve the issue . export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
The FAQ addresses this issue and worked for me with tesseract 3.02.02 on Mac OSX 10.6.8.
Apart from the Leptonica library, png, jpeg, tiff libraries had to passed to the configure script with CXX and CPP flags.
To run configure as non-root -
1. LIBLEPT_HEADERSDIR=; export LIBLEPT_HEADERSDIR;
2. CXXFLAGS="-ltiff -lpng -ljpeg" CPPFLAGS="-ltiff -lpng -ljpeg" ./configure --prefix= --with-extra-libraries=
In my case, this issue was caused by a missing compiler. Searching config.log revealed the following:
./configure:17287: g++ -o conftest -I/Usr/local/include/leptonica -L/usr/local/lib conftest.cpp -llept >&5
./configure: line 2040: g++ command not found
Running apt-get install g++ solved the problem. There is an issue in the tesseract issue tracker about this.
In my case (for Ubuntu/Debian) I downloaded the latest leptonica version and the error was not fixed.
To fix it I removed the package "leptonica-dev" with sudo apt-get remove libleptonica-dev and then tesseract found the leptonica version installed from the source code.
Hope it helps!
The answer is going to be slightly different for everyone, depending on the state of your system.
At a high level, the pkg-config software needs to know that leptonica is installed. It searches paths for a .pc file that has the definition for the leptonica package. That file will be in different locations for different people.
You can find it using the Linux locate utility at the command line. locate lept.pc. (If you've done some recent installing/uninstalling, you may need to refresh the locate utilities database with the command updatedb.)
Whichever directory locate finds the file in, export PKG_CONFIG_PATH as that directory (export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig for example).
Then you can continue your configure/build.
i had a similar problem with trying to compile from source, but did not experience it with
apt-get to install tesseract
sudo apt-get install tesseract-ocr
export LIBLEPT_HEADERSDIR=$dir/letonica168/include
./autogen.sh
./configure --prefix=$anotherdir --with-extra-libraries=/$dir/letonica168/lib
make
make install
I have compiled gdc together with gcc using the android build-gcc.sh script, and have included a new stub in build/core/definitions.mk to deal with D language files as a part of the build process. I know things are compiling OK at this point, but my problem is linking:
When I build a project, I get this error:
ld: crtbegin_so.o: No such file: No such file or directory
This is true for regular c-only projects as well. Now I ran a quick find in my build directory, and found that the file (crtbegin_so.o) does exist within the sysroot I specified when I compiled gcc (or rather, when build-gcc.sh built it).
What are some things I could look for to find a solution to this problem?
Would copying the files locally and linking directly to them be a decent solution in the
interim?
Why would ld (or collect2) be trying to include these for a gdc (D Language) linkage?
The issue arises on NDK r7c for linux as well.
I found that the toolchain ignores the platform location ($NDK_ROOT/platforms/android-8/arch-arm/usr/lib/) and searches for it in the toolchain path, which is incorrect.
However, as the toolchain also searches for the file in the current directory, one solution is to symlink the correct platform crtbegin_so.o and crtend_so.o into the source directory:
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtbegin_so.a
cd src && ln -s NDK_ROOT/platforms/android-8/arch-arm/usr/lib/crtend_so.a
Thus your second point should work out (where you can do a symlink, instead of a copy)
NOTE 1:This assumes that the code is being compiled for API8 (Android 2.2) using the NDK. Please alter the path to the correct path as per your requirement.
NOTE 2:Configure flags used:
./configure \
--host=arm-linux-androideabi \
CC=arm-linux-androideabi-gcc \
CPPFLAGS="-I$NDK_ROOT/platforms/android-8/arch-arm/usr/include/" \
CFLAGS="-nostdlib" \
LDFLAGS="-Wl,-rpath-link=$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/ -L$NDK_ROOT/platforms/android-8/arch-arm/usr/lib/" \
LIBS="-lc"
I have found that adding --sysroot=$(SYSROOT) to the compiler options fixes the error:
cannot open crtbegin_so.o: No such file or directory
from my makefile...
CC= $(CROSS_COMPILE)gcc -fvisibility-hidded $(INC) $(LIB) -shared
Note: this assumes that the setenv-android.sh has been run to setup the environment
$. ./setenv-android.sh
In my case quotes were missing from sysroot path.
When I changed
--sysroot=${ANDROID_NDK}\platforms\android-17\arch-arm
to
--sysroot="${ANDROID_NDK}\platforms\android-17\arch-arm"
the project was compiled and linked successfully.
I faced with the same issue in two separate cases:
during building boost for android
during using android-cmake project.
Once I have switched to standalone toolchain issue gone, here is example of command which prepare standalone toolchain
$NDK_ROOT/build/tools/make-standalone-toolchain.sh --platform=android-9 --install-dir=android-toolchain --ndk-dir=$NDK_ROOT --system=darwin-x86_64 --toolchain=arm-linux-androideabi-4.9
Boost specific
for boost you need specify --sysroot several times in your jam
<compileflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
<linkflags>--sysroot=$NDK_ROOT/platforms/android-9/arch-arm
I am trying to compile a package on ubuntu 8.1
when executing this command: ./configure I get the follwoing error:
checking for Boost headers version >= 103700... no
configure: error: cannot find Boost headers version >= 103700
knowing that I installed needed boost packages using these command:
$ apt-get install libboost-dev libboost-graph-dev libboost-iostreams-dev
Can anybody help please?
thank you. Now it works but i get another error when running ./configure: checking boost/iostreams/device/file_descriptor.hpp usability... yes checking boost/iostreams/device/file_descriptor.hpp presence... yes checking for boost/iostreams/device/file_descriptor.hpp... yes checking for the Boost iostreams library... no configure: error: cannot not find the flags to link with Boost iostreams any ideas please?
It could be that the version of boost that you're getting from the Ubuntu repository is too old (it's suggested here that the highest version for 8.10 is 1.35; it looks like your configure script is asking for 1.37). You might need to build from source; there's some more info in the answers to the question I linked to which will hopefully help.
UPDATE:
From your new error, it sounds like configure now can't find the boost_iostreams library. On my system it's /usr/lib/libboost_iostreams-mt.[a|so] - do you have those files (possibly in a different directory depending on where you installed boost)?
You can also try running ldconfig in case there's a missing symlink (from, say,
libboost_iostreams-mt.so.1.37.0 to libboost_iostreams-mt.so).
Is this configure one generated by GNU autoconf? If it is, there should be a file called config.log in the same directory which contains a list of all the commands configure tried to run when looking for things. If there's anything in there about boost_iostreams could you post it?
One totally random guess: some examples I've found on the web link to boost_iostreams without the multi-threading suffix -mt - but I don't have those on my machine at all. Maybe your configure script is running into the same problem?
UPDATE 2
The configure script seems to be looking for a single-threaded debug build of the boost iostreams library, which won't be produced by default when building from source on linux. Also, the default on linux is not to name the libraries based on the build configuration (so the libs you found in /usr/lib might not be the ones you installed from source unless you overrode this). This stuff isn't really explained on the boost website, I only found out by looking in the Jamroot file (bjam --help works too)! Anyway, to get a library with the right build configuration, and named correctly, I need to go into the root of the boost source tree and run:
sudo bjam --with-iostreams --layout=tagged variant=debug threading=single install
For me this puts the libraries (libboost_iostreams-d.a and the shared versions) into /usr/local/lib where ld will find them by default, so this should be fine. If you need them to go somewhere else you can use the --prefix=... option to bjam eg. if you want them in /usr/lib you can do --prefix=/usr. If the package you're building needs more boost libraries you can remove the --with-iostreams and then they'll all be built (or replace iostream with the name of each other library you need).
A side note: I had to install the libbz2-dev package to get boost iostreams to build - it's easy to miss the error here if you build all of boost as there's so much output!
I want to have a static Universal binary lib of Boost. (Preferable the latest stable version, that is 1.43.0, or newer.)
I found many Google hits with similar problems and possible solutions. However, most of them seems outdated. Also none of them really worked.
Right now, I am trying
sudo ./bjam --toolset=darwin --link=static --threading=multi \
--architecture=combined --address-model=32_64 \
--macosx-version=10.4 --macosx-version-min=10.4 \
install
That compiles and install fine. However, the produced binaries seems broken.
az#ip245 47 (openlierox) %file /usr/local/lib/libboost_signals.a
/usr/local/lib/libboost_signals.a: current ar archive random library
az#ip245 49 (openlierox) %lipo -info /usr/local/lib/libboost_signals.a
input file /usr/local/lib/libboost_signals.a is not a fat file
Non-fat file: /usr/local/lib/libboost_signals.a is architecture: x86_64
Edit: It seems that the command was wrong and I must remove the "--" for most options. So the command I am trying now (-a just means to rebuild all):
sudo ./bjam -a toolset=darwin link=static threading=multi \
architecture=combined address-model=32_64 \
macosx-version=10.4 macosx-version-min=10.4 \
install
However, this gives many strange errors (what I already had earlier), all like this:
darwin.compile.c++.pch bin.v2/libs/math/build/darwin-4.2.1/release/address-model-32_64/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/../src/tr1/pch.hpp.gch
In file included from ./boost/math/special_functions/acosh.hpp:18,
from ./boost/math/special_functions.hpp:15,
from libs/math/build/../src/tr1/pch.hpp:9:
./boost/config/no_tr1/cmath.hpp:21:19: error: cmath: No such file or directory
This could be another problem I have when building Universal binaries: g++ on MacOSX doesn't work with -arch ppc64
I found the problem. It seems that the MacOSX 10.4 SDK is missing a bunch of symlinks for GCC 4.2.
Use this as a test case:
g++ on MacOSX doesn't work with -arch ppc64
It will report multiple errors with GCC 4.2 (missing C++ includes, missing C includes, missing libs). In all cases, you can just fix that by setting a symlink. Search in your SDK for the file and just set the symlink in the same way it is in the MacOSX 10.5 SDK.
After that, it all just worked.
We use Boost compiled for 10.4 here at work. We don't use GCC 4.2 on it though, rather we use GCC 4.0 as Apple's GCC 4.2 is not supported for the MacOS 10.4 SDK. To accomplish this you need a bjam user config file, eg. user-config-darwin.jam. Here's the contents of ours. Modify to your heart's content:
# Boost.Build Configuration
# Compiler configuration
using darwin : 8.11 : /usr/bin/g++-4.0 :
<architecture>"combined"
<address-model>"32" # this can be changed to 32_64 for 32/64 universal builds
<macosx-version>"10.4"
<macosx-version-min>"10.4"
# <root>"/Developer"
<compileflags>""
<linkflags>"" ;
Then, you need to tell bjam to use the user config jam file when compiling:
bjam --user-config=user-config-darwin.jam ... (your other options go here) ...
Now you don't have to mess with symlinks in the system SDK directories.
To build 4-way universal boost static binaries on OSX 10.6 I do the following:
Download boost from the boost website.
Extract the archive and cd into the boost_1_xx_0 folder (where xx is the version of boost you are using).
Run:
./bootstrap.sh and then
./bjam macosx-version=10.6 macosx-version-min=10.4 architecture=combined threading=multi link=static address-model=32_64
This will compile everything except for Boost.MPI (which requires the --with-mpi option). The build products get put in ./stage