perl, gdbm and perl's obsequious help

Chris Staub chris at
Wed Jun 2 21:30:58 PDT 2010

On 06/02/2010 05:22 PM, Neal Murphy wrote:
> Some time back (LFS 6.4), I discovered that perl's configure program can
> poison the build; it is designed to be extremely helpful by ferreting out
> features of the host system to support. Specifically in my case, because it
> found libgdbm on the host system, it configured perl to include support for
> gdbm; this causes the build to fail later because perl can't find libgdbm.
> Alas, such obsequiousness hoses the LFS build process.
> The standard LFS configure options for perl do not prevent this from
> happening. For review, the options are:
>      -des -Dprefix=/tools -Dstatic_ext='Data/Dumper Fcntl IO POSIX'
> After days of gnashing teeth and rending garments (my hair is too short to
> pull out in tufts) and parsing perl's configure script, I developed the
> correct incantation:
>      -des -Dprefix=/tools -Dstatic_ext="Data/Dumper Fcntl IO POSIX" \
>      -Donlyextensions="Data/Dumper Fcntl IO POSIX" \
>      -Dglincpth="/tools/include" -Dglibpth="/tools/lib" \
>      -Dinc_version_list=none
> The four extra options are required _when building the toolchain_ to ensure
> absolutely that perl's configure
>    - configures those extensions and ONLY those extensions, and
>    - cannot examine the host for features to support
> These options should work regardless of what is installed on the host build
> system.

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.

More information about the lfs-support mailing list