An executable seemingly can't resolve a symbol in a linked library. The relevant output of LD_DEBUG=libs shows that the correct library is loaded:
6557: /usr/lib/libcharon.so.0: error: symbol lookup error: undefined symbol: auth_class_names (fatal)
/usr/libexec/ipsec/charon: symbol lookup error: /usr/lib/libcharon.so.0: undefined symbol: auth_class_names
nm -D shows that the symbol auth_class_names is defined:
nm -D /usr/lib/libcharon.so.0|grep auth_class_names
U auth_class_names
EDIT: Outputs of ldd added:
/usr/lib# ldd /usr/lib/libstrongswan.so
libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xb6ecd000)
libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xb6ec2000)
librt.so.1 => /lib/arm-linux-gnueabi/librt.so.1 (0xb6eb3000)
libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xb6d78000)
/lib/ld-linux.so.3 (0xb6f25000)
/usr/lib# ldd /usr/lib/libcharon.so
libm.so.6 => /lib/arm-linux-gnueabi/libm.so.6 (0xb6ea6000)
libpthread.so.0 => /lib/arm-linux-gnueabi/libpthread.so.0 (0xb6e86000)
libdl.so.2 => /lib/arm-linux-gnueabi/libdl.so.2 (0xb6e7b000)
libcap.so.2 => /lib/arm-linux-gnueabi/libcap.so.2 (0xb6e70000)
libc.so.6 => /lib/arm-linux-gnueabi/libc.so.6 (0xb6d35000)
/lib/ld-linux.so.3 (0xb6fa6000)
libattr.so.1 => /lib/arm-linux-gnueabi/libattr.so.1 (0xb6d27000)
# nm -D /usr/lib/libstrongswan.so|grep auth_class
00036a50 D auth_class_names
nm -D shows that the symbol auth_class_names is defined
No: it shows that auth_class_names is undefined in libcharon.so.
libstrongswan provides the auth_class symbol, but libcharon doesn't reference it.
Wrong again: libcharon.so does reference the symbol.
ldd /usr/lib/libstrongswan.so
That's not what you want. You want ldd /usr/lib/libcharon.so.
Your problem is most likely that neigher libcharon.so, nor the main executable were linked against libstrongswan.so, so when you dynamically load libcharon.so, libstrongswan.so is nowhere to be found; hence the loading fails with undefined symbol.
There are several possible solutions, ordered from more correct to more hacky:
Link libcharon.so against libstrongswan.so. Loading libcharon.so will load all of its dependencies (which will now include libstrongswan.so, and the symbol will be found).
Link charon binary against libstrongswan.so.
Dynamically load libstrongswan.so before you load libcharon.so.
LD_PRELOAD=libstrongswan.so
Actually "U" means, that symbol is undefined. What does ldd show on your libcharon.so.0? libstrongswan.so.0 is where you should find auth_class_names.
Related
I'm trying to run google assistant on my raspberry pi following the steps on: https://developers.google.com/assistant/sdk/guides/service/python/embed/run-sample
all works fine until activating the Google Assistant with the command:
googlesamples-assistant-pushtotalk --project-id my-dev-project --device-model-id my-model
I'm getting the following ImportError:
Traceback (most recent call last):
File "/home/pi/env/bin/googlesamples-assistant-pushtotalk", line 5, in <module>
from googlesamples.assistant.grpc.pushtotalk import main
File "/home/pi/env/lib/python3.9/site-packages/googlesamples/assistant/grpc/pushtotalk.py", line 28, in <module>
import grpc
File "/home/pi/env/lib/python3.9/site-packages/grpc/__init__.py", line 22, in <module>
from grpc import _compression
File "/home/pi/env/lib/python3.9/site-packages/grpc/_compression.py", line 15, in <module>
from grpc._cython import cygrpc
ImportError: /home/pi/env/lib/python3.9/site-packages/grpc/_cython/cygrpc.cpython-39-arm-linux-gnueabihf.so: undefined symbol: __atomic_exchange_8
Any ideas on how to fix this?
just ended up here since I ran into the same problem (on a different project) but also involving python3.9, cygrpc on a RPi4 with a recent raspbian-lite (32bit).
While I don't have a solution here are my guesses:
formerly __atomic_exchange_8 was defined in /lib/arm-linux-gnueabihf/libgcc_s.so.1 but now it seems defined in libatomic:
$ grep __atomic_exchange_8 /lib/arm-linux-gnueabihf/libatomic.so.1
grep: /lib/arm-linux-gnueabihf/libatomic.so.1: binary file matches
EDIT:
Solved it. I was looking at the patch which tried to solve the problem two years ago:
https://github.com/grpc/grpc/pull/20514/commits/b912fc7d8d401bb65b3147ee77d03beaa3d46038
I figured their test check_linker_need_libatomic() might be broken, and patched it again to always return True, the problem got fixed.
Had tried earlier to fix it by adding CFLAGS='-latomic' CPPFLAGS='-latomic' but that didn't help.
here's my tiny workaround (not fix!) for today's grpc git HEAD:
root#mypi:/home/pi/CODE/grpc# git diff
diff --git a/setup.py b/setup.py
index 1a72c5c668..60b7705cd2 100644
--- a/setup.py
+++ b/setup.py
## -197,6 +197,7 ## ENABLE_DOCUMENTATION_BUILD = _env_bool_value(
def check_linker_need_libatomic():
"""Test if linker on system needs libatomic."""
+ return True
code_test = (b'#include <atomic>\n' +
b'int main() { return std::atomic<int64_t>{}; }')
cxx = os.environ.get('CXX', 'c++')
diff --git a/tools/distrib/python/grpcio_tools/setup.py b/tools/distrib/python/grpcio_tools/setup.py
index 6b842f56b9..8d5f581ac7 100644
--- a/tools/distrib/python/grpcio_tools/setup.py
+++ b/tools/distrib/python/grpcio_tools/setup.py
## -85,6 +85,7 ## BUILD_WITH_STATIC_LIBSTDCXX = _env_bool_value(
def check_linker_need_libatomic():
"""Test if linker on system needs libatomic."""
+ return True
code_test = (b'#include <atomic>\n' +
b'int main() { return std::atomic<int64_t>{}; }')
cxx = os.environ.get('CXX', 'c++')
root#mypi:/home/pi/CODE/grpc#
EDIT:
as a quick test, cygrpc.cpython-39-arm-linux-gnueabihf.so needs to depend on libatomic:
pi#mypi:~/CODE/grpc $ ldd /usr/local/lib/python3.9/dist-packages/grpc/_cython/cygrpc.cpython-39-arm-linux-gnueabihf.so
linux-vdso.so.1 (0xbeef7000)
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb698b000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb695f000)
libatomic.so.1 => /lib/arm-linux-gnueabihf/libatomic.so.1 (0xb6946000)
libstdc++.so.6 => /lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb67be000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb674f000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb65fb000)
/lib/ld-linux-armhf.so.3 (0xb6fcc000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb65ce000)
This works for me on RPI0 + Bullseye + Python3.9:
pip3 uninstall -y grpcio grpcio-tools
sudo apt install -y python3-grpcio python3-grpc-tools
EDIT: Update to gRPC v1.44.0. The issue has been fixed there, see the explanation below in the old answer.
There was a problem with the order of the parameters used by the compiler to compile some test code which result is used to determine whether libatomic needs to be linked or not.
The issue will be fixed with the next release of grpc. If they maintain the same schedule of previous releases it should be v1.44.0 which should come out some time the next month.
In the mean time you can git cherry-pick the proper fix and build grpc yourself
I am trying to run stack build and get the following errors:
bartosz $ stack setup
The GHC located at /Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc failed to compile a sanity check. Please see:
http://docs.haskellstack.org/en/stable/install_and_upgrade/
for more information. Exception was:
Received ExitFailure 1 when running
Raw command: /Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc /private/var/folders/rj/vrrtj8094qb8gf4ky_r_mxq80000gn/T/stack-sanity-check4255/Main.hs -no-user-package-db
Run from: /private/var/folders/rj/vrrtj8094qb8gf4ky_r_mxq80000gn/T/stack-sanity-check4255/
Standard output:
[1 of 1] Compiling Main ( /private/var/folders/rj/vrrtj8094qb8gf4ky_r_mxq80000gn/T/stack-sanity-check4255/Main.hs, /private/var/folders/rj/vrrtj8094qb8gf4ky_r_mxq80000gn/T/stack-sanity-check4255/Main.o )
Linking /private/var/folders/rj/vrrtj8094qb8gf4ky_r_mxq80000gn/T/stack-sanity-check4255/Main ...
Standard error:
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
Undefined symbols for architecture x86_64:
"_iconv", referenced from:
_hs_iconv in libHSbase-4.11.1.0.a(iconv.o)
(maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure, _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , _base_GHCziIOziEncodingziIconv_iconvEncoding_info , _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _hs_iconv_close , _hs_iconv , _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure )
"_iconv_open", referenced from:
_hs_iconv_open in libHSbase-4.11.1.0.a(iconv.o)
(maybe you meant: _hs_iconv_open)
"_iconv_close", referenced from:
_hs_iconv_close in libHSbase-4.11.1.0.a(iconv.o)
(maybe you meant: _hs_iconv_close)
"_locale_charset", referenced from:
_localeEncoding in libHSbase-4.11.1.0.a(PrelIOUtils.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
`gcc' failed in phase `Linker'. (Exit code: 1)
Here is the output from stack path:
stack-root: /Users/evanzamir/.stack
project-root: /Users/evanzamir/Code/Haskell/bartosz
config-location: /Users/evanzamir/Code/Haskell/bartosz/stack.yaml
bin-path: /Users/evanzamir/.stack/snapshots/x86_64-osx/lts-12.17/8.4.4/bin:/Users/evanzamir/.stack/compiler-tools/x86_64-osx/ghc-8.4.4/bin:/Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/bin:/Library/Frameworks/Python.framework/Versions/3.6/bin:/usr/local/bin/stack:/usr/local/smlnj-110.77/bin:/opt/local/bin:/opt/local/sbin:/Library/Frameworks/Python.framework/Versions/3.6/bin:/Users/evanzamir/.rvm/gems/ruby-1.9.3-p327/bin:/Users/evanzamir/.rvm/gems/ruby-1.9.3-p327#global/bin:/Users/evanzamir/.rvm/rubies/ruby-1.9.3-p327/bin:/Users/evanzamir/.rvm/bin:/usr/local/smlnj-110.77/bin:/opt/local/bin:/opt/local/sbin:/usr/local/share/npm/bin/jitsu :/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/sbin:/usr/local/share/npm/bin:/usr/local/sbin:/usr/local/share/npm/bin
programs: /Users/evanzamir/.stack/programs/x86_64-osx
compiler-exe: /Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/bin/ghc
compiler-bin: /Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/bin
compiler-tools-bin: /Users/evanzamir/.stack/compiler-tools/x86_64-osx/ghc-8.4.4/bin
local-bin: /Users/evanzamir/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /Users/evanzamir/.stack/snapshots/x86_64-osx/lts-12.17/8.4.4/pkgdb
local-pkg-db: /Users/evanzamir/Code/Haskell/bartosz/.stack-work/install/x86_64-osx/lts-12.17/8.4.4/pkgdb
global-pkg-db: /Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/lib/ghc-8.4.4/package.conf.d
ghc-package-path: /Users/evanzamir/Code/Haskell/bartosz/.stack-work/install/x86_64-osx/lts-12.17/8.4.4/pkgdb:/Users/evanzamir/.stack/snapshots/x86_64-osx/lts-12.17/8.4.4/pkgdb:/Users/evanzamir/.stack/programs/x86_64-osx/ghc-8.4.4/lib/ghc-8.4.4/package.conf.d
snapshot-install-root: /Users/evanzamir/.stack/snapshots/x86_64-osx/lts-12.17/8.4.4
local-install-root: /Users/evanzamir/Code/Haskell/bartosz/.stack-work/install/x86_64-osx/lts-12.17/8.4.4
snapshot-doc-root: /Users/evanzamir/.stack/snapshots/x86_64-osx/lts-12.17/8.4.4/doc
local-doc-root: /Users/evanzamir/Code/Haskell/bartosz/.stack-work/install/x86_64-osx/lts-12.17/8.4.4/doc
dist-dir: .stack-work/dist/x86_64-osx/Cabal-2.2.0.1
local-hpc-root: /Users/evanzamir/Code/Haskell/bartosz/.stack-work/install/x86_64-osx/lts-12.17/8.4.4/hpc
local-bin-path: /Users/evanzamir/.local/bin
ghc-paths: /Users/evanzamir/.stack/programs/x86_64-osx
Been trying to figure this out all day. I'm on OS X Mojave 14.1. I've tried installing stack using the script, Brew, directly from the binary, and even the Haskell Platform installer, and all are giving me errors.
I have a 3.4 Kernel Linux Virtual Machine and I want to run a compiled ELF Binary.
bash-4.3# file insane
insane: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0d449c7f73019c2ac7708f6bd0b21558da139135, stripped
I have compiled it on Ubuntu 32 Bit and now I want to run it on an Unix i386 virtual machine with Linux Kernel 3.4.0
ldd on the Unix image where it's not working:
bash-4.3# ldd insane
insane:
-lc.6 => not found
ldd on the Ubuntu 32bit where I compiled the binary and works:
ldd insane
linux-gate.so.1 => (0xb7784000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75b5000)
/lib/ld-linux.so.2 (0x80086000)
Those are my libraries:
bash-4.3# ls /usr/lib/
bc liblua.so
cawf liblua.so.5
crontab liblua.so.5.3
crt0.o liblua_pic.a
crtbegin.o liblutok.a
crtbeginS.o liblutok.so
crtbeginT.o liblutok.so.2
crtend.o liblutok.so.2.0
crtendS.o liblutok_pic.a
crti.o liblwip.a
crtn.o liblwip_pic.a
fonts liblzma.a
gcrt0.o liblzma.so
keymaps liblzma.so.2
libarchive.a liblzma.so.2.0
libarchive.so liblzma_pic.a
libarchive.so.3 libm.a
libarchive.so.3.1 libm.so
libarchive_pic.a libm.so.0
libasyn.a libm.so.0.11
libasyn_pic.a libm387.a
libatf-c++.a libm387.so
libatf-c++.so libm387.so.0
libatf-c++.so.1 libm387.so.0.1
libatf-c++.so.1.0 libm387_pic.a
libatf-c++_pic.a libm_pic.a
libatf-c.a libmagic.a
libatf-c.so libmagic.so
libatf-c.so.0 libmagic.so.5
libatf-c.so.0.0 libmagic.so.5.1
libatf-c_pic.a libmagic_pic.a
libaudiodriver.a libmenu.a
libaudiodriver_pic.a libmenu.so
libbdev.a libmenu.so.6
libbdev_pic.a libmenu.so.6.0
libbfd.so.13 libmenu_pic.a
libbfd.so.13.0 libminc.a
libblacklist.a libminixfs.a
libblacklist.so libminixfs_pic.a
libblacklist.so.0 libmj.a
libblacklist.so.0.0 libmj.so
libblacklist_pic.a libmj.so.1
libblockdriver.a libmj.so.1.0
libblockdriver_pic.a libmj_pic.a
libbz2.a libmthread.a
libbz2.so libmthread.so
libbz2.so.1 libmthread.so.0
libbz2.so.1.1 libmthread.so.0.0
libbz2_pic.a libmthread_pic.a
libc++.a libnetdriver.a
libc++.so libnetdriver_pic.a
libc++.so.1 libnetpgp.a
libc++.so.1.0 libnetpgp.so
libc++_pic.a libnetpgp.so.3
libc.a libnetpgp.so.3.0
libc.so libnetpgp_pic.a
libc.so.12 libnetpgpverify.a
libc.so.12.197 libnetpgpverify.so
libc_pic.a libnetpgpverify.so.4
libchardriver.a libnetpgpverify.so.4.0
libchardriver_pic.a libnetpgpverify_pic.a
libcrypt.a libnetsock.a
libcrypt.so libnetsock_pic.a
libcrypt.so.1 libopcodes.so.6
libcrypt.so.1.0 libopcodes.so.6.0
libcrypt_pic.a libpci.a
libcrypto.a libpci.so
libcrypto.so libpci.so.2
libcrypto.so.8 libpci.so.2.1
libcrypto.so.8.4 libpci_pic.a
libcrypto_pic.a libprop.a
libcurses.a libprop.so
libcurses.so libprop.so.1
libcurses.so.7 libprop.so.1.1
libcurses.so.7.0 libprop_pic.a
libcurses_pic.a libpuffs.a
libddekit.a libpuffs.so
libddekit_pic.a libpuffs.so.2
libddekit_usb_client.a libpuffs.so.2.0
libddekit_usb_client_pic.a libpuffs_pic.a
libddekit_usb_server.a librefuse.a
libddekit_usb_server_pic.a librefuse.so
libdes.a librefuse.so.2
libdes.so librefuse.so.2.0
libdes.so.8 librefuse_pic.a
libdes.so.8.2 librmt.a
libdes_pic.a libsaslc.a
libdevman.a libsaslc.so
libdevman_pic.a libsaslc.so.0
libedit.a libsaslc.so.0.0
libedit.so libsaslc_pic.a
libedit.so.3 libsffs.a
libedit.so.3.1 libsffs_pic.a
libedit_pic.a libsqlite3.a
libelf.a libsqlite3.so
libelf.so libsqlite3.so.1
libelf.so.1 libsqlite3.so.1.2
libelf.so.1.0 libsqlite3_pic.a
libelf_pic.a libssl.a
libevent.a libssl.so
libevent.so libssl.so.10
libevent.so.4 libssl.so.10.5
libevent.so.4.0 libssl_pic.a
libevent_openssl.a libsys.a
libevent_openssl.so libsys.so
libevent_openssl.so.4 libsys.so.0
libevent_openssl.so.4.0 libsys.so.0.0
libevent_openssl_pic.a libsys_pic.a
libevent_pic.a libtermcap.a
libexec.a libtermcap.so
libexec_pic.a libtermcap.so.0
libexecinfo.a libtermcap.so.0.6
libexecinfo.so libtermcap_pic.a
libexecinfo.so.0 libterminfo.a
libexecinfo.so.0.0 libterminfo.so
libexecinfo_pic.a libterminfo.so.1
libexpat.a libterminfo.so.1.0
libexpat.so libterminfo_pic.a
libexpat.so.2 libtermlib.a
libexpat.so.2.1 libtermlib.so
libexpat_pic.a libtermlib.so.0
libfetch.a libtermlib.so.0.6
libfetch.so libtermlib_pic.a
libfetch.so.3 libtimers.a
libfetch.so.3.0 libtimers_pic.a
libfetch_pic.a libusb.a
libfl.a libusb_pic.a
libform.a libutil.a
libform.so libutil.so
libform.so.6 libutil.so.7
libform.so.6.0 libutil.so.7.23
libform_pic.a libutil_pic.a
libfsdriver.a libvassert.a
libfsdriver_pic.a libvboxfs.a
libgcc_s.a libvboxfs_pic.a
libgcc_s.so libvirtio.a
libgcc_s.so.1 libvirtio_pic.a
libgcc_s.so.1.0 libvtreefs.a
libhgfs.a libvtreefs_pic.a
libhgfs_pic.a libz.a
libinputdriver.a libz.so
libinputdriver_pic.a libz.so.1
libkvm.a libz.so.1.0
libkvm.so libz_pic.a
libkvm.so.6 lua
libkvm.so.6.0 pkgconfig
libkvm_pic.a pwdauth
libl.a security
liblua.a
But when I try to run it I get:
bash-4.3# ./insane
bash: ./insane: No such file or directory
You're missing the dynamic loader /lib/ld-linux.so.2 (as identified by file).
The error message is pretty confusing, and can be quickly reproduced by modifying the loader location in the header with a hex editor (just search for ld-linux and overwrite it with garbage):
$ file myfile
myfile: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), dynamically linked,
interpreter /doesntexistfoobarbaz_.so.2,
for GNU/Linux 2.6.32, (...)
$ [ -x ./myfile ] && ./myfile
bash: ./myfile: No such file or directory
You can run it by putting the correct loader in the correct place, or using another loader explicitly:
$ /lib64/ld-linux-x86-64.so.2 ./myfile
Hello World
I have an application I'm building that's using the NetCDF C++ library, and NetCDF is pulling in the HDF-4 libary. However, it's pulling in the wrong HDF-4 library.
Here's how my app is linked:
/apps1/intel/bin/icpc -gxx-name=/apps1/gcc-4.5.0/bin/g++ -shared -o lib/libMyCustom.so
-Llib -L/apps1/boost-1.48.0/lib -Wl,-rpath=/apps1/boost-1.48.0/lib
-L/apps1/gdal-1.8.0-jasper/lib -Wl,-rpath=/apps1/gdal-1.8.0-jasper/lib
-L/new_apps1/hdf4/lib -Wl,-rpath=/new_apps1/hdf4/lib -L/new_apps1/netcdf/lib
-Wl,-rpath=/new_apps1/netcdf/lib -lboost_system -lboost_serialization
-lboost_date_time -lboost_thread -lgdal -ldf -lmfhdf -lnetcdf_c++
MyProj/obj/ProjUtility.o MyProj/obj/ProjMetadataException.o
MyProj/obj/ProjTimestampUtil.o
I have set my LD_LIBRARY_PATH very short:
LD_LIBRARY_PATH=/new_apps1/hdf4/lib:/new_apps1/hdf5/lib:
/apps1/intel/composerxe/lib/intel64:/apps1/gcc-4.5.0/lib64:/apps1/gcc-4.5.0/lib
And here is an excerpt from the ldd -v output:
libdf.so.0 => /new_apps1/hdf4/lib/libdf.so.0 (0x00002af5baabc000)
libmfhdf.so.0 => /new_apps1/hdf4/lib/libmfhdf.so.0 (0x00002af5bad61000)
libnetcdf_c++.so.5 => /new_apps1/netcdf/lib/libnetcdf_c++.so.5 (0x00002af5baf85000)
libhdf5.so.6 => /new_apps1/hdf5/lib/libhdf5.so.6 (0x00002af5bd1e7000)
libgif.so.4 => /usr/lib64/libgif.so.4 (0x0000003a6bc00000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003a71000000)
libnetcdf.so.6 => /new_apps1/netcdf/lib/libnetcdf.so.6 (0x00002af5bd682000)
libhdf5_hl.so.6 => /new_apps1/hdf5/lib/libhdf5_hl.so.6 (0x00002af5be272000)
/new_apps1/hdf4/lib/libdf.so.0:
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/new_apps1/hdf4/lib/libmfhdf.so.0:
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/new_apps1/netcdf/lib/libnetcdf_c++.so.5:
libgcc_s.so.1 (GCC_3.0) => /apps1/gcc-4.5.0/lib64/libgcc_s.so.1
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
libstdc++.so.6 (CXXABI_1.3) => /apps1/gcc-4.5.0/lib64/libstdc++.so.6
libstdc++.so.6 (GLIBCXX_3.4) => /apps1/gcc-4.5.0/lib64/libstdc++.so.6
/new_apps1/hdf5/lib/libhdf5.so.6:
libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/new_apps1/netcdf/lib/libnetcdf.so.6:
libm.so.6 (GLIBC_2.2.5) => /lib64/libm.so.6
libc.so.6 (GLIBC_2.3) => /lib64/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
/new_apps1/hdf5/lib/libhdf5_hl.so.6:
libc.so.6 (GLIBC_2.2.5) => /lib64/libc.so.6
So far, everything in the LD_LIBRARY_PATH, rpath, and ldd indicate that it's pointing to the HDF that I want to reference (/new_apps1/hdf4/lib/libmfhdf.so.0). But when I run, Valgrind is telling me that it's dying in the OLD HDF-4 library (which is probably why it's segfaulting), instead of the HDF-4 library I'm attempting to link against:
Invalid read of size 4
at 0x67CF765: NC_var_shape (in /apps1/hdf-4.2.6/lib/libmfhdf.so.0.0.0)
by 0x91327CA: nc_get_NC (v1hpg.c:1113)
by 0x91303C0: l3nc__open_mp (nc.c:1096)
by 0x915B279: nc3d__open_mp (dapdispatch3.c:336)
by 0x914A752: nc3d_open (ncdap3.c:94)
by 0x911F8A2: l4nc_open_file (nc4file.c:2338)
by 0x916A290: nc4d_open_file (ncdap4.c:122)
by 0x911CDDF: nc__open (nc4file.c:2407)
by 0x69E85F8: NcFile::NcFile(char const*, NcFile::FileMode, unsigned long*, unsigned long, NcFile::FileFormat) (netcdf.cpp:384)
by 0x710F0B8: getData(std::string const&) (ProjTimestampUtil.cc:593)
by 0x70E9BEA: (anonymous namespace)::parseOptions(int, char**) (ProjUtility.cc:190)
by 0x70EAAFB: main(int, char**) (ProjUtility.cc:243)
Address 0x1051 is not stack'd, malloc'd or (recently) free'd
Process terminating with default action of signal 11 (SIGSEGV)
Access not within mapped region at address 0x1051
at 0x67CF765: NC_var_shape (in /apps1/hdf-4.2.6/lib/libmfhdf.so.0.0.0)
by 0x91327CA: nc_get_NC (v1hpg.c:1113)
by 0x91303C0: l3nc__open_mp (nc.c:1096)
by 0x915B279: nc3d__open_mp (dapdispatch3.c:336)
by 0x914A752: nc3d_open (ncdap3.c:94)
by 0x911F8A2: l4nc_open_file (nc4file.c:2338)
by 0x916A290: nc4d_open_file (ncdap4.c:122)
by 0x911CDDF: nc__open (nc4file.c:2407)
by 0x69E85F8: NcFile::NcFile(char const*, NcFile::FileMode, unsigned long*, unsigned long, NcFile::FileFormat) (netcdf.cpp:384)
by 0x710F0B8: getData(std::string const&) (ProjTimestampUtil.cc:593)
by 0x70E9BEA: (anonymous namespace)::parseOptions(int, char**) (ProjUtility.cc:190)
by 0x70EAAFB: main(int, char**) (ProjUtility.cc:243)
Where else is my app getting path info when dynamically pulling in other libraries?
I'm not exactly sure of all the details of how -rpath and LD_LIBRARY_PATH work, and their precedence, but I did find some useful environment variables:
LD_DEBUG=all - This env variable turns on verbose dynamic linker debugging. Now doing an ldd on your app will spew output about the details of how all its dependencies find their dependencies.
LD_DEBUG_OUTPUT=<filename_prefix> - Used in conjunction with LD_DEBUG to specify output files to log the debugging info to.
The LD_DEBUG env variable helped me track down that /apps1/gdal-1.8.0-jasper/lib/libgdal.so.1 was compiled with an -rpath option that was pulling the old (wrong) versions of my libraries. It gave this helpful debug output:
search path=/pathXYZ/lib/tls/x86_64:/pathXYZ/lib/tls:/pathXYZ/lib/x86_64:
/pathABC/jasper/lib:/pathABC/hdf5/lib/tls/x86_64:/pathABC/hdf5/lib/tls:
/pathABC/hdf5/lib/x86_64:/pathABC/hdf5/lib:/pathABC/netcdf/lib/tls/x86_64:
/pathABC/netcdf/lib/tls:/pathABC/netcdf/lib/x86_64:/pathABC/netcdf/lib
(RPATH from file /apps1/gdal-1.8.0-jasper/lib/libgdal.so.1)
So the rpath of how the GDAL library was compiled seemed to be making an end-run around my LD_LIBRAR_PATH. Until I can get my lab team to rebuild libgdal correctly, I found this env var, which helped me load the "right" library versions that I wanted:
LD_PRELOAD=<path/to/libName.so> - Point this to the location of a library (or a space-separated list of libraries) that should be loaded before all others. See the ld.so man page.
I need help understanding why I get an error when I insert a module. I have tried this with no success.
$ sudo modprobe lpfc_scst
FATAL: Error inserting lpfc_scst (/lib/modules/2.6.32-33-generic/extra/lpfc_scst.ko): Unknown symbol in module, or unknown parameter (see dmesg)
$ dmesg | tail
[ 1201.262842] lpfc_scst: Unknown symbol scst_register_target
[ 1201.262949] lpfc_scst: Unknown symbol lpfc_tm_term
[ 1201.263161] lpfc_scst: no symbol version for scst_register_session
[ 1201.263164] lpfc_scst: Unknown symbol scst_register_session
[ 1201.263284] lpfc_scst: no symbol version for scst_rx_mgmt_fn
[ 1201.263286] lpfc_scst: Unknown symbol scst_rx_mgmt_fn
[ 1201.263395] lpfc_scst: no symbol version for scst_unregister_session
[ 1201.263398] lpfc_scst: Unknown symbol scst_unregister_session
[ 1201.263573] lpfc_scst: no symbol version for scst_rx_data
[ 1201.263575] lpfc_scst: Unknown symbol scst_rx_data
$ cat /proc/kallsyms | grep scst_register_target
dffd2a10 r __ksymtab_scst_register_target [scst]
dffd302e r __kstrtab_scst_register_target [scst]
dffd2b34 r __kcrctab_scst_register_target [scst]
dffd2a20 r __ksymtab___scst_register_target_template_non_gpl [scst]
dffd3063 r __kstrtab___scst_register_target_template_non_gpl [scst]
dffd2b3c r __kcrctab___scst_register_target_template_non_gpl [scst]
dffd2c10 r __ksymtab___scst_register_target_template [scst]
dffd308b r __kstrtab___scst_register_target_template [scst]
dffd2de8 r __kcrctab___scst_register_target_template [scst]
dff913a0 t __scst_register_target_template [scst]
dff90dd0 T scst_register_target [scst]
dff91840 T __scst_register_target_template_non_gpl [scst]
$
Many thanks.
I have solved this problem as suggested on this forum:
Compiled scst.
Appended the generated Module.symvers to existent /lib/modules/<version>/build/Module.symvers (Hack. Do not know why the kernel did not see the exported symbols).
Copied the scst to /lib/modules/<version>/extra.
depmod -a.
Compiled lpfc_scst.
Inserted module lpfc_scst with no problems.
Have a nice day.
If you are trying to insmod a module that was build against a kernel source tree/headers that are not the actual source of the running kernel, the most likely cause is that some kernel configuration is different between the running kernel and the one you built the module against.
The linker inside the Linux kernel actually looks at a bunch of things besides the symbol name for matching symbols, including possibly a hash of the function parameter and return value, various config option (preempt / non preempt) when trying to match symbol names. I guess that in your case it does not find the right match due to different config options
This means that the kernel isn't allowing modules to see that variable. It does look like you haven't added your variables to the list of symbols that the kernel exports:
EXPORT_SYMBOL_NOVERS(scst_register_target);