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