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