perl, gdbm and perl's obsequious help

Neal Murphy neal.p.murphy at alum.wpi.edu
Thu Jun 3 13:46:49 PDT 2010


On Thursday 03 June 2010 14:45:04 Chris Staub wrote:
> On 06/03/2010 11:33 AM, Neal Murphy wrote:
> > On Thursday 03 June 2010 04:08:33 Simon Geard wrote:
> >> 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?"
>
> Still not enough info. At what point did Perl try to run, and how
> exactly? Is it just when running "perl" at all? With certain specific
> options and/or using certain Perl modules?

IIRC, the problem became apparent when the toolchain perl tried to run in the chroot jail during the final build (Ch. 6 equivalent) before the final build of perl. It didn't matter what I did; toolchain perl always built with support for libgdbm and would fail because it couldn't find that lib in the chroot jail. It built in support for libgdbm because it found gdbm libs and headers on my Debian host. It found those things because the '-Dstatic_ext' option does not prevent it from doing so.

>
> > 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.
>
> And this may very well be the issue, since nobody has reported this
> problem when building LFS before. I'd say that for this report to have
> any validity, you'd need share exactly what these differences are, in
> particular how Perl is built in Chapter 5 (of course giving more than
> just "adding those 4 options to Configure"). Typically when some package
> tries to pull something from the host, it's because of a goof-up in
> Chapter 5.

  - This oddity has not been reported before (here or anywhere).
  - This is not a problem report or support request.
  - It's a report of something I encountered whilst using 6.4 as a
    guide to updating a project that was originally based on LFS.
  - To the best of my ability to determine, perl's configure script
    explicitly searches the host filesystem for features it should
    support, an action which _can_ poison the toolchain.
  - I know that the normal 'static_ext' parameter does not prevent
    perl's configure from searching the host for features to support.
  - I am very sure that the extra four configure options do prevent
    perl's configure from potentially poisoning the toolchain with
    references to the host ysstem.

According to Ch. 5, the intent is to have perl build only the four specified features, and build them statically into perl. As I understand, the '-Dstatic_ext=...' option that LFS uses tells perl only to build those features statically into perl. It doesn't restrain perl from building other extensions. It doesn't prevent perl's configure script from searching the host system. 

The real issue is that, as best as I can tell, perl's configure script searches the host's filesystems for features to support, which is not desired when building the toolchain. Why it does that to me when building on Debian Lenny and not to anyone else, I don't know. I do know that the extra parameters for perl's configure effectively limit it to searching ONLY the toolchain for features to support.

Perhaps I was remiss in not putting 'FYI' in the subject, for it was my intent to save the next guy a lot of time tracking down something that is only a problem when building a toolchain, something that involves unclearly documented options. I don't dispute that the LFS build works. I've tried to avoid denigrating anyone's efforts. I offered the arcane, obscure info not to trick people into spinning their wheels, but rather to help make LFS better, more correct, and more bullet-proof.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-support/attachments/20100603/b785f584/attachment.html>


More information about the lfs-support mailing list