Installing pkg-config files to proper path on CentOS with automake - centos

I have a couple projects I maintain that are built using automake (let's call them lib1 and lib2). lib2 is dependent on lib1 as a library and I'm having some issues with the pkg-config defaults on CentOS. Ideally, I'd like users to not have to set any environment variables to get everything to install properly.
Right now, it's just assuming ${PREFIX}/lib/pkgconfig as the destination for my .pc files, but on CentOS 7, the default for ${PREFIX} is /usr/local but pkgconfig by default only looks in /usr/share/pkgconfig and /usr/lib64/pkgconfig. Therefore, lib2 can't find lib1 with pkg-config and the configure script blows up.
So, the question is, how can my make install in lib1 properly detect the directory to install the pkg-config files?

From man pkg-config
PKG_INSTALLDIR(DIRECTORY)
Substitutes the variable pkgconfigdir as the location where a module should install pkg-config .pc files. By default the
directory is $libdir/pkgconfig, but the default can be changed by passing DIRECTORY. The user can override through the
--with-pkgconfigdir parameter.
This allows you expose the install-directory of the pkg-config file to the user (and - if your distribution patched pkg-config to use non-standard search-paths, it hopefully will pick the proper default for your system).
Example:
configure.ac:
[...]
PKG_INSTALLDIR
[...]
Makefile.am:
[...]
pkgconfig_DATA = lib1.pc
[...]
Usage
$ ./configure --prefix=/usr --with-pkgconfigdir=/usr/lib64/pkgconfig
Note
Please do not make distro-specific assumptions about where pkg-config will look for files.
Always use the defaults (they are defaults for good reasons), and provide a way to override these defaults for non-standard systems.
There are a lot distributions out there, and just because in my community one is prevailing, this doesn't mean that this is true for other communities (or not going to change).
If your distro does not follow the standard that's ok, but it should be consistent; if it fails to do be consistent (e.g. pkg-config looking for files in /foo/baz, but PKG_INSTALLDIR expanding pkgconfigdir to /usr/lib/pkg-config), then you should report a bug at your distribution.
Also I think it rather weird, that your pkg-config won't search for files in /usr/local.
E.g. on my Debian/sid system, it first searches /usr/local and then /usr:
$ which pkg-config
/usr/bin/pkg-config
$ strace -e trace=open pkg-config --cflags foo 2>&1 | grep /usr
open("/usr/local/lib/x86_64-linux-gnu/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/local/share/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/lib/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/usr/share/pkgconfig", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
$

Related

perl DBI module installation erroring out

perl DBI module installation is erroring out.
Installed perl 5.32.1 in non standard location, using -Dinstallprefix option
./Configure -Dinstallprefix=/test/user/home/perl -des
make
make test
make install
/test/user/home/perl/bin/perl -version
This is perl 5, version 32, subversion 1 (v5.32.1) built for x86_64-linux
Set PERL5LIB env variable
export PERL5LIB="/test/user/home/perl/lib/5.32.1:/test/user/home/perl/lib/site_perl/5.32.1:/test/user/home/perl/lib/5.32.1/x86_64-linux"
which perl
/test/user/home/perl/bin/perl
Downloaded DBI-1.643 archive, after extraction execution of Makefile.PL is failing
perl Makefile.PL
Warning: PERL_LIB (/perl/lib/5.32.1) seems not to be a perl library directory
(strict.pm not found) at /test/user/home/perl/lib/5.32.1/ExtUtils/MM_Unix.pm line 1934.
Have /test/user/home/perl/lib/5.32.1/x86_64-linux
Want /perl/lib/5.32.1/x86_64-linux
Your perl and your Config.pm seem to have different ideas about the
architecture they are running on.
Perl thinks: [x86_64-linux]
Config says: [x86_64-linux]
This may or may not cause problems. Please check your installation of perl
if you have problems building this extension.
Can't stat /perl/lib/5.32.1: No such file or directory
at Makefile.PL line 280.
Can't stat /perl/lib/5.32.1/x86_64-linux: No such file or directory
at Makefile.PL line 280.
Failed to opendir '/perl/lib/5.32.1/x86_64-linux/CORE' to find header files: No such file or directory at /test/user/home/perl/lib/5.32.1/ExtUtils/MM_Any.pm line 3048.
Found non existing paths are referred from #INC
perl -e "print \"#INC\""
/test/user/home/perl/lib/5.32.1 /test/user/home/perl/lib/site_perl/5.32.1 /test/user/home/perl/lib/5.32.1/x86_64-linux
/perl/lib/site_perl/5.32.1/x86_64-linux /perl/lib/site_perl/5.32.1 /perl/lib/5.32.1/x86_64-linux /perl/lib/5.32.1
Can someone guide me where from #INC getting these non existing paths
/perl/lib/site_perl/5.32.1/x86_64-linux /perl/lib/site_perl/5.32.1 /perl/lib/5.32.1/x86_64-linux /perl/lib/5.32.1
are there any way to restrict #INC to append non existing paths?
I think you want just -Dprefix=/.... There are other things that need to end up in the right place too. You shouldn't need to set PERL5LIB though because perl should be using your prefix as its default #INC. What does your perl -V show?
There is an installprefix, but it's aimed at compiling on one machine and installing on another. However, the INSTALL docs also recommend against using that. Is that what you are trying to do?
As for the other directories, the INSTALL docs describe the various directories that show up in #INC.
Thank you #brian for pointing me in right direction.
Following was the root cause behind #INC contains non existing directories.
Last time during perl installation at least one time I ran following command
./Configure -des -Dprefix=/perl
Use relocatable #INC? [n]
Pathname where the private library files will reside? (~name ok)
[/perl/lib/5.32.1]
Where do you want to put the public architecture-dependent libraries? (~name ok)
[/perl/lib/5.32.1/x86_64-linux]
Pathname for the site-specific library files? (~name ok)
[/perl/lib/site_perl/5.32.1]
Pathname for the site-specific architecture-dependent library files? (~name ok)
[/perl/lib/site_perl/5.32.1/x86_64-linux]
then executed make command. Later on make test failed for other error.
Then without running make distclean command, I re ran Configure with
-Dinstallprefix option
./Configure -Dinstallprefix=/test/user/home/perl -des
This populate #INC as follows
/test/user/home/perl/lib/5.32.1 /test/user/home/perl/lib/site_perl/5.32.1 /test/user/home/perl/lib/5.32.1/x86_64-linux
/perl/lib/site_perl/5.32.1/x86_64-linux /perl/lib/site_perl/5.32.1 /perl/lib/5.32.1/x86_64-linux /perl/lib/5.32.1
To fix this issue executed following steps,
make distclean
./Configure -des -Dprefix=/test/user/home/perl -Dusethreads
now #INC is populated correct
#INC:
/test/user/home/perl/lib/site_perl/5.32.1/x86_64-linux-thread-multi
/test/user/home/perl/lib/site_perl/5.32.1
/test/user/home/perl/lib/5.32.1/x86_64-linux-thread-multi
/test/user/home/perl/lib/5.32.1
Now DBI installation ran successfully.

Mac M1 Homebrew Perl Carton Net::SSLeay is loading libcrypto in an unsafe way

I'm trying to install Net::SSLeay with Carton.
The installation fails with this message
Configuring Net-SSLeay-1.90 Running Makefile.PL Do you want to run external tests?
These tests *will* *fail* if you do not have network connectivity. [n] n
*** Found LibreSSL-2.8.3 installed in /usr
*** Be sure to use the same compiler and options to compile your OpenSSL, perl, and Net::SSLeay. Mixing and matching compilers is not supported.
Checking if your kit is complete... Looks good
WARNING: /opt/homebrew/Cellar/perl/5.32.1_1/bin/perl is loading libcrypto in an unsafe way -> N/A
I've tried this with system perl, brew perl and multiple perlbrew perls.
Google came up with a temp solution to build homebrew using x86_64 architecture.
This did work for the libcrypto error, but gave me a whole different set of issues including mysql not running anymore.
Other "solutions" that I've tried are symlinking libssl & libcrypto as suggested by numerous other posts, all sadly without success.
Any ideas how to fix this or work around this without having to reinstall all brew packages as x86_64 ?
Quick Workaround
If you are looking for a quick workaround follow these steps.
Run carton bundle to create a vendor cache directory.
Go to cached tarball 'cache/authors/id/C/CH/CHRISN/' and unpack tar -xvzf Net-SSLeay-1.90.tar.gz
Edit Makefile.PL, change my $prefix = find_openssl_prefix(); to
my $prefix = '/opt/homebrew/opt/openssl#1.1'; ** adjust to your openssl location.
Save and create new tarball tar -czvf Net-SSLeay-1.90.tar.gz Net-SSLeay-1.90
Run carton install --cached to use the altered version
Hope this helps anyone in search of workaround
You can solve this in two steps:
upgrade ExtUtils::MakeMaker to at least version 7.58 (e.g. cpanm ExtUtils::MakeMaker)
install openssl via macports (sudo port install openssl) or homebrew (brew install --cask openssl)
After the Monterey update this broke again also on the x86_64 architecture, but just symlinking your latest openssl (where ever it is, depending how you have installed it) seemed to fix this. Example:
$ export OPENSSL_PREFIX=[find your openssl installation]
$ sudo ln -s $OPENSSL_PREFIX/lib/libssl.dylib /usr/local/lib/
$ sudo ln -s $OPENSSL_PREFIX/lib/libcrypto.dylib /usr/local/lib/
Better workaround:
I entered export OPENSSL_PREFIX=/opt/homebrew/opt/openssl#1.1 in my shell and then ran cpan. I checked the code in Makefile.PL and the first thing the function find_openssl_prefix does is to check the OPENSSL_PREFIX environment variable. If it is set, then it the function will return its contents.
Add the variable to your .profile, .cshrc, .bashrc, .zshrc, or whatever rc file your shell uses and you never have to worry about it again!!

CRYPTO_num_locks error occurs due to two versions of libcurl on Centos 7

I've trying to build some c++ libraries on a virtual Centos 7 distribution.
For a reason that I haven't found out this os can't see the /usr/local/lib or /usr/local/lib64 where these libraries are installed as other linux distributions do. So I had to add these folders on /etc/ld.so.conf. Then the c++ linker was able to see these libraries.
However when afterwards I gave
sudo yum update
I got the following message:
/usr/lib64/python2.7/site-packages/pycurl.so: undefined symbol: CRYPTO_num_locks
After searching I found that it was cause due to the existence of two version of libcurl. I gave
ldconfig -v | grep libcurl
And I got the following :
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
libcurl.so.4 -> libcurl.so.4.4.0
libcurl.so.4 -> libcurl.so.4.3.0
Meaning that I installed a new version of libcurl and now two versions coexist.
When I removed the folder paths from the /etc/ld.so.conf then yum worked fine but c++ linker could not find the c++ libaries that my app needs. I also tried to update the LD_LIBRARY_PATH but I had the same problems.
Is there a way to fix this issue without having reinstall the libraries on new location ? Is it safe to remove the older version?
The ls -lsa /usr/lib64/*curl* gave
0 lrwxrwxrwx. 1 root root 16 Aug 10 10:19 /usr/lib64/libcurl.so.4 -> libcurl.so.4.3.0
428 -rwxr-xr-x. 1 root root 435120 Nov 14 2016 /usr/lib64/libcurl.so.4.3.0
I tried giving
sudo unlink /usr/lib64/libcurl.so.4
sudo ln -s /usr/local/lib/libcurl.so.4.4.0 /usr/lib64/libcurl.so.4
I even gave them as root but every time I give ldconfig I get
libcurl.so.4 -> libcurl.so.4.3.0
while before ldconfig gives
libcurl.so.4 -> /usr/local/lib/libcurl.so.4.4.0
I had this same issue, but I didn't have two versions of curl or pycurl installed on my system. One of my end user software installs, changed the LD_LIBRARY_PATH and it didn't include /usr/lib or /usr/lib64. I tried adding them at the end of the path and I still received the same error. I added them to the front, and no more error. I have to inquire with my end user if there's a legitimate reason they excluded the default libraries from the enviroment variable.
The default path for standard libraries, as far as I know, on CentOS is /usr/lib and /usr/lib64. If you compiling from source, without explicitly specify the library path when you use ./configure, those libraries will be installed by default in /usr/local/lib or /usr/local/lib64 (usually lib64 is found on 64 bit OS). So if the libraries are installed there, you should add those path in /etc/ld.so.conf and run a ldconfig afterwards;
According to your example:
ldconfig: Path `/usr/lib' given more than once
ldconfig: Path `/usr/lib64' given more than once
libcurl.so.4 -> libcurl.so.4.4.0
libcurl.so.4 -> libcurl.so.4.3.0
libcurl.so.4 is linked to 2 different library versions and I think that's the cause of your issue.
You could remove the second link, libcurl.so.4 -> libcurl.so.4.3.0, leaving libcurl.so.4 only linked to libcurl.so.4.4.0, run ldconfig and try again.

How do I set up my Dockerfile to use cpanm to install a specific version of a Perl module?

Within my Dockerfile, I am setting up the Perl modules that will be installed when run, like so:
RUN ["cpanm", "Carp", "Carp::Heavy", "Class::Data::Inheritable"]
However, for one module, I need a specific version of a module, not the latest one. How can I specify that version in the above line?
I've been searching online for hours, and haven't turned up anything useful yet.
Instead of specifying a module name, specify a URL. Eg, instead of Class::Data::Inheritable, use https://cpan.metacpan.org/authors/id/T/TM/TMTM/Class-Data-Inheritable-0.06.tar.gz
You can find the applicable URL by going to the module page on metacpan, selecting the version you want, and copying the download link.
PS: You might want to also set PERL_CPANM_OPT=--from https://cpan.metacpan.org/ in the environment so cpanm only downloads using HTTPS.
For anyone who's searching for this same answer in the future, another option can be found here in the documentation for cpanm:
cpanm Plack#0.9990
If you have a long list of modules, consider feeding a cpanfile into cpanm rather than listing them all in the Dockerfile.
The easiest way to specify a particular version number for a module in a cpanfile is like this:
requires 'Text::ParseWords', '==3.1';
The syntax for requesting the latest version of a module is this:
requires 'Text::ParseWords';
Requesting a minimum version: (note the lack of '==')
requires 'Text::ParseWords', '3.1';
The syntax for requesting specific versions in other ways is fairly well-documented here.
Another great write-up of the use of cpanm and a cpanfile can be found
in Installation of cpan modules by cpanm and cpanfile.
To have CPAN install a specific version of a module, you need to provide the full module distribution filename including the author. For example to install the module Set::Object version 1.28, at the command line type:
cpan SAMV/Set-Object-1.28.tar.gz
Same thing apply with Docker, just add
RUN cpan SAMV/Set-Object-1.28.tar.gz
To specify target module version you can use
cpanm MIYAGAWA/Plack-0.99_05.tar.gz # full distribution path
cpanm http://example.org/LDS/CGI.pm-3.20.tar.gz # install from URL
cpanm ~/dists/MyCompany-Enterprise-1.00.tar.gz # install from a local file
See official documentation: https://metacpan.org/dist/App-cpanminus/view/bin/cpanm
But better, to my mind, would be to use cpanfile. See --cpanfile option https://metacpan.org/dist/App-cpanminus/view/bin/cpanm#-cpanfile and format of this file https://metacpan.org/pod/cpanfile
But if you have many modules (like me), I recommend to use cpm. It installs modules in parallel very fast. Also with help of docker we could cache builds, thus rebuilds will takes seconds. Here is my Dockerfile:
## Modules
WORKDIR ${APP_ROOT}
# install modules outside of WORKDIR, so it will not interfere when we do COPY . .
RUN mkdir -p ../modules
RUN ln -s ../modules local
RUN cpanm -n -L ./local App::cpm Carton::Snapshot && rm -rf /root/.cpanm
COPY cpanfile ./
COPY cpanfile.snapshot ./
RUN \
--mount=type=cache,target=/root/.perl-cpm \
cpm install -w 16 --no-test -L ./local \
--with-develop
# regenerate cpanfile.snapshot
# https://github.com/miyagawa/Carmel#cpm
# cpm doesn't have the ability to manage cpanfile.snapshot file on its own.
RUN carton install
# You can copy snapshot from container by running:
# docker cp <container_name>:${APP_ROOT}/cpanfile.snapshot.latest ./cpanfile.snapshot

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 .