in reply to Re^4: Can't Install/Use GDBM_File.pm
in thread Can't Install/Use GDBM_File.pm

I've overcome the problem -- solved would be too strong a word -- but it was quite a hack getting there. Disregarding the blind alleys and dead ends, this is what I did on two different systems (system details below):

Went to a GNU mirror and downloaded a tarball of the latest version of gdbm.

Unpacked that tarball, changed into the gdbm-1.8.3 directory, called ./configure and then make.

Unfortunately, the Makefile so created is defective. On both systems on which I tried this, the Makefile contained this code:

# File ownership and group BINOWN = bin BINGRP = bin

This created problems when I later called make install. The install failed at these lines in the Makefile:

install: libgdbm.la gdbm.h gdbm.info $(srcdir)/mkinstalldirs $(INSTALL_ROOT)$(libdir) \ $(INSTALL_ROOT)$(includedir) $(INSTALL_ROOT)$(man3dir) \ $(INSTALL_ROOT)$(infodir) $(LIBTOOL) $(INSTALL) -c libgdbm.la $(INSTALL_ROOT)$(libdir)/libgd +bm.la $(INSTALL_DATA) -o $(BINOWN) -g $(BINGRP) gdbm.h \ $(INSTALL_ROOT)$(includedir)/gdbm.h $(INSTALL_DATA) -o $(BINOWN) -g $(BINGRP) $(srcdir)/gdbm.3 \ $(INSTALL_ROOT)$(man3dir)/gdbm.3 $(INSTALL_DATA) -o $(BINOWN) -g $(BINGRP) $(srcdir)/gdbm.info \ $(INSTALL_ROOT)$(infodir)/gdbm.info

... which, when the variables were interpolated, came out as:

/usr/bin/install -c -m 644 -o bin -g bin gdbm.h \ /usr/local/include/gdbm.h install: bin: Invalid argument make: *** [install] Error 67

Since bin was nonexistent as either an owner or group-member, the install failed. I hacked around this by manually editing the Makefile to assign myself to the two variables:

BINOWN = jimk BINGRP = jimk

make install then succeeded.

But there's more!

As I reported yesterday, GDBM_File.pm was neither built nor tested when I installed Perl -- even though a test file for this module exists in the perl 5.8.8 distribution! Instead, once Perl was installed, I took up Fletch's suggestion, changed to the ext/GDBM_File directory under .cpan/build/perl-5.8.8, and tried to build GDBM_File from the Makefile.PLfound therein.

perl Makefile.PL make

So far, so good!

[GDBM_File] 554 $ make test PERL_DL_NONLAZY=1 ../../perl "-MExtUtils::Command::MM" "-e" "test_harn +ess(0, 'blib/lib', 'blib/arch')" t/*.t t/gdbm....Can't locate Config.pm in @INC (@INC contains: ../lib) at t/ +gdbm.t line 8. BEGIN failed--compilation aborted at t/gdbm.t line 13. t/gdbm....dubious + Test returned status 2 (wstat 512, 0x200) FAILED--1 test script could be run, alas--no output ever seen make: *** [test_dynamic] Error 2

Oops! To cut to the quick, t/gdbm.t has a hard-coded assignment to @INC:

BEGIN { chdir 't' if -d 't'; @INC = '../lib'; require Config; import Config; if ($Config{'extensions'} !~ /\bGDBM_File\b/) { print "1..0 # Skip: GDBM_File was not built\n"; exit 0;

But when I worked around this by providing a successful value for @INC, I got this:

[GDBM_File] 574 $ prove -v t/gdbm.t t/gdbm....1..0 # Skip: GDBM_File was not built skipped all skipped: GDBM_File was not built All tests successful, 1 test skipped. Files=1, Tests=0, 0 wallclock secs ( 0.01 cusr + 0.02 csys = 0.03 C +PU)

I was ready to throw in the towel, but I figured, "What the hell!", and called:

[GDBM_File] 575 $ sudo make install Installing /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level/auto/GDB +M_File/GDBM_File.bs Installing /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level/auto/GDB +M_File/GDBM_File.bundle Files found in blib/arch: installing files in blib/lib into architectu +re dependent library tree Installing /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level/GDBM_Fil +e.pm Writing /usr/local/lib/perl5/site_perl/5.8.8/darwin-2level/auto/GDBM_F +ile/.packlist Appending installation info to /usr/local/lib/perl5/5.8.8/darwin-2leve +l/perllocal.pod

... leading at long last to:

[gdbm-1.8.3] 504 $ perl -MGDBM_File -e 'print "Hello world\n";' Hello world

Now, is there anyone who can tell me why this process should have been so difficult? Setting aside the problem with GNU gdbm -- for which the Perl community is not responsible -- why is GDBM_File (and its C components) included in the Perl source distribution if it's not going to be installed in a typical installation?

And this is not a problem with the OSes! Last night, in order to get a headstart on solving this problem at work today, I spent two hours trying to get GDBM_File installed on my Mac OS X 10.4 system at home. I decided to take the opportunity to upgrade from 5.8.7 to 5.8.8 and installed, in the default configuration, from source, as I have done several times previously. I again noted that, during make test, t/gdbm.t was passed over.

ext/File/Glob/t/basic.....................ok ext/File/Glob/t/case......................ok ext/File/Glob/t/global....................ok ext/File/Glob/t/taint.....................ok ext/Filter/t/call.........................ok ext/I18N/Langinfo/t/Langinfo..............ok ext/IO/t/io_const.........................ok

And, once again, when Perl was done installing, GDBM_File was not working. Eventually I stumbled on the hack described above. Then I came to work this morning, booted my Ubuntu Linux box, and solved the problem on that box in exactly the same way as on my Mac!

Why? Why? Why?

Jim Keenan

Replies are listed 'Best First'.
Re^6: Can't Install/Use GDBM_File.pm
by Fletch (Bishop) on Sep 15, 2006 at 01:03 UTC

    There's no requirement that the headers and other components necessary for compiling code against the GDBM library be installed after the compilation is done. Once it's been compiled all that needs to be present to run is the shared library containing the compiled GDBM routines.

    The problem you encountered is more due to the Linux distributions splitting libraries like this into two components (e.g. gdbm and gdbm-devel). If you'd installed the complete GDBM distribution from source it would have worked find (and it did, once you got around the bizarre lack of a bin user and group and installed the headers; really you probably could have just copied the headers to /usr/local/include and you'd have been good). A typical "developer" install of something like Fedora would have had both packaged components to begin with and likewise GDBM_FIle would have compiled fine.

    As for the OS X case, I don't see libgdbm installed on my box in any form. If you had part of it the only thing I can think of is that you again installed just the runtime shared libraries using something like Darwin Ports or Fink. But similarly, OS X isn't really a full *NIX development environment out of the box without user intervention (in the form of Darwin Ports or Fink).

      Fletch wrote:
      As for the OS X case, I don't see libgdbm installed on my box in any form. If you had part of it the only thing I can think of is that you again installed just the runtime shared libraries using something like Darwin Ports or Fink.

      And, indeed, that is what I did first, i.e., immediately prior to doing the Perl upgrade to 5.8.8. But my last post was so long that I decided to omit some of the "blind alleys," of which this was one.

      Jim Keenan