I am trying to generate a .gir-file from a very simple library; it's basically the GObject example from the GLib documentation. When using g-ir-scanner, it fails with the follwing error:
$ g-ir-scanner -I./ --library=foo --library-path=./ --pkg=gobject-2.0 --namespace=Foo -o foo-bar.gir foo-bar.c foo-bar.h
g-ir-scanner: compile: gcc -Wall -pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64- linux-gnu/glib-2.0/include -I./ -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib- 2.0/include -c -o /home/roman/Documents/own_gobject/tmp-introspectEx3pzw/Foo-None.o /home/roman/Documents/own_gobject/tmp-introspectEx3pzw/Foo-None.c
g-ir-scanner: link: gcc -o /home/roman/Documents/own_gobject/tmp-introspectEx3pzw/Foo-None /home/roman/Documents/own_gobject/tmp-introspectEx3pzw/Foo-None.o -L. -Wl,-rpath=. - lfoo -L./ -Wl,--export-dynamic -pthread -lgio-2.0 -lgmodule-2.0 -lrt -lgobject-2.0 -lglib-2.0
ERROR: can't resolve libraries to shared libraries: foo
I have really no idea what went wrong. Any ideas?
This is a bug in g-ir-scanner (https://bugzilla.gnome.org/show_bug.cgi?id=699442). Basically foo-bar does not contain any GObject classes and it has failed. A class is detected by having a function called foo_blah_get_type().
the --library argument of g-ir-scanner needs the name of the shared object - for instance, libfoo.so, or libfoo.la if you're using libtool in your build environment.
Related
I'm trying to compile the PCL 1.8 and get the following error:
/usr/lib/x86_64-linux-gnu/libpq.so.5: undefined reference to `SSL_get_peer_certificate#OPENSSL_1.0.0'
/usr/lib/libvtkIO.so.5.10.1: undefined reference to `TIFFReadDirectory#LIBTIFF_4.0'
If i list the dependencies of /usr/lib/x86_64-linux-gnu/libpq.so.5 I get libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0, which is readelf -h /lib/x86_64-linux-gnu/libssl.so.1.0.0 | grep Class\|File\|Machine':
Class: ELF64
Machine: Advanced Micro Devices X86-64
However, I seem to have more libpq versions installed:
/home/t/anaconda2/lib/libssl.so.1.0.0
/home/t/anaconda2/pkgs/openssl-1.0.2j-0/lib/libssl.so.1.0.0
/home/t/matlab/R2015a/bin/glnxa64/libssl.so.1.0.0
/lib/i386-linux-gnu/libssl.so.1.0.0
/lib/x86_64-linux-gnu/libssl.so.1.0.0
with /lib/i386-linux-gnu/libssl.so.1.0.0 being
Class: ELF32
Machine: Intel 80386
And:
[ 12%] Linking CXX executable ../../bin/pcl_convert_pcd_ascii_binary
cd /pcl/build/io/tools && /usr/bin/cmake -E cmake_link_script CMakeFiles/pcl_con
vert_pcd_ascii_binary.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++11 -pthread -fopenmp -Wno-deprecated -O2 -g -DNDEB
UG CMakeFiles/pcl_convert_pcd_ascii_binary.dir/convert_pcd_ascii_binary.cpp.o
-o ../../bin/pcl_convert_pcd_ascii_binary -rdynamic -lboost_system -lboost_fil
esystem -lboost_thread -lboost_date_time -lboost_iostreams -lboost_chrono -lboos
t_atomic -lboost_regex -lpthread -lpthread -lm ../../lib/libpcl_io.so.1.8.0 ../.
./lib/libpcl_common.so.1.8.0 ../../lib/libpcl_io_ply.so.1.8.0 -lboost_system -lb
oost_filesystem -lboost_thread -lboost_date_time -lboost_iostreams -lboost_chron
o -lboost_atomic -lboost_regex -lpthread /usr/lib/libvtkGenericFiltering.so.5.10
.1 /usr/lib/libvtkGeovis.so.5.10.1 -lm /usr/lib/libvtkCharts.so.5.10.1 /usr/lib/
libvtkViews.so.5.10.1 /usr/lib/libvtkInfovis.so.5.10.1 /usr/lib/libvtkWidgets.so
.5.10.1 /usr/lib/libvtkVolumeRendering.so.5.10.1 /usr/lib/libvtkHybrid.so.5.10.1
/usr/lib/libvtkParallel.so.5.10.1 /usr/lib/libvtkRendering.so.5.10.1 /usr/lib/l
ibvtkImaging.so.5.10.1 /usr/lib/libvtkGraphics.so.5.10.1 /usr/lib/libvtkIO.so.5.
10.1 /usr/lib/libvtkFiltering.so.5.10.1 /usr/lib/libvtkCommon.so.5.10.1 -lm /usr
/lib/libvtksys.so.5.10.1 -ldl /anaconda2/lib/libpng.so /anaconda2/lib/libz.so -l
usb-1.0 -Wl,-rpath,/pcl/build/lib:/usr/lib/openmpi/lib:/anaconda2/lib: -Wl,-rpat
h-link,/usr/lib/openmpi/lib
//usr/lib/x86_64-linux-gnu/libpq.so.5: undefined reference to `SSL_get_peer_cert
ificate#OPENSSL_1.0.0'
Guess the /anaconda2/lib shouldn't be there?
How I can make sure that CMake links to the correct version (and remove the wrong version)?
I managed to compile it removing anaconda from the PATH, and changing all values having a path to anaconda to lib/x86_64-linux-gnu/ in cmake-gui
I had this problem but I to compile it removing anaconda from the PATH, and delete build file, then redo cmake, then make.
I'm trying to load a library to Firefox, and I get the following error in the terminal:
http://pastebin.com/ZLryd20D,
gcc -Wall -fPIC -c 11.cpp ,
gcc -shared -o libshared.so 11.o -ldl ,
LD_PRELOAD=$PWD/libshared.so firefox ,
/bin/sh: symbol lookup error: /home/enigma/Desktop/compilacionproceso/libshared.so: undefined symbol: __gxx_personality_v0
gcc -shared -o libshared.so 11.o -ldl -lstdc++
That's the wrong solution, that happens to work on Linux by accident.
The correct command line to build your shared library is:
g++ -shared -o libshared.so 11.o
(contrary to popular belief, gcc and g++ are not the same thing).
Answer from the OP himself, taken from a revision of the question:
I solved the problem adding a flag -lstdc++ for create the library
thanks to this post
What is __gxx_personality_v0 for?
cd /directory
gcc -Wall -fPIC -c 11.cpp
gcc -shared -o libshared.so 11.o -ldl -lstdc++
LD_PRELOAD=$PWD/libshared.so program
I need some help with a linker error I get during installation of an Rcpp package on a linux system where I don't have admin rights. In a nutshell, I get this error:
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
I have a file solve.cpp that uses external library interp2d, which in turn has a GSL dependency. I specify my dependencies via [[Rcpp::depends(RcppArmadillo,RcppGSL)]] and in the DESCRIPTION. My Makevars is like the one from the RcppGSL package, with the addition of the linterp2d flag:
PKG_CPPFLAGS = -W $(GSL_CFLAGS) $(LOCAL_INCLUDE)
PKG_LIBS += $(GSL_LIBS) $(LOCAL_LIBS) -linterp2d $(RCPP_LDFLAGS)
where I define the environement variables
export LOCAL_INCLUDE="-I/data/uctpfos/local/include/"
export LOCAL_LIBS="-L/data/uctpfos/local/lib/"
on the system.
I do R CMD INSTALL bkPackage and see:
g++ -I/cm/shared/apps/R/3.0.1/lib64/R/include -DNDEBUG -W -I/cm/shared/apps/gsl/1.15/include -I/data/uctpfos/local/include -fPIC -I/usr/local/include -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/Rcpp/include" -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/RcppArmadillo/include" -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/RcppGSL/include" -fpic -O3 -fPIC -c RcppExports.cpp -o RcppExports.o
g++ -I/cm/shared/apps/R/3.0.1/lib64/R/include -DNDEBUG -W -I/cm/shared/apps/gsl/1.15/include -I/data/uctpfos/local/include -fPIC -I/usr/local/include -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/Rcpp/include" -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/RcppArmadillo/include" -I"/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/RcppGSL/include" -fpic -O3 -fPIC -c solve.cpp -o solve.o
The problems appears after that in the linking step:
g++ -shared -L/usr/local/lib64 -o bkPackage.so RcppExports.o solve.o -L/cm/shared/apps/gsl/1.15/lib -lgsl -lgslcblas -lm -L/data/uctpfos/local/lib -linterp2d -L/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/Rcpp/lib -lRcpp -Wl,-rpath,/data/uctpfos/R/x86_64-unknown-linux-gnu-library/3.0/Rcpp/lib
The error follows as:
/usr/bin/ld: /data/uctpfos/local/lib/libinterp2d.a(interp2d_spline.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/data/uctpfos/local/lib/libinterp2d.a: could not read symbols: Bad value
As you can see I compiled this with -fPIC, so that can't be it.
It's complaining that libinterp2d.a was not compiled with -fPIC; are you sure that was also compiled with -fPIC on?
Also, it seems you both have -fpic and -fPIC in your flags; you probably just want -fPIC. I think R actually ensures that's on by default.
I am making use of a logging library, named liblogger, (that I've implemented) within another library, libmsg. For both of them, I'm using the autotools. I successfully install the liblogger library in my system, under the /usr/local/lib directory.
Within the configure.ac script of the other libmsg, I verify that liblogger is installed in the system, as follows:
AC_CHECK_LIB([logger],
[log_init],
[],
[
echo "Error: Could not find liblogger."
exit 1
])
And add the "-L/usr/local/lib" path to the LDFLAGS variable.
The AC_CHECK_LIB test finds the library, and both the libmsg library and its check_PROGRAMS using are successfully compiled.
However, when I try to execute the test programs, I get the error:
error while loading shared libraries: liblogger.so.0: cannot open shared object file: No such file or directory
Indeed, ldd does not find the library either:
$ ldd msgs
linux-vdso.so.1 => (0x00007fff543ff000)
liblogger.so.0 => not found
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fdf329ad000)
But the library is actually there, in /usr/local/lib.
For linking the test program, libtool is being called with the instruction:
$ /bin/bash ../libtool --tag=CC --mode=link gcc -I../include -I../msg -L/usr/local/lib -O2 -Wall -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/local/include -I/usr/local/lib -L/usr/local/lib -o msgs msgs.o message.o base64.o misc.o -llogger -lglib-2.0
Which actually echoes the following:
libtool: link: gcc -I../include -I../msg -O2 -Wall -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/local/include -I/usr/local/lib -o msgs msgs.o message.o base64.o misc.o -L/usr/local/lib /usr/local/lib/liblogger.so -lglib-2.0
So, the -llogger flag is being substituted by -L[..] /usr/local/liblogger.so (I suppose this is a correct behavior? I haven't been able yet to determine it...)
Actually, if I call the test program with:
LDPRELOAD=/usr/local/lib/liblogger.so msgs
It actually works.
Can anyone tell me what is it what I'm missing?
You need to check if:
/usr/local/lib is in /etc/ld.so.conf (it usually is these days).
ldconfig was run when you installed liblogger. If not, run it.
liblogger.so.0 is actually in /usr/local/lib.
I want to use one program as a shared library for an other program.
I started as follows:
I have a application which I have compiled using:
/usr/bin/g++ -I/usr/include/libxml2 -Xlinker -zmuldefs -fPIC -c a.cpp
/usr/bin/g++ -I/usr/include/libxml2 -Xlinker -zmuldefs -fPIC -c b.cpp
/usr/bin/g++ -I/usr/include/libxml2 -Xlinker -zmuldefs -fPIC -c c.cpp
Then I have created a shared object library from the objects I get from this file using this command:
g++ -fPIC -Xlinker -zmuldefs -shared -o libabc.so a.o b.o c.o
After this I get the libabc.so file which I copy to the
sudo cp libabc.so /usr/local/lib/libabc.so
Now when I compile my orignal application which will use this newly created library libabc.so using this command:
/usr/local/lib/libabd.so: undefined reference to `xmlXPathNewContext'
I get errors for all the functions I used from the included library libxml2 in the first application and the function which has this undefined reference is actually the library I include in the first program I mean I have tested it.
So kindly anyone guide me where I need corrections.
You may have to pass the path also using -I/path/to/library, or alternatively export it to LD_LIBRARY_PATH.
I don't see the command line that you used to link your application against your library, but I suppose that adding -lxml2 to the flags passed to the linker should solve the problem.