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)
Related
I tried to use a dblink I created in Oracle to access a Dameng database and this error poped up. I tried to isql to Dameng database before, and I could connect to Dameng with isql.
Here is my /etc/odbc.ini:
[dm8]
Driver = DM8 ODBC DRIVER
Description = DM ODBC DSND
SERVER = 10.10.10.73
UID = SYSDBA
PWD = SYSDBA
TCP_PORT = 5236
Here is my /etc/odbcinst.ini file:
[DM8 ODBC DRIVER]
Description = ODBC DRIVER FOR DM8
Driver = /opt/dmdbms/bin/libdodbc.so
threading = 0
I was able to connect to Dameng database via isql successfully.
But when after I set up related Oracle configurations, and connect from Oracle, the error poped up.
Here are some related configurations:
ORACLE_HOME/hs/admin/initdm8.ora:
HS_FDS_CONNECT_INFO = dm8
HS_FDS_TRACE_LEVEL = debug
HS_FDS_SHAREABLE_NAME = /usr/lib64/libodbc.so
#HS_FDS_SHAREABLE_NAME = /usr/lib/libodbc.so
HS_FDS_SUPPORT_STATISTICS=FALSE
#HS_LANGUAGE="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
HS_LANGUAGE="AMERICAN_AMERICA.ZHS16GBK"
HS_NLS_NCHAR=UCS2
For ORACLE_HOME/network/admin/listener.ora, I added SID_DESC in existing SID_LIST:
(SID_DESC =
(PROGRAM = dg4odbc)
(ORACLE_HOME = /u01/app/oracle/product/19.0.3/dbhome_1)
(SID_NAME = dm8)
(ENVS="LD_LIBRARY_PATH=/u01/app/oracle/product/19.0.3/dbhome_1/lib:/opt/dmdbms/bin")
)
For ORACLE_HOME/network/admin/tnsnames.ora, added:
dm8 =
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP) (HOST=ylzcs) (PORT=1521)
)
(CONNECT_DATA=
(SID=dm8)
)
(HS=OK)
)
The dblink was created and used in PL/SQL:
drop database link dblink_DM8;
create database link dblink_DM8 connect to "SYSDBA" identified by "SYSDBA" using 'dm8';
select * from v$version#dblink_DM8;
I have searched lots of web pages and encountered many assumptions, but they usually do not match my situation:
Assumption: this libdodbc.so file doesn't exist. Answer: the file does exists at that location.
Assumption: Oracle's install user doesn't have access to this file. Answer: the install user oracle was used to install Dameng database, which is the same user used to install Oracle, so libdodbc.so belongs to oracle.
Assumption: You didn't set up LD_LIBRARY_PATH environment variable. Answer: I did set it up in .bash/profile, and the content of LD_LIBRARY_PATH is :/opt/dmdbms/bin:/opt/dmdbms/bin
Assumption: libdodbc.so has some dependent files missing. Answer: there are no not found entries:
[root#ylzcs log]# ldd /opt/dmdbms/bin/libdodbc.so
linux-vdso.so.1 => (0x00007ffd317fd000)
libdmdpi.so => /opt/dmdbms/bin/libdmdpi.so (0x00007f5852901000)
libdmfldr.so => /opt/dmdbms/bin/libdmfldr.so (0x00007f5851ca1000)
libdmelog.so => /opt/dmdbms/bin/libdmelog.so (0x00007f5851a99000)
libdmutl.so => /opt/dmdbms/bin/libdmutl.so (0x00007f5851884000)
libdmclientlex.so => /opt/dmdbms/bin/libdmclientlex.so (0x00007f585164f000)
libdmos.so => /opt/dmdbms/bin/libdmos.so (0x00007f5851420000)
libdmcvt.so => /opt/dmdbms/bin/libdmcvt.so (0x00007f5850d3f000)
libdmstrt.so => /opt/dmdbms/bin/libdmstrt.so (0x00007f5850b29000)
librt.so.1 => /lib64/librt.so.1 (0x00007f5850915000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f58506f9000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f58504f4000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f58501ed000)
libm.so.6 => /lib64/libm.so.6 (0x00007f584feeb000)
libc.so.6 => /lib64/libc.so.6 (0x00007f584fb1d000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f584f907000)
libdmmem.so => /opt/dmdbms/bin/libdmmem.so (0x00007f584f6f5000)
libdmcalc.so => /opt/dmdbms/bin/libdmcalc.so (0x00007f584f474000)
/lib64/ld-linux-x86-64.so.2 (0x0000562c35c01000)
Assumption: libdodbc.so is not compatible with the system. Answer: both the driver and the system are x86_64.
Could there be any other reasons? Any help would be greatly appreciated!
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 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 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.
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