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

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 .

Related

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!!

gcc49 on Fedora 27: /usr/bin/ld: cannot find -lgcc_s

I am using the davidva/gcc49 copr, on Fedora 27.
When I try to compile after running source /usr/bin/gcc49 as the copr webpage describes, I get this error:
/usr/bin/ld: cannot find -lgcc_s
After learning about how the flag -l works for gcc, I learned it is looking for library gcc_s. I found it in /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64, which sounds like the right spot for it to be. Why is it not linking? Do I need to add a directory to a library path? If it's LDFLAGS, it's already there because of the file I sourced:
export LDFLAGS="-L/opt/gcc-$gver/$lib/gcc/$gcc_target_platform/$lib/"
What do I need to do to get gcc 4.9 on Fedora 27 to find its library file which is clearly in the LDFLAGS directory?
The problem is that the libgcc_s.so file is in the wrong directory! Just symlink to it in the 4.9.3 directory:
pushd /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/4.9.3
sudo cp -p ../lib64/libgcc_s.so.1 .
sudo ln -s libgcc_s.so.1 libgcc_s.so
popd
I guess the /opt/gcc-4.9.3/lib64/gcc/x86_64-fedoraunited-linux-gnu/lib64 directory was supposed to be included in any LDFLAGS parameter, and that might be a weakness of the build process I was using and not the gcc 4.9 package.
Putting this file and appropriately-named symlink in the 4.9.3 directory allows my build process to complete successfully.
Reference: https://bgstack15.wordpress.com/2018/02/01/gcc-4-9-for-fedora-27/

Portable binaries with Rust

I have problems building a portable executable with rust.
Running an executable simply built with cargo build on Ubuntu fails with
./test: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./test)
Building with rustc ... -C link-args=-static fails to link correctly (output of ld ./test):
ld: error in ./test(.eh_frame); no .eh_frame_hdr table will be created.
Is there a way around this except building on an older system with an old glibc version?
Glibc is not linked statically (much as we might have liked to, it goes out of its way to prevent this). As a result, the system libraries (libstd and such) are always dependent on the glibc version on which they were built. This is why the buildbots in the linux cluster mozilla uses are/were old versions of centos.
See https://github.com/rust-lang/rust/issues/9545 and https://github.com/rust-lang/rust/issues/7283
Unfortunately at this time I believe there is no workaround aside from making sure you build on a system with an older glibc than you're going to deploy to.
To avoid GLIBC errors, you can compile your own version of Rust against a static alternative libc, musl.
Get the latest stable release of musl and build it with option --disable-shared:
$ mkdir musldist
$ PREFIX=$(pwd)/musldist
$ ./configure --disable-shared --prefix=$PREFIX
then build Rust against musl:
$ ./configure --target=x86_64-unknown-linux-musl --musl-root=$PREFIX --prefix=$PREFIX
then build your project
$ echo 'fn main() { println!("Hello, world!"); }' > main.rs
$ rustc --target=x86_64-unknown-linux-musl main.rs
$ ldd main
not a dynamic executable
For more information, look at the advanced linking section of the documentation.
As reported in the original documentation:
However, you may need to recompile your native libraries against musl
before they can be linked against.
You can also use rustup.
Remove old Rust installed by rustup.sh
$ sudo /usr/local/lib/rustlib/uninstall.sh # only if you have
$ rm $HOME/.rustup
Install rustup
$ curl https://sh.rustup.rs -sSf | sh
$ rustup default nightly #just for ubuntu 14.04 (stable Rust 1.11.0 has linking issue)
$ rustup target add x86_64-unknown-linux-musl
$ export PATH=$HOME/.cargo/bin:$PATH
$ cargo new --bin hello && cd hello
$ cargo run --target=x86_64-unknown-linux-musl
$ ldd target/x86_64-unknown-linux-musl/debug/hello
not a dynamic executable

Installing Bio::DB::Sam perl module

I am trying to install a perl module Bio::DB::Sam on my home directory on a remote server.
I downloaded the module, extracted the files, and ran:
perl Build.pl prefix=~/local
this is what happens next:
This module requires samtools 0.1.10 or higher (samtools.sourceforge.net).
Please enter the location of the bam.h and compiled libbam.a files: **/some_places/samtools-0.1.19**
Found /some_places/samtools-0.1.19/bam.h and /some_places/samtools-0.1.19/libbam.a.
Created MYMETA.yml and MYMETA.json
Creating new 'Build' script for 'Bio-SamTools' version '1.39'
Next when I try to run:
./Build
this is what I get:
Building Bio-SamTools
gcc -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o blib/arch/auto/Bio/DB/Sam/Sam.so lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o -L/some_places/samtools-0.1.19 -lbam -lpthread -lz
/usr/bin/ld: /some_places/samtools-0.1.19/libbam.a(bgzf.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/some_places/samtools-0.1.19/libbam.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
error building blib/arch/auto/Bio/DB/Sam/Sam.so from lib/Bio/DB/Sam.o c_bin/bam2bedgraph.o at ~/perl5/lib/perl5/ExtUtils/CBuilder/Base.pm line 323.
I did google the possible solutions and tried a couple, but they didn't work, e.g. --enable-shared OR export CXXFLAGS="$CXXFLAGS -fPIC".
I have already have Bioperl installed on my home directory.
Any help would be appreciated.
Cheers
Here is a script that will fetch the SAMtools source and compile it, then fetch and compile the Perl bindings.
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
export SAMTOOLS=`pwd`
cpanm Bio::DB::Sam
Part of the problem you were likely seeing is that the SAMtools project has recently undergone some major code reorganization (and this has naturally made it difficult to work with external language bindings).
I fixed this issue by remaking samtools with the -fPIC parameter
make clean
make CXXFLAGS=-fPIC CFLAGS=-fPIC CPPFLAGS=-fPIC
then installed using cpan.
cpan[2]> install Bio::DB::Sam
[Solved]
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
enter cpan in terminal and enter
install Bio::DB::Sam
Be carefully:
You can not use the following command:
perl -MCPAN -Mlocal::lib -e 'CPAN::install(Bio::DB::Sam)'
You can only use cpan and then use
install Bio::DB::Sam
I followed instructions from README file below of Bio-SamTools-1.43 to edit the Makefile in samtools 0.1.17. Then, to install, I used
perl -MCPAN -e shell
install Bio::DB::Sam
README:
This is a Perl interface to the SAMtools sequence alignment
interface. It ONLY works on versions of Samtools up to 0.1.17. It does
not work on version 1.0 or higher due to major changes in the library
structure.
See http://samtools.sourceforge.net/ for samtools documentation.
ONE-STEP INSTALLATION
In the root directory of this distribution you will find the script
INSTALL.pl. Running this will download the latest versions of this
module and SamTools into a temporary directory, compile them, test and
install. Simply run:
perl INSTALL.pl
MULTI-STEP INSTALLATION
The more traditional install requires you to separately download,
unpack and compile SAMtools 0.1.10 through 0.1.17 in some accessible
directory. Typing "make" in the samtools directory will usually
work. SAMtools versions 0.1.18 and higher do not work with this
library.
Then set the environment variable SAMTOOLS to point to this directory.
You will also need to install Bio::Perl from CPAN.
Now run:
perl Build.PL
./Build
./Build test
(sudo) ./Build install
TROUBLESHOOTING:
If you encounter problems during compiling, you may need to edit
Build.PL so that extra_compiler_flags matches the CFLAGS and DFLAGS
settings in the Samtools Makefile. Here are some common problems:
When building this module, you get an error like the following:
relocation R_X86_64_32 against `a local symbol' can not be used when
making a shared object; recompile with -fPIC
To fix this, edit the Makefile in the Samtools distribution by adding
"-fPIC" to the CFLAGS line. While you're at it, you may also wish to
get rid of a bunch of unused variable warnings that appears under
recent versions of gcc. The modified CFLAGS will look like this
CFLAGS= -g -Wall -Wno-unused -Wno-unused-result -O2 -fPIC #-m64 #-arch ppc
Then do "make clean; make" in the Samtools directory to recompile the
library. After this you should be able to build this module without
errors.
When building this module, you get an error about a missing math
library.
To fix this, follow the recipe in (1) except add -m64 to CFLAGS so it
looks like this:
CFLAGS= -g -Wall -O2 -fPIC #-m64 #-arch ppc
TESTING AND CONTRIBUTING:
You can obtain the most recent development version of this module via
its GitHub site at https://github.com/GMOD/GBrowse-Adaptors. Please
feel free to submit bug reports, patches, etc. via GitHub.
AUTHOR:
Lincoln D. Stein
Copyright (c) 2009-2015 Ontario Institute for Cancer Research
This package and its accompanying libraries are free software; you can
redistribute it and/or modify it under the terms of the Artistic
License 2.0, the Apache 2.0 License, or the GNU General Public License
(version 1 or higher). Refer to LICENSE for the full license text.

How to install XML::Parser without expat-devel?

XML::Parser fails to build on a quite fresh 64-bit Debian box. After issuing cpan XML::Parser, cpan fails with lots of errors about Expat.c and Expat.xs:
[...]
Expat.xs:2182: error: ‘CallbackVector’ has no member named ‘skip_until’
Expat.c: In function ‘XS_XML__Parser__Expat_Do_External_Parse’:
Expat.c:2904: error: ‘XML_Parser’ undeclared (first use in this function)
Expat.c:2904: error: expected ‘;’ before ‘parser’
Expat.xs:2194: error: ‘parser’ undeclared (first use in this function)
make[1]: *** [Expat.o] Error 1
make[1]: Leaving directory `/root/.cpan/build/XML-Parser-2.41-rpV6ok/Expat'
make: *** [subdirs] Error 2
TODDR/XML-Parser-2.41.tar.gz
/usr/bin/make -- NOT OK
Running make test
Can't test without successful make
Running make install
Make had returned bad status, install seems impossible
Message at the start of the output explains that expat-devel is needed for building.
Expat must be installed prior to building XML::Parser and I can't find
it in the standard library directories. Install 'expat-devel' package with your
OS package manager. See 'README'.
But expat-devel is not in Debian repository.
Is it possible to get over this without need to build/install expat from source?
The package you want to install is named libexpat1-dev. You could also just install libxml-parser-perl via apt-get. Or if you really want to install via CPAN try installing the Debian packages dependencies first via apt-get build-dep libxml-parser-perl.
libexpat1-dev contains both libexpat and expat.h, which are both mentioned in the message as well:
If expat is installed, but in a non-standard directory, then use the
following options to Makefile.PL:
EXPATLIBPATH=... To set the directory in which to find libexpat
EXPATINCPATH=... To set the directory in which to find expat.h
Installing libexpat1-dev seems to solve the problem:
$ aptitude install libexpat1-dev
There is always the manual method - to build/install expat from source.
(This example shows installing to an alternative location for XAMPP | LAMPP)
Download from:
http://sourceforge.net/projects/expat/files/expat/
tar zxf /[where-ever]/expat-2.1.0.tar.gz -C /tmp
cd /tmp/expat-2.1.0
/opt/lampp/bin/perl ./configure --prefix=/opt/lampp LDFLAGS=-L/opt/lampp/lib
make
make install
http://search.cpan.org - search for and download - XML::Parser
tar zxf /[where-ever]/XML-Parser-2.41.tar.gz -C /tmp
cd /tmp/XML-Parser-2.41
/opt/lampp/bin/perl ./Makefile.PL EXPATLIBPATH=/opt/lampp/lib EXPATINCPATH=/opt/lampp/include
make
make test
make install
Work like a charm in Ubuntu 15.04. The only thing that I need is install Perl XML Parser with:
sudo apt-get install libxml-parser-perl
And following the instructions here, I was able to import successfully all my ratings into Rhythmbox. Now, the only work that I need to do is create again the smart play lists, that is nothing compared with my entire libray ratings.
Today I had the same issue wanting to complile the new GIMP 2.9.4 beta on OSX 10.8 and the aid of homebrew.
First install perl
brew install perl
Then the XML::Parser module by going into the perl shell with
perl -MCPAN -e shell
And inside the shell install XML::Parser by typing
install XML::Parser
Exit shell
exit
Now, verify it has been installed successfully. If everything is ok, you will not see an error.
perl -e "require XML::Parser"
If the ./configure still fails missing XML::Parser, then intltools is not using the perl you have installed. Looking at the script tells me it does the test with $INTLTOOL_PERL -e "require XML::Parser". Trying a echo $INTLTOOL_PERL gave out nothing, so the magic is to set it with
export $INTLTOOL_PERL=perl
Now run ./configure again.
None of the above methods worked for me. I had the right environment variables setup but they were somehow not picked up by cpanm that I use to install perl modules. Expat was also installed.
Here is what I did to overcome the same problem that OP is reporting.
This is very close to what #LadyBuzz suggested.
Download the XML::Parser from cpan.org
Extract the tarball into directory and descend to it.
Open the Makefile.pl and edit the first lines to actually have the absolute paths to both: EXPATLIBPATH and EXPATINCPATH
Save the Makefile.pl, go up one level and create a new tarball with the Makefile.pl that you just edited.
Execute cpanm on the newly created tarball.
This resulted in successful installation of the module.