|Installing Oracle's BerkeleyDB and Perl's BerkeleyDB|
|The Shell and the Path|
|Downloading the Test Program|
On 2015-03-02 I installed db-6.1.23.tar.gz and the Perl wrapper BerkeleyDB-0.55.tar.gz. Here's how:
I downloaded V 6.1.23 from Oracle.
From there, basically everything went well, although the docs are a little bit confusing. To summarize:
shell> tar xvzf db-6.1.23.tar.gz shell> cd db-6.1.23/build_unix shell> ../dist/configure --enable-sql --enable-sql_compat shell> make shell> sudo make install
Everything ends up in /usr/local/BerkeleyDB.6.1/.
So far, so good. The next problem is beat Debian and Perl over the head until they come to the party...
This package has to be edited before you can install it, so download the distro and unpack it.
Now edit BerkeleyDB-0.55/config.in. Here are my changes:
ron@zigzag:~/Downloads$ diff BerkeleyDB-0.55/config.in config.in 12c12 < INCLUDE = /usr/local/BerkeleyDB/include --- > INCLUDE = /usr/local/BerkeleyDB.6.1/include 21c21 < LIB = /usr/local/BerkeleyDB/lib --- > LIB = /usr/local/BerkeleyDB.6.1/lib 43c43 < #DBNAME = -ldb-3.0 --- > DBNAME = -ldb
After reading the docs for ExtUtils::MakeMaker a few times, I ended up using this incantation:
shell> perl Makefile.PL INSTALL_BASE=/home/ron/perl5/perlbrew/perls/perl-5.20.2
since Perl's BerkeleyDB doesn't come with a Build.PL. Now:
shell> make shell> make test
both work. We seem to be making progress. Try:
shell> make install
Of course, we've all installed the marvellous Module::Version, which gives us the mversion script. So the 1st test is:
shell> mversion BerkeleyDB
returns 0.55, as expected. Let's run BerkeleyDB ourselves!
shell> perl -MBerkeleyDB -e 1
$WTF!? We get an error: Can't locate loadable object for module BerkeleyDB in @INC ...
Of course, we're also installed the marvellous App::moduleswhere, which gives us the mwhere script. But:
shell> mwhere BerkeleyDB
also returns an error. $WTF x 2? How can this be? The version is available but the module itself is not? You-can't-be-serious!!?? I felt uneasy; I've never seen this before, except of course for previous versions of BerkeleyDB.
I assumed it was my fault, and so I spend a hour or so playing with ~/.bashrc and ~/.profile, trying to determine what was wrong.
I had needed to set $LD_LIBRARY_PATH in the past, so I suspected that was the problem. I also remembered I'd never had to use $LD_RUN_PATH, although I did play with it too.
All this lead me to summarize the experience in my other blog: Bash and Its Startup File Execution Algorithm.
Eventually, I wondered if Perl itself, via BerkeleyDB's Makefile.PL was at fault. Studying the output of that carefully, and running 'find' to find to installed BerkeleyDB.pm, I realized the INSTALL_BASE option I used (above) lead to the module being installed in the 'wrong' directory. Not happy.
shell> cd /home/ron/perl5/perlbrew/perls/perl-5.20.2/lib/ shell> mv perl5/x86_64-linux/auto/BerkeleyDB site_perl/5.20.2/x86_64/auto shell> mv perl5/x86_64-linux/B* site_perl/5.20.2/x86_64-linux/
Now all these work:
shell> mversion BerkeleyDB shell> mwhere BerkeleyDB shell> perl -MBerkeleyDB -e 1
There are 2 programs known as sqlite3, one from Oracle, and one from SQLite.org.
Does it matter? Yes, According to my tests (several years ago), they are incompatible :-(.
The Oracle one is installed by the above process into /usr/local/BerkeleyDB.6.1/bin.
The SQLite one (sqlite-shell-linux-x86-3080803.zip) can be downloaded from http://sqlite.org/download.html, and unzips to sqlite3. This means you can install it anywhere.
Since I only use DBD::SQLite to create SQLite databases, I always want the SQLite version of sqlite3.
So, I copy the unzipped file into ~/bin, and then, as explained next, put ~/bin into my $PATH env var before /usr/local/BerkeleyDB.6.1/bin.
I still have the latter dir in the path so I can run the other 16 executables which came with BerkeleyDB. And, by specifying the complete path, I can always run Oracle's version of sqlite3 if I have to.
Put these statements at the end of your ~/.profile:
# set PATH so it includes user's private bin if it exists if [ -d "$HOME/bin" ] ; then PATH="$HOME/bin:/usr/local/BerkeleyDB.6.1/bin:$PATH" fi
The order then, $HOME/bin before /usr/local/BerkeleyDB.6.1/bin, is significant.
With sqlite3 V 3080803 from SQLite.org, I can't run it. I use 'sqlite3' or './sqlite3', and get:
-bash: /home/ron/bin/sqlite3: No such file or directory
Works with MySQL, Postgres and SQLite: dbd.utf8.pl
The output shows that all 3 database servers just Do The Right thing without the user having to call encode()/decode().
Debian, MariaDB, Perl and DBD::mysql