> perl -V:make
make='make';
i have to assume that redhat's perl binary was built using the same version of make which they bundle in the distro, especially where most CPAN modules compile correctly.
i tried upgrading ExtUtils::MakeMaker, and afterwards the same modules still end up creating the same bogus Makefiles.
the more i look at it, the more it looks like it may be something wrong with how redhat built perl in the first place, and whatever it is causes a side effect for ExtUtils::MakeMaker for some modules.
the strange thing is that most modules generate perfect Makefiles, while others seem to "almost" get what they need from Config.pm but end up grabbing more or less text than they should, and in a few cases end up with totally wrong text. example (from the same Makefile we're talking about)
33 LDFLAGS = -L/usr/local/lib
34 LIBC = /lib/libc-2.3.1.so
35 LIB_EXT = .a'
36 libc='
37 OBJ_EXT = ub
38 OSNAME = linux
39 OSVERS = 2.4.20-2.48smp
40 RANLIB = _
notice line 35, whose "value" includes that single quote, a newline, and the text on the next line. the "value" came from the following chunk of Config.pm:
839 less='less'
840 lib_ext='.a'
841 libc='/lib/libc-2.3.1.so'
842 libperl='libperl.so'
it's like the code arbitrarily grabbed eight extra bytes. another example is just below it- line 37 of Makefile, "OBJ_EXT = ub" should say "OBJ_EXT = .o". it looks like it somehow came from the following chunk of Config.pm:
907 nvsize='8'
908 nvtype='double'
909 o_nonblock='O_NONBLOCK'
910 obj_ext='.o'
911 old_pthread_create_joinable=''
notice "ub" in the word "double" on line 908, which is two lines above what it should be reading (line 910.) it seems to have gotten the right NUMBER of bytes (two), but it missed by 36 bytes when grabbing the contents.
maybe it's a subtle bug in one of redhat's libraries?
for what it's worth, other configuration requests i've tried seem to show exactly what one would expect:
> perl -V:lib_ext
lib_ext='.a';
> perl -V:libc
libc='/lib/libc-2.3.1.so';
> perl -V:obj_ext
obj_ext='.o';
very strange. hopefully somebody will have seen this before and can offer an idea on how to fix it, or work around it. |