While I want to start my Firefox 3.6 which I installed under /opt/firefox/
I have the Following Error:
[root#box]: ./firefox-bin
./firefox-bin: error while loading shared libraries: libxul.so: cannot open shared object file: No such file or directory
Here is my ldd output:
ldd firefox-bin
linux-gate.so.1 => (0xf77cf000)
libpthread.so.0 => /lib32/libpthread.so.0 (0xf779e000)
libxul.so => not found
libxpcom.so => not found
libmozalloc.so => not found
libplds4.so => /usr/lib32/libplds4.so (0xf779a000)
libplc4.so => /usr/lib32/libplc4.so (0xf7796000)
llibnspr4.so => /usr/lib32/libnspr4.so (0xf7762000)
libdl.so.2 => /lib32/libdl.so.2 (0xf775d000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7668000)
libm.so.6 => /lib32/libm.so.6 (0xf7642000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7624000)
libc.so.6 => /lib32/libc.so.6 (0xf74dd000)
/lib/ld-linux.so.2 (0xf77d0000)
The file is there an all the others too:
[root#box]: locate libxul
/opt/firefox/libxul.so
So they are 3 files missing. Can you help to get me them?
EDIT:
With the short fix:
export LD_LIBRARY_PATH=/opt/firefox/
I get the same error with ./firefox-bin
./firefox-bin: error while loading shared libraries: libpangoft2-1.0.so.0: cannot open shared object file: No such file or directory
You should start it with /opt/firefox/firefox
Looks like there is something wrong with you package mananger ...
ldd firefox-bin
libxul.so => not found
...
locate libxul
/opt/firefox/libxul.so
this part can be solved with
export LD_LIBRARY_PATH=/opt/firefox/
..../firefox-bin
or
LD_LIBRARY_PATH=/opt/firefox/ ..../firefox-bin
Try:
sudo apt-get install ia32-libs-gtk
Related
I have an issue writing a custom wrapper around go_test from rules_go:
My situation: I have a set of precompiled libraries (.so) for Fedora that I want to link against go code using cgo. This part works beautifully. The resulting binaries run correctly on Fedora.
I even have declared all of the libraries as dependencies correctly and they show up in the runfiles of my go_binary outputs.
The precompiled .so files also include glibc from fedora (this is required since the other shared libraries depend on this version of the glibc) and ld-linux-x86-64.so.2 from Fedora.
How would I write a wrapper around go_test that uses the vendored ld from Fedora as a binary and passes the original go binary path as the first argument?
Additional info:
All of the libraries are accessible via the runfiles and findable via the ELF runpath. It's only ld itself that is selected incorrectly:
$ readelf -a bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test | grep RUNPATH
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs:$ORIGIN/initserver_test.runfiles/__main__/_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs]
$ ldd bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
/lib64/ld-linux-x86-64.so.2 (0x00007f944795d000)
linux-vdso.so.1 (0x00007fff66347000)
libargon2.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libargon2.so.1 (0x00007f9447952000)
libblkid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libblkid.so.1 (0x00007f9447919000)
libc.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libc.so.6 (0x00007f944773c000)
libcrypto.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcrypto.so.3 (0x00007f9447312000)
libcryptsetup.so.12 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcryptsetup.so.12 (0x00007f9447294000)
libdevmapper.so.1.02 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libdevmapper.so.1.02 (0x00007f9447238000)
libgcc_s.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libgcc_s.so.1 (0x00007f9447218000)
libjson-c.so.5 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libjson-c.so.5 (0x00007f9447205000)
libm.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libm.so.6 (0x00007f9447123000)
libpcre2-8.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpcre2-8.so.0 (0x00007f9447086000)
libpthread.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpthread.so.0 (0x00007f9447081000)
libselinux.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libselinux.so.1 (0x00007f9447054000)
libssl.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libssl.so.3 (0x00007f9446fb1000)
libudev.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libudev.so.1 (0x00007f9446f81000)
libuuid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libuuid.so.1 (0x00007f9446f78000)
libz.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libz.so.1 (0x00007f9446f5e000)
$ bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 --list bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
/lib64/ld-linux-x86-64.so.2 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 (0x00007f637dec7000)
linux-vdso.so.1 (0x00007ffd2e1e8000)
libargon2.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libargon2.so.1 (0x00007f637debc000)
libblkid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libblkid.so.1 (0x00007f637de83000)
libc.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libc.so.6 (0x00007f637dca6000)
libcrypto.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcrypto.so.3 (0x00007f637d87c000)
libcryptsetup.so.12 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libcryptsetup.so.12 (0x00007f637d7fe000)
libdevmapper.so.1.02 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libdevmapper.so.1.02 (0x00007f637d7a2000)
libgcc_s.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libgcc_s.so.1 (0x00007f637d782000)
libjson-c.so.5 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libjson-c.so.5 (0x00007f637d76f000)
libm.so.6 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libm.so.6 (0x00007f637d68d000)
libpcre2-8.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpcre2-8.so.0 (0x00007f637d5f0000)
libpthread.so.0 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libpthread.so.0 (0x00007f637d5eb000)
libselinux.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libselinux.so.1 (0x00007f637d5be000)
libssl.so.3 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libssl.so.3 (0x00007f637d51b000)
libudev.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libudev.so.1 (0x00007f637d4eb000)
libuuid.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libuuid.so.1 (0x00007f637d4e2000)
libz.so.1 => /some/path/bazel-bin/bootstrapper/internal/initserver/initserver_test_/../../../../_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/libz.so.1 (0x00007f637d4c8000)
When using bazel run or bazel test on Ubuntu, my host ld-linux-x86-64.so.2 is used and I get a segfault. This is due to the hardcoded path to the interpreter (LD) embedded in the go binary and because ld and libc have to match:
readelf -p .interp bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
String dump of section '.interp':
[ 0] /lib64/ld-linux-x86-64.so.2
bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
Segmentation fault (core dumped)
The same works if I execute fedoras ld-linux-x86-64.so.2 directly and give it the path to the go binary as an argument (this is equivalent to setting the interpreter in the elf header to the absolute path of the location of the fedora ld on my host).
bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test.runfiles/__main__/_solib_k8/_U_S_Srpm_Ccryptsetup___Urpm_Scryptsetup-libs/ld-linux-x86-64.so.2 bazel-bin/bootstrapper/internal/initserver/initserver_test_/initserver_test
PASS
I'm trying to build a go program with static link. I want to run this on a different system, with different version of glibc, without all the dependencies etc ...
So i looked up and found that you can pass arguments to the gcc compiler and tell him to statically link the dependencies. But i'm facing issue with "undefined_reference"
Here's the command i'm using : go build --ldflags '-extldflags "-static"' src/main/command/main.go
And the result :
# command-line-arguments
/usr/local/go/pkg/tool/linux_amd64/link: running g++ failed: exit status 1
/usr/bin/ld: /tmp/go-link-376220047/000023.o: in function `_cgo_26061493d47f_C2func_getaddrinfo':
/tmp/go-build/cgo-gcc-prolog:58: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtesseract.a(libtesseract_la-baseapi.o): in function `tesseract::TessBaseAPI::ProcessPagesInternal(char const*, char const*, int, tesseract::TessResultRenderer*)':
(.text+0x7356): undefined reference to `curl_easy_init'
/usr/bin/ld: (.text+0x7378): undefined reference to `curl_easy_setopt'
/usr/bin/ld: (.text+0x7387): undefined reference to `curl_easy_strerror'
/usr/bin/ld: (.text+0x73b6): undefined reference to `curl_easy_cleanup'
/usr/bin/ld: (.text+0x7700): undefined reference to `curl_easy_setopt'
/usr/bin/ld: (.text+0x771e): undefined reference to `curl_easy_setopt'
/usr/bin/ld: (.text+0x773e): undefined reference to `curl_easy_setopt'
/usr/bin/ld: (.text+0x775e): undefined reference to `curl_easy_setopt'
/usr/bin/ld: (.text+0x7770): undefined reference to `curl_easy_perform'
/usr/bin/ld: (.text+0x777f): undefined reference to `curl_easy_strerror'
/usr/bin/ld: (.text+0x7b16): undefined reference to `curl_easy_cleanup'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtesseract.a(libtesseract_la-par_control.o): in function `tesseract::Tesseract::PrerecAllWordsPar(std::vector<tesseract::WordData, std::allocator<tesseract::WordData> > const&) [clone ._omp_fn.0]':
(.text+0x36): undefined reference to `omp_get_num_threads'
/usr/bin/ld: (.text+0x3e): undefined reference to `omp_get_thread_num'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtesseract.a(libtesseract_la-par_control.o): in function `tesseract::Tesseract::PrerecAllWordsPar(std::vector<tesseract::WordData, std::allocator<tesseract::WordData> > const&)':
(.text+0x3eb): undefined reference to `GOMP_parallel'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libtesseract.a(libtesseract_ccutil_la-tessdatamanager.o): in function `tesseract::TessdataManager::LoadArchiveFile(char const*)':
(.text+0x406): undefined reference to `archive_read_new'
/usr/bin/ld: (.text+0x416): undefined reference to `archive_read_support_filter_all'
/usr/bin/ld: (.text+0x41e): undefined reference to `archive_read_support_format_all'
/usr/bin/ld: (.text+0x42e): undefined reference to `archive_read_open_filename'
/usr/bin/ld: (.text+0x44e): undefined reference to `archive_entry_pathname'
/usr/bin/ld: (.text+0x45e): undefined reference to `archive_read_next_header'
/usr/bin/ld: (.text+0x470): undefined reference to `archive_read_free'
...
The output is way bigger than that, it's just the start, but other errors are the same with different libraries.
i tried telling ld to find curl (for example) with the flag -lcurl, it works, but the problem is the same for many other libraries.
If you want to know the depedencies i use, here's the output of ldd main (the binary compiled dynamically) :
linux-vdso.so.1 (0x00007ffe273ed000)
liblept.so.5 => /usr/lib/x86_64-linux-gnu/liblept.so.5 (0x00007f70737d2000)
libtesseract.so.5 => /usr/lib/x86_64-linux-gnu/libtesseract.so.5 (0x00007f707345e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f707343c000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f707326f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f707312b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7073111000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7072f4a000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f7072f10000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f7072e8c000)
libgif.so.7 => /usr/lib/x86_64-linux-gnu/libgif.so.7 (0x00007f7072e81000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f7072dfb000)
libwebpmux.so.3 => /usr/lib/x86_64-linux-gnu/libwebpmux.so.3 (0x00007f7072def000)
libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f7072d84000)
libopenjp2.so.7 => /usr/lib/x86_64-linux-gnu/libopenjp2.so.7 (0x00007f7072d27000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7072d0a000)
libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 (0x00007f7072c42000)
libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007f7072ba7000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f7072b67000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7073a90000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f7072a8a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f7072a62000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f7072854000)
libdeflate.so.0 => /usr/lib/x86_64-linux-gnu/libdeflate.so.0 (0x00007f7072838000)
libnettle.so.8 => /usr/lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f70727f0000)
libacl.so.1 => /usr/lib/x86_64-linux-gnu/libacl.so.1 (0x00007f70727e3000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f70727c0000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f70727ad000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f70725ff000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f70725d2000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f70725b1000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f7072590000)
libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1 (0x00007f707255b000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f7072547000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f70724b4000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f70721c0000)
libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f707216d000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f7072115000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f7072104000)
libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f70720f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f70720f0000)
libicuuc.so.67 => /usr/lib/x86_64-linux-gnu/libicuuc.so.67 (0x00007f7071f07000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f7071d83000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f7071b83000)
libhogweed.so.6 => /usr/lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f7071b3a000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f7071ab9000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f7071999000)
libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f70718bd000)
libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f707188d000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f7071887000)
libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f7071878000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f707185e000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f7071841000)
libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f707181c000)
libicudata.so.67 => /usr/lib/x86_64-linux-gnu/libicudata.so.67 (0x00007f706fd03000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f706fbcf000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f706fbb9000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f706fb93000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f706fb8a000)
libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f706fb7e000)
My questions are :
Why ld cannot find curl and other libraries by itself ?
How to know everything i need to install ?
Even if i install every lib it needs, will it work ?
Add required libraries to the linker flags: -static -lcurl -lssh2 -lssl -lcrypto -lz. Also you probably need to install -dev versions of the libraries: apt install libcurl4-openssl-dev libssh-dev zlib1g-dev. It will install lib*.a files which are needed for static linking.
I am insterested in using PGI OpenACC runtime API directly from code compiled by GCC.
I've noticed that the PGI OpenACC installation provides two openacc.h headers. One for PGI (located in include/openacc.h) and another that seems to be compatible with GCC (etc/include_acc/openacc.h). It is safe to use the second header with GCC?
So far I've been able to compile & run a small test:
#include <openacc.h>
#include <cuda_runtime_api.h>
#include <stdio.h>
int main()
{
acc_init( acc_device_nvidia );
int ndev = acc_get_num_devices( acc_device_nvidia );
printf("Num OpenACC devices: %d\n", ndev);
cudaGetDeviceCount(&ndev);
printf("Num CUDA devices: %d\n", ndev);
return 0;
}
Using PGI:
pgcc -acc -ta=tesla,cuda8.0 -Mcuda ./test.c -o oacc_test.pgi
Using GCC + PGI OpenACC:
gcc -isystem /usr/local/cuda-8.0/include -isystem /usr/local/pgi/linux86-64/17.4/etc/include_acc -o oacc_test.both test.c -L/usr/local/cuda-8.0/lib64 -Wl,-rpath,/usr/local/cuda-8.0/lib64 -lcudart -lcuda -L/usr/local/pgi/linux86-64/17.4/lib -Wl,-rpath,/usr/local/pgi/linux86-64/17.4/lib -laccapi -laccg -laccnc -laccn -laccg2 -ldl -lpgc -lm
Using GCC + GCC OpenACC: (for comparison)
gcc -fopenacc -isystem /usr/local/cuda-8.0/include -o oacc_test.gnu test.c -L/usr/local/cuda-8.0/lib64 -Wl,-rpath,/usr/local/cuda-8.0/lib64 -lcudart -lcuda
And execute:
$ ./oacc_test.pgi
Num OpenACC devices: 4
Num CUDA devices: 4
$ ./oacc_test.both
Num OpenACC devices: 4
Num CUDA devices: 4
$ ./oacc_test.gnu
libgomp: device type nvidia not supported
More info:
$ ldd oacc_test.pgi
linux-vdso.so.1 (0x00007ffd843f8000)
libaccapi.so => /usr/local/pgi/linux86-64/17.4/lib/libaccapi.so (0x00007fa5a2b9f000)
libaccg.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg.so (0x00007fa5a2981000)
libaccnc.so => /usr/local/pgi/linux86-64/17.4/lib/libaccnc.so (0x00007fa5a2777000)
libaccn.so => /usr/local/pgi/linux86-64/17.4/lib/libaccn.so (0x00007fa5a2552000)
libaccg2.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg2.so (0x00007fa5a233c000)
libcudapgi.so => /usr/local/pgi/linux86-64/17.4/lib/libcudapgi.so (0x00007fa5a213b000)
libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007fa5a1ed5000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa5a1b49000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa5a1945000)
libcudadevice.so => /usr/local/pgi/linux86-64/17.4/lib/libcudadevice.so (0x00007fa5a1731000)
libpgmp.so => /usr/local/pgi/linux86-64/17.4/lib/libpgmp.so (0x00007fa5a14af000)
libnuma.so => /usr/local/pgi/linux86-64/17.4/lib/libnuma.so (0x00007fa5a12ae000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa5a1091000)
libpgc.so => /usr/local/pgi/linux86-64/17.4/lib/libpgc.so (0x00007fa5a0dae000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa5a0aaa000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa5a070b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa5a04f2000)
/lib64/ld-linux-x86-64.so.2 (0x000055767be3b000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa5a02ea000)
$ ldd oacc_test.both
linux-vdso.so.1 (0x00007ffe55753000)
libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007f7ddfe3c000)
libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007f7ddf3d8000)
libaccapi.so => /usr/local/pgi/linux86-64/17.4/lib/libaccapi.so (0x00007f7ddf1b8000)
libaccg.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg.so (0x00007f7ddef9a000)
libaccnc.so => /usr/local/pgi/linux86-64/17.4/lib/libaccnc.so (0x00007f7dded90000)
libaccn.so => /usr/local/pgi/linux86-64/17.4/lib/libaccn.so (0x00007f7ddeb69000)
libaccg2.so => /usr/local/pgi/linux86-64/17.4/lib/libaccg2.so (0x00007f7dde955000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7dde751000)
libpgc.so => /usr/local/pgi/linux86-64/17.4/lib/libpgc.so (0x00007f7dde46e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7dde16a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7ddddcb000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7dddbac000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7ddd9a4000)
libnvidia-fatbinaryloader.so.378.13 => /usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.378.13 (0x00007f7ddd753000)
/lib64/ld-linux-x86-64.so.2 (0x00005593f06f5000)
$ ldd oacc_test.gnu
linux-vdso.so.1 (0x00007ffd967d7000)
libcudart.so.8.0 => /usr/local/cuda/lib64/libcudart.so.8.0 (0x00007f9002679000)
libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1 (0x00007f9001c15000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f90019e8000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f90017cb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f900142c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9001226000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f900101e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9000d1a000)
libnvidia-fatbinaryloader.so.378.13 => /usr/lib/x86_64-linux-gnu/libnvidia-fatbinaryloader.so.378.13 (0x00007f9000ac9000)
/lib64/ld-linux-x86-64.so.2 (0x0000563eee684000)
Is is safe to use the PGI OpenACC Runtime API that way?
Also threre is any difference between the CUDA runtime provided by Nvidia (usually in /usr/local/cuda) and the one provided by PGI (in my case in /usr/local/pgi/linux86-64/2017/cuda)?
I've noticed that pgcc uses the CUDA 7.5 from it's own install path but when -ta=cuda8.0 is provided it uses the one in /usr/local/cuda. Any special reason?
PGI compiled objects are interoperable with GNU and it's fine to mix in PGI OpenACC compiled code with GNU compiled objects. Though, the OpenACC runtimes libraries aren't compatible so I'd recommend not mixing the OpenACC code. Note that GNU support for OpenACC has gotten a lot better in their 7.0 release, so while I work for PGI, I'd encourage you to try both compilers. The one caveat is the they (GNU) don't support the "kernels" construct, so you'll want to stick to using "parallel" regions.
As for the CUDA libraries, PGI ships all the libraries that we need to compile your OpenACC code. Though, there's no difference in the CUDA libraries themselves. We didn't want users to have to co-install the CUDA SDK and it allows us to add convenience flags such as "-Mcudalib[=cublas|cufft|curand|cusolver|cusparse]" since we know where these libraries are located as well as include our own Fortran interface modules to these libraries.
Unless you have the flag "CUDAROOT=" set on your compilation line, "-ta=tesla:cuda8.0" should be using the PGI supplied CUDA 8.0 directory located in "$PGI/linux86-64/2017/cuda/8.0". Are you sure it's using the /usr/local/cuda install? You can double check by adding the verbose flag (-v) to see what the compiler driver is executing or "-dryrun" to see the commands without having the driver execute them.
Another possibility is that you're using "-L" or "-Wl" flags to point to the CUDA install (like you do with GNU) in which case the linker will pick-up the CUDA libraries from these directories. Though since they're the same libraries as we ship, it shouldn't be a problem.
I have downloaded, build and configured
unixODBC-2.3.2.tar
I installed:
oracle-instantclient12.1-odbc-12.1.0.2.0-1.x86_64.rpm
oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm
oracle-instantclient12.1-sqlplus-12.1.0.2.0-1.x86_64.rpm
I configured /usr/local/etc/odbcinst.ini as follows:
[Oracle]
Description = Oracle ODBC Connection
Driver = /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
Setup =
FileUsage =
libsqora.so.12.1 file exists:
file /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
/usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
I also configured the odbc.ini file:
[prd_db]
Driver=Oracle
Description=prod database
Trace=Yes
ServerName=//prddb01:1521/dbp01_svc1
When I use prd_db credentilas to connect using isql:
isql prd_db
I get connection error. User name and password are accurate and I can connect using sql developer.
what am I missing? I need to configure odbc connection in a linux server.
ldd /usr/lib/oracle/12.1/client64/lib/libsqora.so.12.1
linux-vdso.so.1 => (0x00007fffd918b000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f6c73bb2000)
libm.so.6 => /lib64/libm.so.6 (0x00007f6c73939000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6c7371b000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f6c73503000)
librt.so.1 => /lib64/librt.so.1 (0x00007f6c732fa000)
libclntsh.so.12.1 => not found
libodbcinst.so.2 => /usr/local/lib/libodbcinst.so.2 (0x00007f6c730e8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6c72d6c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6c74242000)
libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6c72b61000)
I have two computers - Ubuntu 12.04 + Lazarus. Let's call them A and B.
I develop a program on A. It works fine.
I run the same program on B using Lazarus and it works fine.
Then I make a compiled program (binary) on A and try it on B. Now the problem starts.
Everything works fine except that none of the reports (LazReport) appear. There's no error. Just no response. The program continues without a crash but just no response. How is this possible?
Clues:
On machine A and B, I installed the software (Lazarus) as the default admin user.
On machine B, I have another user account but this is a standard user.
On machine B, I installed LazReport component on Lazarus using the standard user account. So I suspect a permissions issue.
Then I removed the LazReport component on Lazarus from machine B and reinstalled it a second time. But this time I ran it as admin like this gksu -u ADMIN -w startlazarus but still no change.
Please advice how I may solve this problem.
My restriction:
I must be able to do this using the standard account and not ADMIN. Is this even possible?
Thanks!
EDIT: here's the output of ldd:
linux-gate.so.1 => (0xb76f3000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb76c3000)
libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb758f000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk_pixbuf-2.0.so.0 (0xb756d000)
libgtk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0 (0xb7105000)
libgdk-x11-2.0.so.0 => /usr/lib/i386-linux-gnu/libgdk-x11-2.0.so.0 (0xb7056000)
libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb7007000)
libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb6f0e000)
libgthread-2.0.so.0 => /usr/lib/i386-linux-gnu/libgthread-2.0.so.0 (0xb6f0a000)
libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb6f05000)
libpango-1.0.so.0 => /usr/lib/i386-linux-gnu/libpango-1.0.so.0 (0xb6ebb000)
libcairo.so.2 => /usr/lib/i386-linux-gnu/libcairo.so.2 (0xb6df0000)
libatk-1.0.so.0 => /usr/lib/i386-linux-gnu/libatk-1.0.so.0 (0xb6dd0000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6dca000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6c20000)
/lib/ld-linux.so.2 (0xb76f4000)
libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb6bff000)
libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb6aa8000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6a7c000)
libpangocairo-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0 (0xb6a6e000)
libXfixes.so.3 => /usr/lib/i386-linux-gnu/libXfixes.so.3 (0xb6a68000)
libpangoft2-1.0.so.0 => /usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0 (0xb6a3c000)
libfontconfig.so.1 => /usr/lib/i386-linux-gnu/libfontconfig.so.1 (0xb6a08000)
libXext.so.6 => /usr/lib/i386-linux-gnu/libXext.so.6 (0xb69f6000)
libXrender.so.1 => /usr/lib/i386-linux-gnu/libXrender.so.1 (0xb69eb000)
libXinerama.so.1 => /usr/lib/i386-linux-gnu/libXinerama.so.1 (0xb69e7000)
libXi.so.6 => /usr/lib/i386-linux-gnu/libXi.so.6 (0xb69d7000)
libXrandr.so.2 => /usr/lib/i386-linux-gnu/libXrandr.so.2 (0xb69ce000)
libXcursor.so.1 => /usr/lib/i386-linux-gnu/libXcursor.so.1 (0xb69c3000)
libXcomposite.so.1 => /usr/lib/i386-linux-gnu/libXcomposite.so.1 (0xb69be000)
libXdamage.so.1 => /usr/lib/i386-linux-gnu/libXdamage.so.1 (0xb69ba000)
libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb69b3000)
libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb6977000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb696e000)
libpixman-1.so.0 => /usr/lib/i386-linux-gnu/libpixman-1.so.0 (0xb68d5000)
libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb683b000)
libpng12.so.0 => /lib/i386-linux-gnu/libpng12.so.0 (0xb6811000)
libxcb-shm.so.0 => /usr/lib/i386-linux-gnu/libxcb-shm.so.0 (0xb680d000)
libxcb-render.so.0 => /usr/lib/i386-linux-gnu/libxcb-render.so.0 (0xb6803000)
libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb67ec000)
libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb67e8000)
libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb67e1000)
libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb67c2000)
libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb67aa000)
libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xb677f000)
They appear IDENTICAL on machines A and B except that the hex number within brackets is different. Apart from that, it's the same line to line.
EDIT: More info - new findings...
I opened a terminal. Then ran Nautilus. Then I run my binary and when trying the report, I got this error in the terminal:
[WARNING] SetAlphaBlend called without handle for
frProgressForm(TfrProgressForm)
I have no clue but I believe this is the bug. I have no form like the one mentioned either.
Apparently, as I discovered much later, the reports didn't work outside of the development folder although the rest of the application did.
The solution was to simply copy the report files (.lrf) and put it into the destination folder that contained the binary.