perl, gdbm and perl's obsequious help
bruce.dubbs at gmail.com
Thu Jun 3 14:38:43 PDT 2010
Neal Murphy wrote:
> 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:
> 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.
Hmm. I wonder why the incorrect behavior doesn't show up for me. On my
current svn build, I do not have libgdbm in /tools, but I do have it in
the final /usr/lib. ldd on perl does shows:
# ldd perl
linux-vdso.so.1 => (0x00007fffb53ff000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00007f912c312000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f912c10e000)
libm.so.6 => /lib/libm.so.6 (0x00007f912be8c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f912bc55000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f912ba52000)
libc.so.6 => /lib/libc.so.6 (0x00007f912b6f6000)
The tools version gives me:
# ldd perl
linux-vdso.so.1 => (0x00007fffe93ff000)
libnsl.so.1 => /tools/lib/libnsl.so.1 (0x00007f342df99000)
libdl.so.2 => /tools/lib/libdl.so.2 (0x00007f342dd95000)
libm.so.6 => /tools/lib/libm.so.6 (0x00007f342db13000)
libcrypt.so.1 => /tools/lib/libcrypt.so.1 (0x00007f342d8dc000)
libutil.so.1 => /tools/lib/libutil.so.1 (0x00007f342d6d9000)
libc.so.6 => /tools/lib/libc.so.6 (0x00007f342d37d000)
libgcc_s.so.1 => /tools/lib/libgcc_s.so.1 (0x00007f342d168000)
I do have libgdm on the host system also.
I didn't do the research that is in the book's dependencies section, but
it says that perl is needed to build glibc. If it were a general
problem, I'd think we would have seen it a long time ago.
We may end up adding the extra switches in Chapter 5's perl build, but
I'm trying to understand why it's needed on your system and not others
before doing that. Figuring that out may be more work than anyone wants
> - 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.
That's the intent, yes.
> 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,
No, not really. We appreciate and thank you for your report.
More information about the lfs-support