Ticket #201 (closed task: fixed)

Opened 6 years ago

Last modified 6 years ago

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

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

Change History

Changed 6 years ago by willimmn

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

comment:1 follow-up: ↓ 2 Changed 6 years ago by 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.

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.

comment:2 in reply to: ↑ 1 Changed 6 years ago by ken

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 follow-up: ↓ 4 Changed 6 years ago by jim

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.

comment:4 in reply to: ↑ 3 Changed 6 years ago by chris@…

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 Changed 6 years ago by Gesp

"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 follow-up: ↓ 8 Changed 6 years ago by 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 \

THEN WE CAN PUT THIS TO BED.

comment:7 Changed 6 years ago by jim

Works fine here, please provide your data.

comment:8 in reply to: ↑ 6 Changed 6 years ago by chris@…

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 Changed 6 years ago by jim

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 Changed 6 years ago by jim

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.