Could NOT find OpenSSL, try to set the path to OpenSSL root folder - github

I extracted Cmake zip file (downloaded from github) and tried to install it but an error occured.
I tried installing OpenSSL and tried to install Cmake but Error(same) is still comming
Terminal output is below :
CMake 3.16.20191118, Copyright 2000-2019 Kitware, Inc. and Contributors
Found GNU toolchain
C compiler on this system is: gcc
C++ compiler on this system is: g++
Makefile processor on this system is: make
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
g++ has <ext/stdio_filebuf.h>
---------------------------------------------
make: 'cmake' is up to date.
loading initial cache file /root/Cmake/Bootstrap.cmk/InitialCacheFlags.cmake
-- Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the system variable OPENSSL_ROOT_DIR (missing: OPENSSL_CRYPTO_LIBRARY OPENSSL_INCLUDE_DIR)
-- Configuring incomplete, errors occurred!
See also "/root/Cmake/CMakeFiles/CMakeOutput.log".
See also "/root/Cmake/CMakeFiles/CMakeError.log".
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
---------------------------------------------

I ran into the same problem today trying to compile cmake 3.16-rc4 under Ubuntu 18.04. While trying to fix that by setting appropriate paths and looking for them in the first place, I discovered this: How do I install the OpenSSL libraries on Ubuntu?
So the solution is to simply do:
sudo apt install libssl-dev
So cmake obviously needs the dev package of openssl. Kudos to Niki Yoshiuchi, who has given the desired answer in the linked question.

Related

How to force MATLAB 2016a to use gcc-4.7.x instead of the one I have (gcc-5.4.1)?

There are some posts about this for the older releases of MATLAB, but they don't seem to work for R2016a.
I'm trying to install MatConvNet on Ubuntu 16.04. When I run the vl_compilenn command as described here, it gives me a warning as follows:
Building with 'gcc'.
Warning: You are using gcc version '5.4.1'. The version of gcc is not supported.
The version currently supported with MEX is '4.7.x'. For a list of currently supported
compilers see: http://www.mathworks.com/support/compilers/current_release.
I have already installed gcc-4.7 and g++-4.7 using apt-get install gcc-4.7 g++-4.7. How can I force MATLAB to use these versions and not the default ones?
Few hints, not a complete tutorial how to do it.
Probably the simplest would be to edit the MATLAB's Mex XML configuration file:
mex -setup C
cc = mex.getCompilerConfigurations('C', 'Selected')
edit(cc.MexOpt)
The mex setup usually creates a copy in your home folder (~/.matlab/<version>/mex_C_glnca64.xml), so you should be able to edit it without root.
There you probably need to change the section:
<GCC>
<cmdReturns name="which gcc" />
</GCC>
which I guess searches for the location of the gcc command to your gcc version and assigns it to the $GCC variable. Plus you can change the version name in the header.
Additionally you need to do the same for the C++ language.
This works with R2016b:
Install the required GCC version with apt install (gcc-4.9 and g++-4.9 in my case).
Create a bin folder in your home, i.e. ~/bin.
Create the following links with ln:
ln -s /usr/bin/gcc-4.9 ~/bin/gcc
ln -s /usr/bin/g++-4.9 ~/bin/g++
If using CUDA, create a file called nvcc in the ~/bin folder, with the following contents (don't forget to make it executable: chmod +x ~/bin/nvcc):
Contents:
#!/bin/sh
exec /usr/lib/nvidia-cuda-toolkit/bin/nvcc -ccbin gcc-4.9 "$#"
If necessary replace /usr/lib/nvidia-cuda-toolkit/bin/nvcc with the correct location of the nvcc binary.
Open MATLAB and follow the instructions for compiling MatConvNet.

CMake fails to generate Makefiles with Sun Studio 12.5

I'm working on Solaris 11.3 with Sun Studio 12.5. When I attempt to configure with Cmake out-of-tree, Cmake finishes with configuration errors and does not produce the makefiles. In-tree may be broken, too. But our procedures say to build out-of-tree, so that;' what I do.
I have nearly no Cmake experience. Others contributed the the CMake files, and I struggle with tasks related to them. I'm not sure if I am doing something wrong, if our Cmake files are broken, or if Cmake is not well tested under Solaris.
What is going on with CMake, and how do I fix it?
Here are the links to the Cmake files. I can copy/paste them, but it just takes up a bunch of space. The files are hosted on GitHub so they should always be available.
CMakefileList.txt
cryptopp-config.cmake
Here is Solaris' Cmake version, prior to me installing 3.6.2:
$ cmake --version
cmake version 2.8.6
Below is from Solaris Cmake version 2.8.6.
cryptopp-build$ export CXX=/opt/developerstudio12.5/bin/CC
cryptopp-build$ export CXXFLAGS="-DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__ -D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__ -D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i"
cryptopp-build$ cmake ../cryptopp
-- The CXX compiler identification is unknown
-- Check for working CXX compiler: /bin/c++
-- Check for working CXX compiler: /bin/c++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "/bin/c++" is not able to compile a simple test program.
It fails with the following output:
Change Dir: /export/home/test/cryptopp-build/CMakeFiles/CMakeTmp
Run Build Command:/bin/gmake "cmTryCompileExec/fast"
/bin/gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
CMakeFiles/cmTryCompileExec.dir/build
gmake[1]: Entering directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
/usr/bin/cmake -E cmake_progress_report
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/CMakeFiles 1
Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
/bin/c++ -DNDEBUG -g2 -O2 -D__SSE2__ -D__SSE3__ -D__SSSE3__ -D__SSE4_1__
-D__SSE4_2__ -D__AES__ -D__PCLMUL__ -D__RDRND__ -D__RDSEED__ -D__AVX__
-D__AVX2__ -D__BMI__ -D__BMI2__ -D__ADX__ -xarch=avx2_i -o
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c
/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
c++: error: language arch=avx2_i not recognized
c++: error: language arch=avx2_i not recognized
gmake[1]: Leaving directory
`/export/home/test/cryptopp-build/CMakeFiles/CMakeTmp'
gmake[1]: *** [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o] Error
1
gmake: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:9 (project)
-- Configuring incomplete, errors occurred!
And:
$ /opt/developerstudio12.5/bin/CC -V
CC: Studio 12.5 Sun C++ 5.14 SunOS_i386 2016/05/31
I built Cmake 3.6.2 from sources and installed in /usr/local to attack the CXX compiler identification is unknown issue, but it appears to be having some troubles. As I said earlier, I'm not a Cmake expert (and I'm not sure how one can mess up a make && sudo make install).
cryptopp-build$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
Clearing the cache as suggested by #AndrewHenle results in:
# The project GNUmakefile clears all Cmake artifacts because Cmake cannot seem to do it on its own
$ cd cryptopp
$ git status -s
$
$ cd ..
$ rm -rf cryptopp-build
$ mkdir cryptopp-build
$ cd cryptopp-build
# Using 3.6.2 now
$ cmake ../cryptopp
CMake Error: Could not find CMAKE_ROOT !!!
CMake has most likely not been installed correctly.
Modules directory not found in
/usr/local/bin
CMake Error: Error executing cmake::LoadCache(). Aborting.
So there appeared to be two problems. First was the down level Sun supplied Cmake. There's nothing genius about diagnosing it as "too old".
The second issue was more interesting. It appears the CMake Error: Could not find CMAKE_ROOT !!! was cause by sudo make install Once I switched to sudo gmake install the issue went away.
Here are the bug reports on the issue:
Cmake Issue 16302: Cmake fails to identify Sun Studio 12.5 compiler
Cmake Issue 16303: Cmake fails to produce a working installation on Solaris 11.3

Unable to compile "hello world" program with Swift on Ubuntu 14.04

Using Ubuntu 14.04
Distributor ID: Ubuntu
Description: Ubuntu 14.04.3 LTS
Release: 14.04
Codename: trusty
and trying to compile a hello world Swift program.
print("Hello World!")
I have verified the download:
gpg --verify swift-2.2-SNAPSHOT-2015-12-10-a-ubuntu14.04.tar.gz.sig
gpg: Signature made Thu 10 Dec 2015 07:17:37 PM PST using RSA key ID 412B37AD
gpg: Good signature from "Swift Automatic Signing Key #1 <swift-infrastructure#swift.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7463 A81A 4B2E EA1B 551F FBCF D441 C977 412B 37AD
But when I try and compile the hello world program I get this error:
> swiftc hello_world.swift
<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directory
If I start up the Swift REPL I get a similar error:
~$ swift
Welcome to Swift version 2.2-dev (LLVM 7bae82deaa, Clang 53d04af5ce, Swift 5995ef2acd). Type :help for assistance.
1> y = 6
opening import file for module 'SwiftShims': No such file or directory
1>
If I follow the instructions given here on using "swift build" versus "swiftc" for compiling a Hello World Swift program, I get a different error:
$ swift build
<unknown>:0: error: opening import file for module 'Swift': No such file or directory
swift-build: exit(1): ["/home/scooter/Programs/Swift/V2.2/bin/swiftc", "--driver-mode=swift", "-I", "/home/scooter/Programs/Swift/V2.2/lib/swift/pm", "-L", "/home/scooter/Programs/Swift/V2.2/lib/swift/pm", "-lPackageDescription", "/home/scooter/code/swift/helloworld-project/Package.swift"]
Executing the interpreter:
$ swift hello_world.swift
gives
<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directory
strace gets an error trying to run swift:
$ strace -o /tmp/swift.log -- swift <(echo '1 + 1')
<unknown>:0: error: opening import file for module 'SwiftShims': No such file or directory
open("/home/user/Programs/Swift/V2.2/lib/swift/linux/x86_64/SwiftShims.swiftmodule",
O_RDONLY) = -1 ENOENT (No such file or directory)
Sorry for adding as an answer what should have really been a comment content-wise, but it is a little too long for a comment.
As far as I can tell, this is indeed the same problem as described in Swift on Linux: Make very first step work. I have been looking into this myself in my spare time, but no luck so far. The user who asked the other question has been pursuing it and has some interesting recent updates there.
A few things to try:
See if the swift interpreter works. Just type swift hello_world.swift and see what happens. I don't think it will work. If it does not, then run the strace command as follows:
strace -o /tmp/swift.log -- swift <(echo '1 + 1')
and look at /tmp/swift.log. See what files cannot be found, especially near the end of the output. Warning: even on a system where the error doesn't happen (I haven't been able to reproduce it yet), the strace output shows a lot of No such file... errors.
You can also try swift and swiftrc with the -v option to enable verbose output and see if you notice anything suspicious.
Update 1/2/2016:
The question referenced earlier has been updated with a possible solution to the problem: get rid of non-standard installations of gcc, g++, libgcc, and libstdc++. Please see the comments in the other question.
Update 1/3/2016:
Using the clues from the discussion on the other question, I've been able to reproduce the problem by installing gcc-5.1.0 from source and pre-pending the location of the newly-installed libstdc++.so.6 to the LD_LIBRARY_PATH variable.
The problem could be solved as follows:
1) Figure out where libstdc++.so.6 from the older package is installed. On my system:
user#ubuntu14:~$ dpkg -l | grep libstdc++
ii libstdc++-4.8-dev:amd64 4.8.4-2ubuntu1~14.04 amd64 GNU Standard C++ Library v3 (development files)
ii libstdc++6:amd64 4.8.4-2ubuntu1~14.04 amd64 GNU Standard C++ Library v3
user#ubuntu14:~$ dpkg -L libstdc++6 | grep libstdc++.so
/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
2) Prepend the location of libstdc++.so.6 to $LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH
3) Double-check that the swift binary is using the correct shared library:
user#ubuntu14:~$ ldd `which swift` | grep libstdc++
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdd1476b000)
Now Swift should work without the error in question.
Do you have a non standard install using a PPA or any libraries for the build chain built from source? Particularly libstdc++. Please see my answer for Swift on Linux: Make very first step work.

Trying to install PostStat, a library to add statistics function into Postgres

I am trying to install Poststat on debian squeeze.
http://poststat.projects.postgresql.org
This project looks not so old (2008), but I am having some difficulties to install it. Although it seems to be a really interesting project, google is empty. I'll try here to sum up what I did (postgres 8.4 is installed) :
apt-get install fort77 postgresql-server-dev-8.4 libblas-dev liblapack-dev gfortran
First, as it is said on the official website, unpack the tar.gz and go in the directory f77stat and 'make'.
Then if you have libpq-dev installed, on debian squeeze it install also its owns pg_config in /usr/bin/ wich report false infos. (see http://postgresql.1045698.n5.nabble.com/Bug-report-Wrong-version-in-pg-config-td2123792.html)
One solution :
mv /usr/bin/pg_config pg_config_bak
ln -s /usr/lib/postgresql/8.4/bin/pg_config pg_config
This is important because the makefile of Poststat is retrieving some info with pg_config.
Then in the main Makefile there is the line :
-lblas -llapack -lg2c
Install those package for blas and lapack :
apt-get install libatlas-base-dev libatlas-dev libatlas-doc libatlas3gf-base
Now my problem is about g2c. According to google, g2c is obsolete so I edited the Makefile and replace -lg2c with -lgfortrant
Last step :
compile and import the new statitics functions in my database.
make && sudo make install
psql -f poststat.sql <database>
Sadly,
psql:poststat.sql:18: ERROR: unable to load the library
« /usr/lib/postgresql/8.4/lib/poststat.so » : /usr/lib/postgresql/8.4/lib/poststat.so:
undefined symbol: s_stop
Any thought ? fortran is not my world, and packages seem to have change a lot in debian about fortran. My switch from -lg2c to -lgfortrant is probably wrong. In fact removing this include does at the end produce the same error.
libg2c belongs to the g77 (http://stackoverflow.com/questions/2406581/what-is-libg2c-library), which is obsolete and unsupported for many years. Switching to a more current compiler involves more than just replacing this library. You need to replace the compiler also, e.g., gfortran. You might need to change the default compiler options of gfortran to be able to compile FORTRAN 77 code. I use: -O2 -ffixed-form -ffixed-line-length-none. If you use gfortran as the linker you won't need to explicitly include the fortran run-time library.
change -lg2c by -lf2c
Add to poststat.c , at the end
int MAIN__(){
return (0);
}

How do you install perl DBD::Oracle on OSX Snow Leopard 10.6

I'm trying to connect to Oracle 10.2.0.4 on a remote system from my intel mac running OSX 10.6 snow leopard. I've tried using perl CPAN to install DBD::Oracle (DBI worked ok) but get compilation errors. Could someone provide an easy to follow guide?
Getting a mac install of perl to play nicely with oracle is a bit of a pain - once it's running it is fantastic, getting it running is a little frustrating..
The below has worked for me on a few different intel macs, there could well be superfluous steps in there and it is likely not going to be the same for other platforms.
This will require use of shell, the root user and a bit of CPANing - nothing too onerous
First off create a directory for the oracle pap - libraries, instant client etc
sudo mkdir /usr/oracle_instantClient64
Download and extract all 64 bit instant client packages from oracle to the above directory
Create a symlink within that directory for one of the files in there
sudo cd /usr/oracle_instantClient64
sudo ln -s /usr/oracle_instantClient64/libclntsh.dylib.10.1 libclntsh.dylib
The following dir is hardcoded into the oracle instant client - god knows why - so need to create and symlink it
sudo mkdir -p /b/227/rdbms/
sudo cd /b/227/rdbms/
sudo ln -s /usr/oracle_instantClient64/ lib
Need to add a couple of environment variables, so edit /etc/profile and add them so they exist for all users:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now try and install DBD::Oracle through CPAN - this will fail, but it means any dependencies will be downloaded and it retrieves the module for us
sudo perl -MCPAN -e shell
install DBD::Oracle
When this fails exit CPAN and head to your .cpan/build dir - if you used automatic config of CPAN it'll be
cd ~/.cpan/build
if you didn't auto configure you can find your build directory with the following command in CPAN
o conf build_dir
Once in the build dir look for the DBD::Oracle dir which has just been created (it'll be called something like DBD-Oracle-1.28-?) and cd into it.
Now we need to switch to the root user. Root isn't enabled as default in osx - for details on enabling see this post on the apple website
Once logged in as root we need to set the above environment variables for root:
export ORACLE_HOME=/usr/oracle_instantClient64
export DYLD_LIBRARY_PATH=/usr/oracle_instantClient64
Now while still logged in as root we need to run the makefile for the module, then make, then install
perl Makefile.pl
make
make install
Assuming that all worked without error log out of root: we're DBD'd up! If this didn't work it's time to bust out google on whatever errors you're seeing
Now just to install the DBI module
sudo perl -MCPAN -e shell
install DBI
Now you're all set - enjoy your perly oracley new life
Additional info from user852637:
Correction to this step
perl Makefile.pl
make
install
The last step should be make install
During make, you may encounter an error that looks like :
lipo: can't open input file: /var/tmp//ccIevTzM.out (No such file or directory)
To correct this you must edit the file "Makefile" created after the "perl Makefile.pl" step and remove all occurrences of the following text :
-arch ppc
This will eliminate the error.
The same error described in (2.) will occur during the installation of the DBI module. You must edit the Makefile created after the perl Makefile.pl step and remove all occurrences of the following text :
-arch ppc
It looks with the XCode4 change (removal of PPC arch support) the Perl installation was not updated in any of the 10.6.X updates to also remove PPC binaries (probably because Rosetta is still present).
Because of this, the configuration files retain "-arch ppc" causing all CPAN module compiles with C libraries to fail because MakeMaker's output Makefile contains -arch ppc.
To fix this one can edit the following file:
/System/Library/Perl/5.10.0/darwin-thread-multi-2level/Config_heavy.pl
at line 1219 you'll see:
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch x86_64 -arch i386 -arch ppc';
change that to:
$archflags = exists($ENV{ARCHFLAGS}) ? $ENV{ARCHFLAGS} : '-arch x86_64 -arch i386';
Once you do this the generated Makefile will be correct.
These are a great set of instructions. I have a few other comments about potential "gotchas".
Correction to this step
perl Makefile.pl
make
install
The last step should be make install
During make, you may encounter an error that looks like :
lipo: can't open input file: /var/tmp//ccIevTzM.out (No such file or directory)
To correct this you must edit the file "Makefile" created after the "perl Makefile.pl" step and remove all occurrences of the following text :
-arch ppc
This will eliminate the error.
The same error described in (2.) will occur during the installation of the DBI module. You must edit the Makefile created after the perl Makefile.pl step and remove all occurrences of the following text :
-arch ppc
It seems as though the "Perl MakeFile.pl" command is not finding the version of Perl correctly and I get this error message:
bash-3.2# perl Makefile.PL
Multiple copies of Driver.xst found in: /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 37
Using DBI 1.616 (for perl 5.010000 on darwin-thread-multi-2level) installed in /Library/Perl/5.10.0/darwin-thread-multi-2level/auto/DBI/
Configuring DBD::Oracle for perl 5.010000 on darwin (darwin-thread-multi-2level)
Remember to actually *READ* the README file! Especially if you have any problems.
Installing on a darwin, Ver#10.0
Using Oracle in /usr/oracle_instantClient64
Can't find sqlplus. Pity, it would have helped.
I'm having trouble finding your Oracle version number... trying harder
WARNING: I could not determine Oracle client version so I'll just
default to version 8.0.0.0. Some features of DBD::Oracle may not work.
Oracle version based logic in Makefile.PL may produce erroneous results.
You can use "perl Makefile.PL -V X.Y.Z" to specify a your client version.
Oracle version 8.0.0.0 (8.0)
DBD::Oracle no longer supports Oracle client versions before 9.2
Try a version before 1.25 for 9 and 1.18 for 8! at Makefile.PL line 175.
I've triple checked that I've downloaded and installed the proper 64-bit drivers from Oracle. I also checked to make sure that I'm running 64-bit Perl.
If I force the version number like this:
perl MakeFile.pl -V 10.2.0.4
It completes, but I receive the error message when running "make":
Oracle.c:2267: error: ‘SQLT_BIN’ undeclared (first use in this function)
Oracle.c:2277: error: ‘SQLCS_NCHAR’ undeclared (first use in this function)
Oracle.c:2281: error: ‘SQLT_INT’ undeclared (first use in this function)
Oracle.c:2283: error: ‘OCI_FETCH_PRIOR’ undeclared (first use in this function)
Oracle.c:2287: error: ‘OCI_FETCH_NEXT’ undeclared (first use in this function)
lipo: can't open input file: /var/tmp//ccyIFLPN.out (No such file or directory)
make: *** [Oracle.o] Error 1
I realize this is because of the "-arch ppc" argument that needs to be removed from Makefile, but even after removal the removal of all 32-bit references, I still saw the error message.
Running 10.6.8 Snow Leopard with Oracle Driver version 10.2.0.4
I found that the key to this issue was making sure that MakeFile.pl could find the Oracle version.
The problem I ran into was that Safari was downloading the zip files from Oracle.com, but unzipping them and somehow corrupting the library.
Instead, I used a different browser and downloaded all the zip files into one directory. Then I ran the following tar commands:
tar -xf instantclient-basic-10.2.0.4.0-macosx-x64.zip
tar -xf instantclient-sdk-10.2.0.4.0-macosx-x64.zip
tar -xf instantclient-sqlplus-10.2.0.4.0-macosx-x64.zip
The copy all the contents in the folder "instantclient_10_2" to $ORACLE_HOME (set previously)
sudo cp -R instantclient_10_2/* $ORACLE_HOME
Also, I did not need to edit the Makefile generated by the MakeFile.pl script to remove the "-arch ppc" references.
You should not recreate on your machine the same directory structure as of the client libraries packager.
Don't do mkdir -p /b/227/rdbms/
Use MacOSX library header management tools: otool and install_name_tool
For instance, I have updated the library headers to my deployment architecture:
otool -L /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1:
/ade/b/2649109290/oracle/rdbms/lib/libclntsh.dylib.11.1 (compatibility version 0.0.0, current version 0.0.0)
/ade/b/2649109290/oracle/ldap/lib/libnnz11.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
install_name_tool -id /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 \
-change /ade/b/2649109290/oracle/ldap/lib/libnnz11.dylib /usr/oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
otool -L /usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1:
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 (compatibility version 0.0.0, current version 0.0.0)
/usr/oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
Check all files that come with the Oracle instantclient libraries and fix the path of all dependent libs
otool -L adrci
otool -L genezi
otool -L libclntsh.dylib.11.1
otool -L libheteroxa11.dylib
otool -L libnnz11.dylib
otool -L libocci.dylib.11.1
otool -L libociei.dylib
otool -L libocijdbc11.dylib
otool -L libsqlplus.dylib
otool -L libsqlplusic.dylib
otool -L sqlplus
otool -L uidrvci
Then, you link your dynamic libraries to the place they're supposed to be.
And you can avoid using that export DYLD_LIBRARY_PATH because you know how to setup your system
cd /usr/lib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libclntsh.dylib.11.1 libclntsh.dylib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libheteroxa11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libnnz11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocci.dylib.11.1 .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocci.dylib.11.1 libocci.dylib
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libociei.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libocijdbc11.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libsqlplus.dylib .
ln -s ../oracle_instantclient/11.2.0.3.0-64-bit/libsqlplusic.dylib .