Bug 17935

Summary: Perl in RELENG_3 uses a config file from 4-current.
Product: Base System Reporter: Library Book Extensions <libagent>
Component: gnuAssignee: Mark Murray <markm>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.4-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
diff.out none

Description Library Book Extensions 2000-04-11 17:50:01 UTC
Perl on RELENG_3, after the MFC of 
$Id: config.SH-elf.i386,v 1.11 1999/05/02 15:29:42 markm Exp $
(in directory src/gnu/usr.bin/perl/libperl) uses a bogus config. Perl
believes it was built on a 4-current machine, using egcs, and not on a 3.x
machine using gcc 2.7.2.x, even if one rebuilds it from source (by doing
'make' in src/gnu/usr.bin/perl/). I'm not sure what the exact implications
are, but I suspect it affects dynamically loaded modules compiled with the
native 3.x compiler.

Fix: 

Probably generate a new config file. Depending on the implications (which
I'm not yet sure of) an entry in ERRATA.TXT may be in order. I don't really
know what to feed perl's Configure with to get the correct config file.
sorry.
How-To-Repeat: 
Just check the output of perl -V on a 3.x system built after 1999/05/02
15:29:42.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-04-12 10:50:41 UTC
Responsible Changed
From-To: freebsd-bugs->markm

Mark was the author of rev 1.10.2.1 and will know what to do. :-) 

Comment 2 k.stevenson 2000-04-12 15:24:50 UTC
The following patch against
/usr/src/gnu/usr.bin/perl/libperl/config.SH-elf.i386 is probably a step in the
right direction.  I really don't think that the bogus information hurts
anything though.  I just makes debugging a bit more confusing.

Regards,
--Keith Stevenson--

-- 
Keith Stevenson
System Programmer - Data Center Services - University of Louisville
k.stevenson@louisville.edu
PGP key fingerprint =  4B 29 A8 95 A8 82 EA A2  29 CE 68 DE FC EE B6 A0
Comment 3 Mark Murray freebsd_committer freebsd_triage 2000-05-01 19:34:08 UTC
State Changed
From-To: open->closed

This is a comments-only problem. It has absolutely no implication for 
any modules (the ports system would be in chaos if it did). 
I will try to keep this more accurate in future versions. 

Thanks for the heads-up! :-)