perl, gdbm and perl's obsequious help

Neal Murphy neal.p.murphy at alum.wpi.edu
Thu Jun 3 08:33:12 PDT 2010


On Thursday 03 June 2010 04:08:33 Simon Geard wrote:
> On Thu, 2010-06-03 at 02:39 -0400, Neal Murphy wrote:
> > On Thursday 03 June 2010 00:30:58 Chris Staub wrote:
> > > I just built Perl in Chapter 5, and I do have gdbm installed (this is
> > > on a couple-week-old LFS svn host system). I get "<gdbm.h> NOT found."
> > > during Configure, and it doesn't look like anything in Perl tries to
> > > link to libgdbm.
> >
> > Dig deep. Perl's configure, trying to be ever-so-helpful, finds it
> > (libgdbm.*) on the host (your LFS SVN host) and configures support for
> > the package.
>
> Curious... like Chris, I routinely build LFS from a host with gdbm
> installed (i.e LFS itself), and never observed any problems relating to
> perl. Indeed, even on completed LFS install, /usr/bin/perl isn't linked
> against gdbm, and runs fine if I remove the libgdbm libraries.
>
> Can you be more specific about the problems you're seeing? Does the perl
> executable fail to run at all, unable to link to libgdbm.so? Or is it
> something less obvious?
>
> Simon.

I built on Debian Lenny. Perl's configure examines the host system looking for 
useful features. In my case, libgdbm was installed on Lenny; perl found it 
and configured support for it. Later in the the build, perl failed to run 
because it couldn't find libgdbm.so. This was obvious. What wasn't obvious 
was, "Why?"

Perl wouldn't run and my build failed. As I said in another post, "Dere I was, 
mindtin' my own bidness, when all of a sudden, I was lost at sea." Instad of 
panicking, I retraced my steps to determine how I got there. That retracement 
led me to perl and its obsequious assistance.

That's when I dug into perl's configure script and eventually discovered that 
LFS' standard two config options are not enough to adequately shield the 
toolchain build from the host system. Given the scant documentation, you'd 
think '-Dstatic_ext='Data/Dumper Fcntl IO POSIX' would be enough. It isn't. 
You also have to tell it to build ONLY those extensions, to look ONLY 
in /tools/lib for libraries, and to look ONLY in /tools/include for headers. 
(Alas, a year later, I don't remember why the inc_version_list is necessary.)

If you don't add these four options, perl's configure will spelunk through the 
HOST's tree looking for features it should support. This behaviour is EXACTLY 
what most people want when they build and install perl on their running 
system. Alas, it is exactly what you do NOT want when building a bootstrap 
toolchain.

If I may be so crass, that you haven't stumbled on this may be due purely to 
dumb luck. There are probably subtle differences between LFS' build steps and 
the steps I follow in my project. As my project was originally based on LFS 
(many years ago), I thought it only fair that I share what I found about this 
particular problem; mayhap I could save someone a lot of time. If nothing 
else, some day y'all'll trip on it and the solution'll be here in the 
archives, waiting to be discovered again.



More information about the lfs-support mailing list