I'm trying to link my code against a shared library ("libX.so") which depends on libcrypto.so. I have libcrypto.so.1.0.0 installed, but it seems to specifically require libcrypto.so.0.9.8. Is there a way to get it to link against 1.0.0? I can't install 0.9.8 on my system (archlinux) without breaking other packages.
/usr/bin/ld: warning: libcrypto.so.0.9.8, needed by /usr/local/lib/libX.so, not found (try using -rpath or -rpath-link)
/usr/local/lib/libX.so: undefined reference to `SHA512#OPENSSL_0.9.8'
...
EDIT:
I should probably add more information. I have tried compiling openssl 0.9.8 and installing to the prefix /usr/local. But even though it seems to find this library, there are still errors when building:
/usr/local/lib/libX.so: undefined reference to `SHA512#OPENSSL_0.9.8'
...
libcrypto does seem to define this:
$ nm /usr/local/ssl/lib/libcrypto.so.0.9.8 | grep SHA512
000000000006f9b0 T SHA512
...
I am using the following script to compile:
export LD_LIBRARY_PATH+=:/usr/local/ssl/lib
gcc -I/usr/local/include/ test.c -o test -lX
And this is the output of ldd on libX:
$ ldd /usr/local/lib/libX.so
/usr/local/lib/libX.so: /usr/local/ssl/lib/libcrypto.so.0.9.8: no version information available (required by /usr/local/lib/libX.so)
libssl.so.0.9.8 => /usr/local/ssl/lib/libssl.so.0.9.8 (0x00007f9c4e329000)
libcrypto.so.0.9.8 => /usr/local/ssl/lib/libcrypto.so.0.9.8 (0x00007f9c4df99000)
...
refer to http://forums.gentoo.org/viewtopic-t-835256-start-0.html
openssl-0.9.8l-sym-version-felixrabe.patch work fine for me!
Because the original OpenSSL library was built with a version script. This is a feature so you can have different versions of the the library and still get the right symbol.
You can add your own looking like this:
OPENSSL_0.9.8 {
*;
};
And then link with --version-script
To make OpenSSL do this you probably need to edit the Makefile.
Related
I am trying to build heimdal package for msys2. To my dismay, during linking of the first constituent library, roken, dlls fail to be built, and that causes sort of a chain reaction further on.
The only message i get is:
libtool: undefined symbols not allowed in x86_64-pc-msys shared ... only static will be built
however, there is no information provided on what symbols are undefined. How can i find that out?
If i turn on output of commands wuth make V=1 i get libtool command that links from a large numbert of .lo files. If i try to run gcc over them (copying command from there), it does not recognize them as anything.
I am trying to follow instructions as outlined in msys2 package build script for heimdal.
On Windows building a shared library while allowing undefined symbols is not allowed.
Try to build with the -Wl,-no-undefined linker flag, for example by adding LDFLAGS="-Wl,-no-undefined" to the ./configure command.
If that didn't work try this after ./configure and before make:
sed -i.bak -e "s/\(allow_undefined=\)yes/\1no/" libtool
If you already had a failed build earlier you should also clean up any .la files like this before running make again:
rm $(find -name '*.la')
I am trying to link a locally installed shared library (./vendor/lib/libfoo.so) with my binary, ./bar. Unfortunately, none of my attempts generates a link with an absolute path to libfoo.so. As a consequence I need to use
LD_LIBRARY_PATH=vendor/lib ./bar
to run it, which I want to avoid. ldd bar shows me this:
linux-vdso.so.1 => (0x00007ffed5fd8000)
libbar.so.2 => not found
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb9ea787000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb9ea47d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb9ea267000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb9e9e9d000)
/lib64/ld-linux-x86-64.so.2 (0x000055f326761000)
A word about libbar.so.2: the file exists (in vendor/lib) alongside libbar.so. Both are actually symlinks to libhts.so.1.6. That file also exists, and is the actual shared library.
Here’s the different ways I’ve tried:
FULL_PATH="$(pwd -P)/vendor/lib"
g++ -o bar bar.o -Lvendor/lib -lfoo # 1
g++ -o bar bar.o -L$FULL_PATH -lfoo # 2
g++ -o bar bar.o $FULL_PATH/libfoo.so # 3
g++ -o bar bar.o $FULL_PATH/libfoo.so.1.6 # 4
All of these variants produce identical ldd output, even the last line (does ld insist on using the highest version of a library?).
The only way I’ve found to make this work is to use
LD_RUN_PATH=$FULL_PATH g++ -o bar bar.o -Lvendor/lib -lfoo
(I can’t use -rpath because my version of g++ doesn’t understand this argument, and I’m using g++ instead of ld to get the libstdc++ dependencies right — I could use -Wl,-rpath of course.)
But I can’t help but feel that there should be a way of making this work without the use of environment variables/-rpath. I’ve found an answer specifically referencing symlinks to libraries but unfortunately it doesn’t help me (see attempt 4 above).
This is on Ubuntu 16.04, g++ 5.4.0, GNU ld 2.26.1, in case it matters.
It sounds likely that you didn't update the ldconfig cache after installing
your shared library in the non-standard location /what/ever/vendor/lib:-
sudo ldconfig /what/ever/vendor/lib
Until you do that the runtime linker will be unaware that libfoo.so is
in /what/ever/vendor/lib, even if it is, unless you prompt it at runtime through
the LD_LIBRARY_PATH environment variable.
Incidentally, it isn't a shortcoming of your version of g++ that it
doesn't recognize -rpath. This has only ever been a linker (ld) option,
never a GCC frontend option. So -Wl,-rpath=/what/ever/vendor/lib is the
conventional way of tacking the non-standard runtime library path to your
program so as to avoid relying on either the ldconfig cache or LD_LIBRARY_PATH
For out-of-the ordinary linkages it may be considered better to use -rpath
rather than extend the ldconfig cache, which has less discriminate effects.
I have written a programm in c++. Linking and runiing is working, as long as I don't use the "-static" option for g++. But I have to run it from an Antergos USB-Live Stick with default settings and there is no GSL included. In the manual of GSL they recommend
$ g++ -c main.cpp
$ g++ -static main.o -lgsl -lgslcblas -lm -lnlopt
But for this code I receive an error message:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
collect2: Fehler: ld gab 1 als End-Status zurück
I tried it as this question, but it didn't work for me. When I run
$ g++ -O2 -o test main.cpp -lgsl -lgslcblas -lnlopt -lm
$ lld test
it prints
linux-vdso.so.1 (0x00007fffa5b95000)
libgsl.so.19 => /usr/lib/libgsl.so.19 (0x00007f8748c9a000)
libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0x00007f8748a5d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f87486d5000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f87483d1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f87481ba000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f8747e1c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f87490fe000)
So I tried to create a symlink, but I do have also "libgsl.so"
$ ls /usr/lib/libgsl
libgslcblas.so libgslcblas.so.0.0.0 libgsl.so.19
libgslcblas.so.0 libgsl.so libgsl.so.19.3.0
Am I doing something stupid? Thank your for your help.
When you pass -lgsl, by default you request the linker to
find and link either the shared library libgsl.so or the static
library libgsl.a and to prefer the shared library, if both are found
in the same search directory. The linker will search, first, in any
directories you have specified with the -L/path/to/search options,
in the order you specified, and then in its default search directories
(/usr/lib, etc.). Likewise for -lgslcblas.
But when you pass the linkage option -static to gcc/g++, it prevents
linking with any shared libraries. Shared libraries, libgsl.so, libgslcblas.so
will be ignored. Static libraries libgsl.a, libgslblas.a, must be
found, in some or other of the search directories, for the linkage to
succeed.
The linker is saying:
/usr/bin/ld: cannot find -lgsl
/usr/bin/ld: cannot find -lgslcblas
because it can't find those static libraries - presumably because you
haven't installed them.
You do not say what linux distro you are working on, but if the package
that provides libgsl and libgslcblas is called, say, libgsl[suffix]
then there will be a corresponding package called libgsl-dev, libgsl-devel,
or similar. This will be the development version of the package,
for the use of people who want to develop software that links with libgsl
or libgslcblas. The development package will require the libgsl package as a dependency
- so it will install the same stuff - and will in addition contain the
library's header files and the static version of the library.
So you need to install the libgsl development package for your distro.
For Ubuntu, for example, that is libgsl-dev:
Later
I gather that your distro, Arch Linux, does not do separate dev packages. You
need to build the static libraries from source. To do that you will need
at least to have installed:
GNU Make
GNU autotools (autoconf, automake, libtool)
GCC (C compiler)
texinfo
Then to make a default build:
Get the gsl source package from https://savannah.gnu.org/git/?group=gsl
either by cloning the git repo or downloading a current tar.gz tarball
and extracting it.
cd into the package directory.
run ./autogen.sh. This will succeed provided the GNU autotools prerequisites
are fulfilled.
run ./configure --enable-maintainer-mode (as ./autogen.sh will have prompted you).
This will succeed provided that the package dependencies are satisfied
and environment sanity checks pass.
run make
If make completes without errors - which will take a matter of minutes -
then, as root, run make install.
If all is well, this will install your missing static libraries:
/usr/local/lib/libgsl.a
/usr/local/lib/libgslcblas.a
You should not need to modify your linkage command for the linker to find
them: /usr/local/lib is a default linker search path.
I am new to g++ and lapack, and attempting to use them. I encountered a problem when I tried to compile the following naive code
#include <lapackpp.h>
int main()
{
LaGenMatDouble A;
return 0;
}
If I run the command
$g++ -L/usr/local/lib -llapackpp test2.cpp
where test2.cpp is the name of the cpp file, the terminal would give an error:
test2.cpp:1:22: fatal error: lapackpp.h: No such file or directory
But if I run the command:
$g++ -I/usr/local/include/lapackpp -L/usr/local/lib -llapackpp test2.cpp
the terminal would give an error:
/tmp/ccUi11DG.o: In function `main':
test2.cpp:(.text+0x12): undefined reference to `LaGenMatDouble::LaGenMatDouble()'
test2.cpp:(.text+0x23): undefined reference to `LaGenMatDouble::~LaGenMatDouble()'
collect2: ld returned 1 exit status
BTW, if I run the command
$pkg-config lapackpp --libs
the result is
-L/usr/local/lib -llapackpp
Could you please help me solve this? Thanks in advance!
Lapack requires fortran libraries, so that's where the -lgfortran comes from. Moreover, it appears the exact way to provide that library for the compiler depends on the Linux distriburion. From the documentation:
Requirements
This package requires the packages "blas", "lapack" (without the "++"), and a Fortran compiler. On most Linuxes these are available as pre-compiled binaries under the name "blas" and "lapack". For SuSE 10.x, the Fortran compiler is available as package "gfortran". For SuSE 9.x, the Fortran compiler is available as package "gcc-g77".
Not sure why pkg-config lapackpp --libs does not list -lgfortran
The -I/usr/local/include/lapackpp specifes the lapackpp-related header files. Without it the compiler cannot find lapackpp.h when you try to include it (#include <lapackpp.h>) -- see the compiler error in your question
I finally solved the problem but would still wonder why it has to be so.
The only command that can link cpp file to lapackpp library is:
g++ foo.cpp -o foo -lgfortran -llapackpp -I/usr/local/include/lapackpp
It would not work without -lgfortran, or with -I/usr/local/include/lapackpp replaced by -L/usr/local/lib.
Does anyone have an answer?
I'm failing to compiled the rabbitmq-c library on Mac OS 10.6.6
I intend to build the php-ampq extension against it.
I've tried both the latest branch of rabbitmq-c and rabbitmq-codegen according to the instructions here and the specific branches according to the instructions here.
Running autoreconf -i as per instructions I get:
glibtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
glibtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.ac:12: installing `./config.sub'
configure.ac:12: required file `./ltmain.sh' not found
configure.ac:3: installing `./missing'
configure.ac:3: installing `./install-sh'
configure.ac:12: installing `./config.guess'
examples/Makefile.am: installing `./depcomp'
autoreconf: automake failed with exit status: 1
Running simply autoconf I get:
configure.ac:3: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:12: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:90: error: possibly undefined macro: AM_CONDITIONAL
Most of what I can find by searching online suggests I don't have libtool or automake. I have both.
I'm afraid I'm out of my depth with autoconf, so I don't know how/where to alter configure.ac, or whether the warning is anything do with the missing ltmain.sh file.
I solved the same problem by installing pkg-config:
sudo port install pkgconfig