Opened 16 years ago

Closed 16 years ago

#201 closed task (fixed)

Perl plobrems and fixes

Reported by: willimmn Owned by: clfs-commits@…
Priority: major Milestone: CLFS Standard 1.2.0
Component: BOOK Version: CLFS Standard GIT
Keywords: Cc:

Description

  1. -DVendorPrefix is not set. Some packages (like Dpkg) use it to put it's perl modules. The fix, use this configure command:
sh Configure -des -Dprefix=/usr \
                  -Dvendorprefix=/usr           \
                  -Dman1dir=/usr/share/man/man1 \
                  -Dman3dir=/usr/share/man/man3 \
                  -Dpager="/usr/bin/less -isR" \
                  -Dusethreads -Duseshrplib
                  (other commands go here)
  1. LFS is using a patch for Perl 5.10.0, it includes the libc fix and lots of security fixes, it is attached with this ticket.
  1. Compress::Raw::Zlib uses it's own copy of Zlib, it may be older than the one of the system (1.2.3), so use these seds to force it to use system Zlib: {{{

sed -i -e "s|BUILD_ZLIB\s*= True|BUILD_ZLIB = False|" \

-e "s|INCLUDE\s*= ./zlib-src|INCLUDE = /usr/include|" \ -e "s|LIB\s*= ./zlib-src|LIB = /usr/lib|" \

ext/Compress/Raw/Zlib/config.in

}}}

Attachments (1)

perl-5.10.0-consolidated-1.patch (7.0 KB ) - added by willimmn 16 years ago.
Perl fixes, includes the libc one and a critical security fix.

Download all attachments as: .zip

Change History (11)

by willimmn, 16 years ago

Perl fixes, includes the libc one and a critical security fix.

comment:1 by Jim Gifford, 16 years ago

Just because LFS has something doesn't mean CLFS will follow that same direction. As far as using the internal Zlib, the version included with Perl is the same as the book. Why should we change it, there is not technical merit to making the change.

As far as the patch, I've been working on a branch_update for perl. It will be added very soon.

The vendor switch, can you provide more details on why we should add it.

in reply to:  1 comment:2 by ken, 16 years ago

Replying to jim:

Just because LFS has something doesn't mean CLFS will follow that same direction. As far as using the internal Zlib, the version included with Perl is the same as the book. Why should we change it, there is not technical merit to making the change.

For the zlib question, it's a question of how secure you expect your system to be, and how you intend to fix known vulnerabilities. If there is another vulnerability found in zlib, first you have to find what used the system's static version (by grepping in your build logs) - e.g. module-init-tools, but if you allow packages to use their own versions of common libs it all gets a little bit harder.

FWIW, I had adding the patch to CLFS on my To Do list.

comment:3 by Jim Gifford, 16 years ago

Added -Dvendorprefix=/usr in r4515.

As far as the Zlib, we should check the configure switches to see if we can use the system instead of a hack if possible.

The lfs consolidated patch will not be added. Joe and myself looked at the patch, and looked at the perl branch, there are a lot of patches in there. If you download the branch and diff it, it's about 15mb. I think that's overkill for what we are doing.

in reply to:  3 comment:4 by chris@…, 16 years ago

Replying to jim:

As far as the Zlib, we should check the configure switches to see if we can use the system instead of a hack if possible.

I tried "make BUILD_ZLIB=False" as done in DIY-Linux, but that doesn't seem to work. During the build I get output like this:

cc -c  -I./zlib-src -fno-strict-aliasing -pipe
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2  
-DVERSION=\"2.008\" -DXS_VERSION=\"2.008\" -fPIC "-I../../../.." 
-DGZIP_OS_CODE=3  Zlib.c

Apparently it's still using its own internal Zlib source, so the sed, altering all the applicable variables, is needed for it to actually use the system-installed zlib. The sed command could at least be shortened though...

sed -i -e '/^BUILD_ZLIB/ s/True/False/' \
  -e '/^INCLUDE\|^LIB/ s|\./zlib-src|/usr/include|' \
  ext/Compress/Raw/Zlib/config.in

comment:5 by Gesp, 16 years ago

"make BUILD_ZLIB=False" work but you have to build the first perl stage without the lib search patch. I loose some time on this. Just follow DYI for the two perl stages, and not only for the second stage.

comment:6 by willimmn, 16 years ago

The recent command STILL DID NOT FIX IT. YOU CAN'T SPECEFY -Dvendorprefix FROM ./configure.gnu. YOU NEED TO REPLACE THE FIRST LINE WITH

sh Configure -des -Dprefix=/usr \

THEN WE CAN PUT THIS TO BED.

comment:7 by Jim Gifford, 16 years ago

Works fine here, please provide your data.

in reply to:  6 comment:8 by chris@…, 16 years ago

Replying to willimmn:

The recent command STILL DID NOT FIX IT. YOU CAN'T SPECEFY -Dvendorprefix FROM ./configure.gnu. YOU NEED TO REPLACE THE FIRST LINE WITH

sh Configure -des -Dprefix=/usr \

I tried the command

perl -MConfig -e 'print $Config{vendorlib}'

given at the top of this ticket - http://wiki.linuxfromscratch.org/lfs/ticket/2071 - and it is indeed blank. Then I added -Dvendorprefix to the list of configure.gnu options, and tried that command again and got

/usr/lib/perl5/vendor_perl/5.10.0

Isn't this what you're supposed to get from that command?

THEN WE CAN PUT THIS TO BED.

Using ALL CAPS does not make you more right.

comment:9 by Jim Gifford, 16 years ago

willimmn from now on for your tickets please provide details. Not because LFS said so. I want to see technical merit. This team will not accept anymore tickets from you unless there is some technical merit. We are not LFS and we don't have the same goals as LFS.

Team, after this ticket is closed, if there is not technical merit from this user, close the ticket as invalid.

comment:10 by Jim Gifford, 16 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.