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. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
