I am attempting to install an application. During compilation it fails with the following error:
/usr/bin/ld: cannot find -lemu
I have installed the libemu library, and it now currently resides in /opt/libemu/. However, when I try and compile my application the library is not found. Is there any way to correct this?
EDIT: It also looks like the make is resulting in:
It also looks like the make file is compiling with the following:
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
build/temp.linux-x86_64-2.6/libemu_module.o
-L/opt/libemu/lib -lemu -o build/lib.linux-x86_64-2.6/libemu.so
I have tried setting my LD_LIBRARY_PATH to /opt/libemu, still doesn't work - fails with the error mentioned above.
You need to tell the linker where it is:
gcc stuff -L/opt/libemu -lemu
or:
gcc stuff /opt/libemu/libemu.a
where stuff is your normal compile/link options files etc.
You can also specify library paths in the LIBRARY_PATH environment variable:
LIBRARY_PATH=/opt/libemu
export LIBRARY_PATH
before you run your build. Yet another option is to see where gcc looks for libraries by running:
gcc --print-search-dirs
and put your library in one of the listed directories.
Edit: It is really not clear from your latest info what you are trying to build. Are you trying to turn a static library into a shared library? Most important - What is the exact filename of the library file you have copied into the /opt/libemu directory?
The environment variable LD_LIBRARY_PATH should include (but probably does not by default) /opt/libemu.
try running:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/libemu
make install
Related
I am trying to use libwebsocket to build up my WebSocket server and I need to used libmysql in my code. I have install the libmysql and able to use it but I don't know how to include it using cmake in CMakeList.txt
I have include it in my test-server.h
#include <mysql.h>
In my CMakeList.txt, I add this
INCLUDE_DIRECTORIES(/usr/include/mysql)//this is add to the begining
when I use "make" to make the file, I got the error message
CMakeFiles/test-server.dir/test-server/test-server.c.o: in function main:
test-server.c:(.text.startup+0x41): undefined reference to `mysql_init'
collect2: error: ld returned 1 exit status
Here is the original code of the CMakeList.txt
https://github.com/warmcat/libwebsockets/blob/master/CMakeLists.txt
The CMakeList.txt is provided by libwebsocket and I try to edit it with the follow code:
INCLUDE_DIRECTORIES(/usr/include/mysql)
Name: libwebsockets
Description: Websockets server and client library
Version: ${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACK AGE_VERSION_PATCH}
Libs: -L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -ldl -L\${libdir} -lwebsockets
Cflags: -I/usr/include/mysql -DBIG_JOINS=1 -fno-strict-aliasing -g -DNDEBUG -I\${includedir}"
Why I can not link the library?
What should I do in order to use libmysql in my libwebsocket server code?
I am using ubuntu 14.04 as OS.
I would recommend you to create your own CMakeLists.txt file.
It should takes care of your own code, because test-server.c is just an example that allow you to understand how to build your own server. In my opinion, it is not intend to be modified. But, of course, it is up to you to do so if you think it is easier.
So, now, if you really want to modify the example coming with libwebsockets, and want to keep the associated CMakeLists.txt file, then you could modify the create_test_app macro and modify calls to target_link_libraries (in addition to the modification you have already made regarding include path).
For example you could change:
target_link_libraries(${TEST_NAME} websockets)
by
target_link_libraries(${TEST_NAME} websockets mysqlclient)
It should be even better to take advantage of FindMysql.cmake to automatically find out what are the correct include paths and libraries locations.
I'm trying to generate pdf file by using libharu library but i have compiled the code its creates objective file while run that executable file its giving
error like :undefined reference 'print_grid'
first i export the path:
export PATH="$PATH:/usr/local/lib/libhpdf.so"
and compiled
gcc -c text_demo.c -o text_demo.o
gcc text_demo.o -L"/usr/loca/lib" -lhpdf -o "text_demo.exe"
Try this:
1) Make sure you've actually installed libhpdf.so into /usr/local/lib
2) Compile and link: gcc -Wall -g text_demo.c -L/usr/local/lib -lhpdf -o text_demo
Note that you do not need "exe", you do not need the extraneous quote marks.
Also note that $PATH has nothing to do your your shared library path. That's for Windows; Linux uses $LD_LIBRARY_PATH.
3) Type ldd text_demo
This checks any runtime dependencies
4) Finally, try running your program: ./text_demo
5) Please copy/paste any EXACT error messages during your build, ldd or execute.
You need to install libharu and libharu-devel package
Please find apperopriate pakage from here for centos 5 or cent os 6
http://pkgs.org/search/libharu
And then compile your source code
The problem I faced has been solved here:
Loading shared library in open-mpi/ mpi-run
I know not how, setting LD_LIBRARY_PATH or specifying -x LD_LIBRARY_PATH fixes the problem, when my installation itself specifies the necessary -L arguments. My installation is in ~/mpi/
I have also included my compile-link configs.
$ mpic++ -showme:version
mpic++: Open MPI 1.6.3 (Language: C++)
$ mpic++ -showme
g++ -I/home/vigneshwaren/mpi/include -pthread -L/home/vigneshwaren/mpi/lib
-lmpi_cxx -lmpi -ldl -lm -Wl,--export-dynamic -lrt -lnsl -lutil -lm -ldl
$ mpic++ -showme:libdirs
/home/vigneshwaren/mpi/lib
$ mpic++ -showme:libs
mpi_cxx mpi dl m rt nsl util m dl % Notice mpi_cxx here %
When I compiled with mpic++ <file> and ran with mpirun a.out I got a (shared library) linker error
error while loading shared libraries: libmpi_cxx.so.1:
cannot open shared object file: No such file or directory
The error has been fixed by setting LD_LIBRARY_PATH. The question is how and why? What am i missing? Why is LD_LIBRARY_PATH required when my installation looks just fine.
libdl, libm, librt, libnsl and libutil are all essential system-wide libraries and they come as part of the very basic OS installation. libmpi and libmpi_cxx are part of the Open MPI installation and in your case are located in a non-standard location that must be explicitly included in the linker search path LD_LIBRARY_PATH.
It is possible to modify the configuration of the Open MPI compiler wrappers and make them pass the -rpath option to the linker. -rpath takes a library path and appends its to a list, stored inside the executable file, which tells the runtime link editor (a.k.a. the dynamic linker) where to search for libraries before it consults the LD_LIBRARY_PATH variable. For example, in your case the following option would suffice:
-Wl,-rpath,/home/vigneshwaren/mpi/lib
This would embed the path to the Open MPI libraries inside the executable and it would not matter if that path is part of LD_LIBRARY_PATH at run time or not.
To make the corresponding wrapper add that option to the list of compiler flags, you would have to modify the mpiXX-wrapper-data.txt file (where XX is cc, c++, CC, f90, etc.), located in mpi/share/openmpi/. For example, to make mpicc pass the option, you would have to modify /home/vigneshwaren/mpi/share/openmpi/mpicc-wrapper-data.txt and add the following to the line that starts with linker_flags=:
linker_flags= ... -Wl,-rpath,${prefix}/lib
${prefix} is automatically expanded by the wrapper to the current Open MPI installation path.
In my case, I just simply appends
export LD_LIBRARY_PATH=/PATH_TO_openmpi-version/lib:$LD_LIBRARY_PATH
For example
export LD_LIBRARY_PATH=/usr/local/openmpi-1.8.1/lib:$LD_LIBRARY_PATH
into $HOME/.bashrc file and then source it to active again source $HOME/.bashrc.
I installed mpich 3.2 using the following command on Ubuntu.
sudo apt-get install mpich
When I tried to run the mpi process using mpiexec, I got the same error.
/home/node1/examples/.libs/lt-cpi: error while loading shared libraries: libmpi.so.0: cannot open shared object file: No such file or directory
Configuring LD_LIBRARY_PATH didn't fix my problem.
I did a search for the file 'libmpi.so.0' on my machine but couldn't find it. Took me some time to figure out that 'libmpi.so.0' file is named as 'libmpi.so' on my machine. So I renamed it to 'libmpi.so.0'.
It solved my problem!
If you are having the same problem and you installed the library through apt-get, then do the following.
The file 'libmpi.so' should be in the location '/usr/lib/'. Rename the file to 'libmpi.so.0'
mv /usr/lib/libmpi.so /usr/lib/libmpi.so.0
After that MPI jobs should run without any problem.
If 'libmpi.so' is not found in '/usr/lib', you can get its location using the following command.
whereis libmpi.so
first, run this command
$ sudo apt-get install libcr-dev
if still have this problem then configure LD_LIBRARY_PATH like this:
export LD_LIBRARY_PATH=/usr/local/mpich-3.2.1/lib:$LD_LIBRARY_PATH
then add it to ~/.bashrc before this line:
[ -z "$PS1" ] && return
Simply running
$ ldconfig
appears to me as a better way to solve the problem (taken from a comment on this question). In particular, since it avoids misuse of the LD_LIBRARY_PATH environment variable. See here and here, for why I believe it's misused to solve the problem at hand.
My gcc compiler is at a custom location /my/path/hpgcc
I've downloaded the boost sources. Executed bootstrap.sh, but it fails because it runs with the default gcc.
Looking into it, I see that it fails at the first thing it does: building the Boost.Build engine:
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
(fails because executed with the default gcc, and not my gcc version).
I've tried to change the gcc path in the user-config.jam file, but it doesn't help. Probably because the Boost.Build's build script boost_1_47_0/tools/build/v2/engine/build.sh doesn't use user-config.jam, and just uses the default locations.
Any solution?
Add the line:
using gcc : : /my/path/hpgcc ;
to user-config.jam. user-config.jam will usually be in /path/to/boost/tools/build/v2/, but you can put a custom user-config.jam or site-config.jam in any of the places listed here.
/my/path/hpgcc should be the full path to the g++ executable.
EDIT (Igor Oks) : What eventually solved the problem is that I edited boost_1_47_0/tools/build/v2/engine/build.sh to make it use my custom gcc.
We do this in our build environment by simply defining the PATH and LD_LIBRARY_PATH environment variables to pickup our desired GCC first.
I want to use CUDPP library in my project. I've downloaded sources from project page. Unfortunatly, when I ran "make", there was only static library build. I've looked into Makefile files and haven't found any dynamic lib configuration. I don't want to keep static library with the project - it's totally non-portable way.
My question is: how can I build .so dynamic library of CUDPP, without writing my own Makefile/compiling it manually? Maybe someone already did it?
EDIT: I've replaced "g++" with "g++ -fPIC", "gcc" with "gcc -fPIC" and "nvcc" with "nvcc -Xcompiler -fpic". When I unpack obj files from archive, and link them to shared lib, I've got no error. However, my application crashes at start, when linked with this library.
when you compile pass the flag -Xcompiler -fpic to nvcc. If you link against any cuda libraries make sure you've linked to the shared libs, otherwise you can't link it. Hopefully that's all you need.
Are you also using -shared to create the library? You shouldn't need to extract anything from an archive if it is working correctly.
If you run ldd on your executable it will show you what dynamic linking is required by the app and you can check that the -fPIC etc. worked correctly. Also make sure that the .so library is on your LD_LIBRARY_PATH (sorry if that's obvious, no harm in checking).