Opened 16 years ago
Closed 16 years ago
#201 closed task (fixed)
Perl plobrems and fixes
Reported by: | willimmn | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | CLFS Standard 1.2.0 |
Component: | BOOK | Version: | CLFS Standard GIT |
Keywords: | Cc: |
Description
- -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)
- 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.
- 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)
Change History (11)
by , 16 years ago
Attachment: | perl-5.10.0-consolidated-1.patch added |
---|
follow-up: 2 comment:1 by , 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.
comment:2 by , 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.
follow-up: 4 comment:3 by , 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.
comment:4 by , 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 , 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.
follow-up: 8 comment:6 by , 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:8 by , 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 , 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 , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Perl fixes, includes the libc one and a critical security fix.