I have installed the mysql connector for c++. I am writing a c++ cgi app. The cgi page has been compiling. I rebooted yesterday and it stopped compiling. g++ -o sales.cgi sales.cpp -lcgicc -lmysqlcppcon. Gives the following error. /usr/bin/ld cannot find -lmysqlcppcon
apt-get tells me I have the latest version of libmysqlcppconn7v5 and i have the latest version of libmyqlcppconn-dev. How do I find the library. I checked /usr/lib/ but I have no idea what I should be looking for.
Since you installed with apt-get, then you can use dpkg to determine which files were installed.
EXAMPLE (you would substitute "mysqlcppcon"):
dpkg -l|grep -i mysql
ii php-mysql 1:7.2+60ubuntu1 all MySQL module for PHP [default]
... <= Search for the exact package name (here, "php-mysql")
dpkg -L php-mysql
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/php-mysql
/usr/share/doc/php-mysql/copyright
/usr/share/doc/php-mysql/changelog.gz
<= List files installed to your system from that package
You can also use find
EXAMPLE:
find / -name "*mysqlcppcon*" -print 2> /dev/null
The *xxx* syntax let's you do a wildcard search; 2> /dev/null filters out irrelevant"noise" from your wildcard search, like "find: ‘/run/lvm’: Permission denied".
Thanks for all of the help. Huge typo on my side. I needed g++ -o sales.cgi sales.cpp -lcgicc -lmysqlcppconn
I want to make g++ linker(ld) search for libraries starting in the directory /usr/local/lib. How do I permanently add /usr/local/lib to the search path for the linker?
The problem is that I am trying to link the library libboost_program_options.a to my source. There are two copies of the library, one in /usr/lib/x86_64-linux-gnu/ and the other in /usr/local/lib. How do I make the linker first look in /usr/local/lib and pick that instead of the other one?
The output of ldconfig -v 2>/dev/null | grep -v ^$'\t' on my system:
/usr/lib/x86_64-linux-gnu/libfakeroot:
/lib/i386-linux-gnu:
/usr/lib/i386-linux-gnu:
/usr/local/lib:
/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu:
/usr/lib/x86_64-linux-gnu/mesa-egl:
/usr/lib/nvidia-304:
/usr/lib32/nvidia-304:
/lib32:
/usr/lib32:
/lib:
/usr/lib:
/usr/lib/nvidia-304/tls: (hwcap: 0x8000000000000000)
/usr/lib32/nvidia-304/tls: (hwcap: 0x8000000000000000)
The output of ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
The search path is specified in the linker scripts used during compilation. Run gcc -v foo.c to perform a link and see which linker script is used. In my case, it is /usr/lib/ldscripts/elf_x86_64.x. In that linker script, you will find SEARCH_DIR directives. Update it to include /usr/local/lib.
Note that ldconfig and ld.so.conf.d are only used at runtime.
I was having issues getting an image to load in to Devil so I have provided exactly how I built the libs and how I am trying to use it.
Downloaded Devel source from their website.
$ unzip DevIL-1.7.8.zip
$ mkdir devil
$ cd Devil-1.7.8
+-------------------------------------------+
| Just type: |
| autoreconf -i |
| ./configure <your options here> |
| make |
| sudo make install |
+-------------------------------------------+
If I use autoreconf -i then ./configure with prefix and ilu and ilut. I get an error ..forgot.. to record it. How important is this? I have just not used it.
$ chmod +x configure
$ ./configure --prefix=/home/path/to/TestingDevil/devil --enable-ILU --enable-ILUT
$ make
$ make install
So at this point my library should be built.
I downloaded the devil simple example (simple.c) to TestingDevil/simple/simple.c
built it.
$ gcc -I ../devil/include -L ../devil/lib/ simple.c -o simple -lIL -lILU -lILUT
$ cp ../devil/lib/*.so* .
I have added an image (jpg) to test.
$ LD_LIBRARY_PATH=. ./simple image.jpg
"Could not open file...exiting"
I ran the executable from the simple directory.
simple$ ls
image.jpg libIL.so.1.1.0 libILU.so.1.1.0 libILUT.so.1.1.0 libIL.so
libILU.so libILUT.so simple libIL.so.1 libILU.so.1
libILUT.so.1 simple.c
Whats going wrong? I am using the example from devIL, it compiles and runs fine. Just can't load any files.
My System is Ubuntu 12.10 64 with build-essential installed and other dev packages for opengl dev.
Uni System is Fedora 15(?) 32. This also has exactly the same problem after building devIL in the same way.
On my home machine I installed the package libdevel-dev and that works fine.
This question does not ask about opengl, purely the devIL lib and example.
It looks like you build it withjout jpg support or you do not have jpeg libs available ?
I am trying to build gcc 4.7.2 using a custom prefix $PREFIX
I have built and installed all the prerequisites into my prefix location, and then successfully configured, built and installed gcc.
The problem that I now have is that $PREFIX is not in the library search path, and therefore the shared libraries cannot be found.
$PREFIX/bin $ ./g++ ~/main.cpp
$PREFIX/libexec/gcc/x86_64-suse-linux/4.7.2/cc1plus: \
error while loading shared libraries: \
libcloog-isl.so.1: \
cannot open shared object file: No such file or directory
What works, but isn't ideal
If I export LD_LIBRARY_PATH=$PREFIX/lib then it works, but I'm looking for something which works without having to set environment variables.
If I use patchelf to set the RPATH on all the gcc binaries then it also works; however this involves searching out all elf binaries and iterating over them calling patchelf, I would rather have something more permanent.
What I think would be ideal for my purposes
So I'm hoping there is a way to have -Wl,-rpath,$PREFIX/lib passed to make during the build process.
Since I know the paths won't need to be changed this seems like the most robust solution, and can be also be used for when we build the next gcc version.
Is configuring the build process to hard code the RPATH possible?
What I have tried, but doesn't work
Setting LDFLAGS_FOR_TARGET prior to calling configure:
All of these fail:
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -R$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib"
export LDFLAGS_FOR_TARGET="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
Setting LDFLAGS prior to calling configure:
export LDFLAGS="-L$PREFIX/lib -Wl,-rpath,$PREFIX/lib"
In any event I worry that these will override any of the LDFLAGS gcc would have had, so I'm not sure these are a viable option even if they could be made to work?
My configure line
For completeness here is the line I pass to configure:
./configure \
--prefix=$PREFIX \
--build=x86_64-suse-linux \
--with-pkgversion='SIG build 12/10/2012' \
--disable-multilib \
--enable-cloog-backend=isl \
--with-mpc=$PREFIX \
--with-mpfr=$PREFIX \
--with-gmp=$PREFIX \
--with-cloog=$PREFIX \
--with-ppl=$PREFIX \
--with-gxx-include-dir=$PREFIX/include/c++/4.7.2
I've found that copying the source directories for gmp, mpfr, mpc, isl, cloog, etc. into the top level gcc source directory (or using symbolic links with the same name) works everywhere. This is in fact the preferred way.
You need to copy (or link) to those source directory names without the version numbers for this to work.
The compilers do not need LD_LIBRARY_PATH (although running applications built with the compilers will need an LD_LIBRARY_PATH to the $PREFIX/lib64 or something like that - but that's different)
Start in a source directory where you'll keep all your sources.
In this source directory you have your gcc directory either by unpacking a tarball or svn...
I use subversion.
Also in this top level directory you have, say, the following source tarballs:
gmp-5.1.0.tar.bz2
mpfr-3.1.1.tar.bz2
mpc-1.0.1.tar.gz
isl-0.11.1.tar.bz2
cloog-0.18.0.tar.gz
I just download these and update to the latest tarballs periodically.
In script form:
# Either:
svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_work
# Or:
bunzip -c gcc-4.8.0.tar.bz2 | tar -xvf -
mv gcc-4.8.0 gcc_work
# Uncompress sources.. (This will produce version numbered directories).
bunzip -c gmp-5.1.0.tar.bz2 | tar -xvf -
bunzip -c mpfr-3.1.1.tar.bz2 | tar -xvf -
gunzip -c mpc-1.0.1.tar.gz | tar -xvf -
bunzip -c isl-0.11.1.tar.bz2 | tar -xvf -
gunzip -c cloog-0.18.0.tar.gz | tar -xvf -
# Link outside source directories into the top level gcc directory.
cd gcc_work
ln -s ../gmp-5.1.0 gmp
ln -s ../mpfr-3.1.1 mpfr
ln -s ../mpc-1.0.1 mpc
ln -s ../isl-0.11.1 isl
ln -s ../cloog-0.18.0 cloog
# Get out of the gcc working directory and create a build directory. I call mine obj_work.
# I configure the gcc binary and other outputs to be bin_work in the top level directory. Your choice. But I have this:
# home/ed/projects
# home/ed/projects/gcc_work
# home/ed/projects/obj_work
# home/ed/projects/bin_work
# home/ed/projects/gmp-5.1.0
# home/ed/projects/mpfr-3.1.1
# home/ed/projects/mpc-1.0.1
# home/ed/projects/isl-0.11.1
# home/ed/projects/cloog-0.18.0
mkdir obj_work
cd obj_work
../gcc_work/configure --prefix=../bin_work <other options>
# Your <other options> shouldn't need to involve anything about gmp, mpfr, mpc, isl, cloog.
# The gcc build system will find the directories you linked,
# then configure and compile the needed libraries with the necessary flags and such.
# Good luck.
I've been using this configure option with gcc-4.8.0, on FreeBSD, after building and installing gmp, isl and cloog:
LD_LIBRARY_PATH=/path/to/isl/lib ./configure (lots of other options) \
--with-stage1-ldflags="-rpath /path/to/isl/lib -rpath /path/to/cloog/lib -rpath /path/to/gmp/lib"
and the resulting gcc binary does not need any LD_LIBRARY_PATH. The LD_LIBRARY_PATH for configure is needed because it compiles a test program to check for the ISL version, which would fail if it didn't find the ISL shared lib.
I tried it on Linux (Ubuntu) where it failed during configuring because the -rpath args were passed to gcc instead of ld. I could fix this by using
--with-stage1-ldflags="-Wl,-rpath,/path/to/isl/lib,-rpath,/path/to/cloog/lib,-rpath,/path/to/gmp/lib"
instead.
Just using configure --with-stage1-ldflags="-Wl,-rpath,/path/to/lib" was not enough for me to build gcc 4.9.2, bootstrap failed in stage 2. What works is to pass he flags directly to make via
make BOOT_LDFLAGS="-Wl,-rpath,/path/to/lib"
I got this from https://gcc.gnu.org/ml/gcc/2008-09/msg00214.html
While it still involves setting environment variables, what I do is that I define LD_RUN_PATH, which sets the rpath. That way the rest of the system can keep using the system provided libraries instead of using the ones that your gcc build generates.
I am going to make a suggestion that I believe solves your problem, although it definitely does not answer your question. Let's see how many downvotes I get.
Writing a generic wrapper script to set LD_LIBRARY_PATH and then to run the executable is easy; see https://stackoverflow.com/a/7101577/768469.
The idea is to pass something like --prefix=$PREFIX/install to configure, building an install tree that looks like this:
$PREFIX/
install/
lib/
libcloogXX.so
libgmpYY.so
...
bin/
gcc
emacs
...
bin/
.wrapper
gcc -> .wrapper
emacs -> .wrapper
.wrapper is a simple shell script:
#!/bin/sh
here="${0%/*}" # or use $(dirname "$0")
base="${0##*/}" # or use $(basename "$0")
libdir="$here"/../install/lib
if [ "$LD_LIBRARY_PATH"x = x ] ; then
LD_LIBRARY_PATH="$libdir"
else
LD_LIBRARY_PATH="$libdir":"$LD_LIBRARY_PATH"
fi
export LD_LIBRARY_PATH
exec "$here"/../install/bin/"$base" "$#"
This will forward all arguments correctly, handle spaces in arguments or directory names, and so forth. For practical purposes, it is indistinguishable from setting the rpath like you want.
Also, you can use this approach not only for gcc, but for your entire my-personal-$PREFIX tree. I do this all the time in environments where I want an up-to-date suite of GNU tools, but I do not have (or want to admit to have) root access.
Try to add your $PREFIX to /etc/ld.so.conf and then run ldconfig:
# echo $PREFIX >> /etc/ld.so.conf
# ldconfig
This will recreate cache that is used by runtime linker and it will pick up your libraries.
WARNING: This operation will cause ALL applications to use your newly compiled libraries in $PREFIX instead of default location
I have installed libboost-dev through apt-get, and it's placed in /usr/lib.
/usr/lib$ ls | grep boost
libboost_filesystem.so.1.46.1
libboost_iostreams.so.1.46.1
libboost_serialization.so.1.46.1
libboost_system.so.1.46.1
libboost_thread.so.1.46.1
libboost_wserialization.so.1.46.1
But when I tried to compile a source that uses boost_thread I still got a error.
$ g++ tcp_echo.cpp -o tcp_echo -L/usr/lib -llibboost_thread
/usr/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
$ g++ tcp_echo.cpp -o tcp_echo -L/usr/lib -lboost_thread
/usr/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
What's the right way to install and link to libboost?
One thing I notice is that you do have no libboost_thread.so. You have
the versioned 1.46.1 file but usually libraries will create a symbolic
link to the versioned copy with the undecorated name. That might not
be it but it's one thing I noticed. (This is typically done by the
installer.) – Omaha
I think this is the point. It imply that I installed libboost the wrong way. In fact, I only installed libboost-dev:
sudo apt-get install libboost-dev
But what should I do is:
sudo apt-get install libboost-dev libboost1.46-doc libboost-date-time1.46-dev ibboost-filesystem1.46-dev libboost-graph1.46-dev libboost-iostreams1.46-dev libboost-math1.46-dev libboost-program-options1.46-dev libboost-python1.46-dev libboost-random1.46-dev libboost-regex1.46-dev libboost-serialization1.46-dev libboost-signals1.46-dev libboost-system1.46-dev libboost-test1.46-dev libboost-thread1.46-dev libboost-wave1.46-dev
(Or, in my particular case, install libboost-system1.46-dev libboost-thread1.46-dev at least)
And once you install them correctly, there should be .a and .so in /usr/lib.
/usr/lib$ ls | grep boost
libboost_date_time.a
libboost_date_time-mt.a
libboost_date_time-mt.so
libboost_date_time.so
libboost_date_time.so.1.46.1
libboost_filesystem.a
libboost_filesystem-mt.a
... and so on ...
In Ubuntu 16.04, the package is named: libboost-all-dev (not libboost-dev-all)
The comment box screwed up the quoting of this suggestion, so I'm posting it as an answer to get correct quoting.
It used to be, Ubuntu had the meta-package libboost-dev-all to install all of those. However, I can't seem to find it now. Here's a command line that might help:
sudo apt-get install `apt-cache search libboost | \
grep -- -dev | \
grep -v '[12]\.[0-9]' | \
awk '{ print $1; }'`
(Taken from https://github.com/imvu-open/istatd/ file install-boost-dev.sh )