xerces-c 2.8 : error while loading shared libraries - c++

I'm trying to compile a program running on an HP UX server on a Red Hat Linux.
It uses xerces-c library to parse xml files. Compilation is ok, but when i try to run it, I get the following message
./a.out: error while loading shared
libraries: libxerces-c.so.28: cannot
open shared object file: No such file
or directory
I wrote a very simple program to try and understand whats going on:
#include <xercesc/util/PlatformUtils.hpp>
#include <xercesc/util/TransService.hpp>
#include <xercesc/parsers/SAXParser.hpp>
#include <xercesc/util/OutOfMemoryException.hpp>
int main(int argc, char* argv[])
{
return 0;
}
And compiled it like this:
g++ test.cpp
-L./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
Surprisingly the file is actually there:
lib]$ ls
libxerces-c.a libxerces-c.so.28 libxerces-depdom.a libxerces-depdom.so.28
libxerces-c.so libxerces-c.so.28.0 libxerces-depdom.so libxerces-depdom.so.28.0
Any thoughts ? I feel i'm missing something, but don't know what.
Thanks in advance.

run ldd a.out and see if the linker can resolve the right .so file
export LD_LIBRARY_PATH to include the current folder (in the same manner as the PATH variable) and check ldd again

the good way to do what you want is the following one:
g++ test.cpp -Xlinker -R ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
or
g++ test.cpp -Wl,-rpath ./xml/xerces-c_2_8_0/lib -lxerces-c -I./xml/xerces-c_2_8_0/include
Xlinker or Wl options allow you to use specific linking options, you do not need to modifiy
LD_LIBRARY_PATH

You need to tell the runtime c library where to find the various symbols that arent compiled statically in your code and arent in the usualy /lib and /usr/lib locations.
You do this by adding the path to your shared library to LD_LIBRARY_PATH. In this case, this will be what you have been putting for the -L argument to the compiler.

Related

How to link to shared object library in msys2?

I have some c++ code in msys2 that I am trying to link dynamically to show how a dynamic link library works.
In linux, showing the call is no problem. stepping in gdb, we can watch the call go through the jump vector, eventually landing in the desired function.
But in msys2, they wanted to eliminated dlls and all the libraries I can find are .dll.a, I think they are really static libraries.
I build a trivial little function like this:
#include <cstdint>
extern "C" {
uint64_t f(uint64_t a, uint64_t b) {
return a + b;
}
}
compiling in the makefile with:
g++ -g -fPIC -c lib1.cc
g++ -g -shared lib1.o -o libtest1.so
When I run the file utility, it says that:
libtest1.so: PE32+ executable (DLL) (console) x86-64, for MS Windows
When I compile the code using it:
g++ -g main.cc -ltest1 -o prog
The error is -ltest1 no such file or directory.
MinGW uses the .dll extension for shared libraries, not .so.
lib??.dll.a is an import library, a shim that will load the corresponding lib??.dll at runtime.
At some point in time, you couldn't link .dlls directly, and had to link .dll.as instead. The modern MinGW can link .dlls directly, so you shouldn't need to use import libraries anymore.
-ltest1 no such file or directory
Wouldn't you get the same error on Linux? You have to specify the library search path with -L. -ltest1 needs either libtest1.a or libtest1.dll.a or libtest1.dll (perhaps some other variants are checked too).
The reason your linker cannot find the library is because your current working directory is not in the search path for libraries. Add -L. to your linking command.
It is untrue that MSYS2 "wanted to eliminate DLLs". Just run ls /mingw64/bin/*.dll and you will see plenty of DLLs (assuming you have some MINGW64 packages installed). The .dll.a files used for linking are called import libraries.

C++ Executable cannot find library at runtime, even though it's in /usr/lib (On Linux)

I'm creating a game in c++ with the Panda3D framework on Ubuntu. All of the Panda3D shared libraries are in /usr/lib/panda3d and all of the headers are in /usr/include/panda3d. I'm compiling with SCons, but I've tried it with gcc and it's the same, so here are the commands:
g++ -o src/main.o -c -fPIC -O2 -std=gnu++11 -I/usr/include/python2.7 -I/usr/include/panda3d -Iinclude src/main.cpp
g++ -o Test src/main.o -L/usr/lib/panda3d -lp3framework -lpanda -lpandafx -lpandaexpress -lpandabullet -lp3dtoolconfig -lp3dtool -lp3direct -lpthread
And here is the error I get when I run the executable:
./Test: error while loading shared libraries: libp3framework.so.1.11: cannot open shared object file: No such file or directory
There isn't much in the code, just initializing a Panda3D window, so I doubt that's the culprit.
As I said before, the libraries are in /usr/lib/panda3d, I've checked about a million times now and it's driving me crazy. I can't think of a single reason why I would get this error. Any help is appreciated :)
Edit:
I was looking through my files and there's a panda3d.conf file in /etc/ld.so.conf.d with one line: /usr/local/lib/x86_64-linux-gnu/panda3d. Does this have anything to do with it?
Edit #2:
I used the path in the above edit as the library path and got the same results, unfortunately.
I can't think of a single reason why I would get this error.
The reason is very simple: the dynamic loader hasn't been told to look in /usr/lib/panda3d for shared libraries, and so doesn't.
You can run your program with:
LD_DEBUG=files,libs ./Test
and observe which directories the loader is searching.
panda3d.conf ... with one line: /usr/local/lib/x86_64-linux-gnu/panda3d
That is the wrong directory (or at least not the one where your libraries are).
One way to fix this is to correct the above path to /usr/lib/panda3d and run sudo ldconfig.
Another way is to add -Wl,-rpath=/usr/lib/panda3d to your link line.

Executing cross-compiled C++ program using Boost on Raspberry Pi

I have built a GCC cross toolchain for the RPi and can cross-compile C++ source and successfully run it after copying the executable to the RPi.
Next I built the Boost libraries targeting ARM, using the cross toolchain. I can successfully build and link C++ source to those Boost libraries using the cross toolchain on my PC.
I then copied the program, dynamically linked to Boost, to the RPi and copied all built libraries into /usr/local/lib on the Pi. However, executing fails:
$ ./my_program
./my_program: error while loading shared libraries: libboost_system.so.1.60.0: cannot open shared object file: No such file or directory
Again, this library, libboost_system.so.1.60.0, exists in /usr/local/lib.
I also tried
export LD_LIBRARY_PATH='/usr/local/lib'
but that doesn't change anything. What am I doing wrong?
EDIT:
I build all source files like this (rpi-g++ is a symlink to my cross-compiler):
rpi-g++ -c -std=c++1y -Wall -Wextra -pedantic -O2 -I /path/to/cross/boost/include *.cpp
rpi-g++ -o myprog *.o -L /path/to/cross/boost/lib/ -lboost_system -pthread
EDIT 2:
When linked with
rpi-g++ -o myprog *.o -L /path/to/cross/boost/lib/ -rdynamic -lboost_system -pthread
the problem remains the same. I have checked and verified everything suggested by Technaton as well. Strangely, ldd insists that the created executable is "not a dynamic executable" (checked that on my PC and on the RPi), which doesn't make sense to me.
There are several things you can check. I've posted a complete check list here, but judging from your linker command line, number 5 is probably the culprit.
Check that your library and your program are correctly build for the target architecture. You can verify that by using file ./myprog and file libboost_system.so.1.60.0.
Make sure that you have copied the actual shared object, and not a link to it.
Ensure that the shared object file's permissions are sane (0755).
Run ldconfig -v and check that your shared object file is picked up. Normally, /usr/local/lib is in the standard library search path, and LD_LIBRARY_PATH is not required.
Make sure that your program is actually dynamically linked by running ldd ./myprog. Judging from your linker command line, that is the problem: You're missing -rdynamic.
Check the paths returned from ldd: If you have linked with rpath, the library search path might be screwed up. Try again without -rpath.

Using the c++ Boost regex libraries in Arch Linux

I'm having trouble building a simple c++ program that tests out regex's from the boost library. The problem that I'm having is occurring in the linking stage and I don't know enough to fix the error on my own.
In the .cpp program that uses regexes I used the following include line.
#include <boost/regex.hpp>
I don't know enough to figure out what command I should use to build the program using g++. I tried using the following command line (and variations of it) to build the program.
g++ -I/usr/include/regex -L/usr/lib -llibboost_regex main.cpp -o regex_test
Other information that might be relevant:
Operating system: Arch linux
g++ version: 4.6.2 20120120 (prerelease)
Any help would be appreciated.
Assume you have installed Boost with the boost and boost-libs packages,
The header <boost/regex.hpp> should exist in /usr/include/boost/regex.hpp. You don't need to use any -I flags since /usr/include should be included by default.
You shouldn't need the -L flag either since /usr/lib should also be included by default when linking.
When using the -l flag to link with a library libfoo.so, the leading "lib" part should be removed.
The command line should therefore be:
g++ main.cpp -o regex_test -lboost_regex

Problems compiling gtkmm

OS: Fedora 14
Compiler: g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4)
I installed gtkmm24-devel from repository via yum. To make sure the install went as planned I decided to try one of the examples on the page.
#include <gtkmm.h>
int main(int argc, char *argv[]) {
Gtk::Main kit(argc, argv);
Gtk::Window window;
Gtk::Main::run(window);
return 0;
}
I ran the example, and, hey! It said it couldn't find gtkmm.h, no problem, I just forgot to link the library. I added /usr/include/gtkmm-2.4 to my library search through Eclipse. No bueno, g++ still can't find it!
fatal error: gtkmm.h: No such file or directory
I then try to include gtkmm by using #include <gtkmm-2.4/gtkmm.h> and recompile, another error! :(
/usr/include/gtkmm-2.4/gtkmm.h:87:20: fatal error: glibmm.h: No such file or directory
Thanks for reading.
Short answer
Use the output of 'pkg-config gtkmm-2.4 --cflags' for include paths and 'pkg-config gtkmm-2.4 --libs' for libraries to link.
Long answer
It said it couldn't find gtkmm.h, no problem, I just forgot to link the library.
Building a C/C++ program is done in two separate steps. First the source files are compiled, outputting object files; and then the object files are linked together. The error you are getting comes from the compiling step.
On Linux, most libraries come with pkgconfig files to make it easier for other programs to use the libraries. gtkmm also comes with its own pkgconfig files.
You are trying to manually specify /usr/include/gtkmm-2.4 for include path; this is wrong. Instead, use the output of pkgconfig to figure out where the header files are located. To get all the include directories needed for gtkmm, use the following command:
pkg-config gtkmm-2.4 --cflags
For linking, use the following pkgconfig command to get the libraries you need to link with:
pkg-config gtkmm-2.4 --libs
You can test it on the command line by invoking g++ directly.
g++ myfirstprogram.cpp -o myfirstprogram `pkg-config gtkmm-2.4 --cflags --libs`
For more information, see the gtkmm docs: http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-basics-simple-example.html.en
These steps usually help resolving this problem:
Search your computer for glibmm.h
If found - add its directory to the include path list
If not found - Google for glibmm.h and find out which library it is contained in. You will find out in this case it's (surprise!) glibmm. Install it using your package manager.
The problem, as noted in comments, is a compiler error and the compiler is arguing about a missing (header) file. The steps I described above either find the location of the missing file or help you to install a library that the header file belongs to.