Bug 185406

Summary: h2ph problem with gcc internal defines
Product: Red Hat Enterprise Linux 4 Reporter: Jason Vas Dias <jvdias>
Component: perlAssignee: Jason Vas Dias <jvdias>
Status: CLOSED ERRATA QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: perl-devel, prockai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: RHBA-2006-0426 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-18 13:30:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 178343    
Bug Blocks: 187538, 189833    

Description Jason Vas Dias 2006-03-14 15:05:01 UTC
+++ This bug was initially created as a clone of Bug #178343 +++

Description of problem:

>  Subject: h2ph problem
>  From:    George Michaelson <ggm@apnic.net>
>    To:    jvdias@redhat.com
>    Date:  2006-01-17 19:54
>  We just got bitten by 32bit vs 64bit logic in the .ph files generated
>  from socket.h/stddef.h/limits.h -bits/socket.ph to be exact.
>  Undefined subroutine &main::__LONG_MAX__ called at (eval 436) line 1.
>  Compilation failed in require at
> /usr/lib/perl5/5.8.5/i386-linux-thread-multi/sy s/socket.ph line 11.
>  Compilation failed in require at
> /usr/lib/perl5/site_perl/5.8.5/i386-linux-threa d-multi/netinet/in.ph line
> 9.
>  By removing some if/then/else logic, to make it just eval() the 32-bit
>  case, the problem went away.
>  this was after applying an up2date on EL4 for perl 5.8.5:
>  [ggm@curry log]$ uname -a
>  Linux curry.apnic.net 2.6.9-22.0.1.ELsmp #1 SMP Tue Oct 18 18:39:27 EDT
> 2005 i686 i686 i386 GNU/Linux [ggm@curry log]$ rpmquery -a | grep perl
>  newt-perl-1.08-7
>  mod_perl-1.99_16-4
>  perl-Net-DNS-0.48-1
>  perl-Time-HiRes-1.55-3
>  perl-5.8.5-24.RHEL4
>  perl-Filter-1.30-6
>  perl-URI-1.30-4
>  perl-Digest-SHA1-2.07-5
>  perl-Digest-HMAC-1.01-13
>  [ggm@curry log]$
>  the RPM errata lists
>  > * Tue Nov 01 2005 Jason Vas Dias <jvdias@redhat.com> - 3:5.8.5-17.RHEL4
>  >   - fix bug 170088: broken h2ph fixed with h2ph from 5.8.7
>  >   - fix bug 171111 / upstream bug 37535: IOCPARM_LEN should be _IOC_SIZE
>  >   - fix bug 172236: make h2ph pick up gcc built-in include directory
>  Is it possible you haven't tested enough of the outcomes here? Without
>  this, the perl just doesn't work.
>  -George
>  --- socket.ph.dist      2006-01-17 16:44:41.000000000 +1000
>  +++ socket.ph   2006-01-17 16:44:49.000000000 +1000
>  @@ -90,11 +90,7 @@
>       eval 'sub SOL_IRDA () {266;}' unless defined(&SOL_IRDA);
>       eval 'sub SOMAXCONN () {128;}' unless defined(&SOMAXCONN);
>       require 'bits/sockaddr.ph';
>  -    if((defined(&ULONG_MAX) ? &ULONG_MAX : 0) > 0xffffffff) {
>  -       eval 'sub __ss_aligntype () { &__uint64_t;}' unless
> defined(&__ss_aligntype); -    } else {
>          eval 'sub __ss_aligntype () { &__uint32_t;}' unless
> defined(&__ss_aligntype); -    }
>       eval 'sub _SS_SIZE () {128;}' unless defined(&_SS_SIZE);
>       eval 'sub _SS_PADSIZE () {( &_SS_SIZE - (2* $sizeof{
> &__ss_aligntype}));}' unless defined(&_SS_PADSIZE); eval("sub MSG_OOB () {
> 0x01; }") unless defined(&MSG_OOB);

Version-Release number of selected component (if applicable):
ALL - including RHEL-4 perl-5.8.5-*
not a problem with RHEL-3 perl-5.8.0, because gcc-3.2.3's limits.h #defines
things like __LONG_MAX__

How reproducible:

Steps to Reproduce:
$ perl -e 'require "sys/socket.ph";'
Actual results:
Undefined subroutine &main::__LONG_MAX__ called at (eval 256) line 1.
Compilation failed in require at
/usr/lib/perl5/5.8.6/i386-linux-thread-multi/sys/socket.ph line 11.
Compilation failed in require at -e line 1.

Expected results:
no errors

-- Additional comment from jvdias@redhat.com on 2006-01-19 12:20 EST --
Now that h2ph correctly picks up the gcc C standard includes, such as limits.h,
from the gcc internal include directory (ie. /usr/lib/gcc/*.../include),
which it was not doing before, due to bug 172236, some perl .ph files cannot be
included because they refer to the newer gcc versions 'internal definitions' such
as __INT_MAX__ / __LONG_MAX__ , which are no longer #define'd in any header file,
but are 'built-in' to the newer gcc compilers, in the same way as __FILE__ or
__LINE__ :

  $ echo 'int main(int argc, char **argv, char **envp)
          { long l=__LONG_MAX__; printf( "%ld\n",l); };' >tlm.c
( NOTE: no files are #include-ed )
  $ gcc -o tlm tlm.c$ gcc -o tlm tlm.c
  tlm.c: In function âmainâ:
  tlm.c:1: warning: incompatible implicit declaration of built-in function  âprintfâ
  $ ./tlm

gcc's C standard headers define constants such as LONG_MAX / INT_MAX in terms
of these internal definitions:

$ egrep 'define\ (INT|LONG)_MAX' limits.h
#define INT_MAX __INT_MAX__
#define LONG_MAX __LONG_MAX__

During the generation of the perl platform h2ph includes, we should create a 
file included by limits.ph that includes definitions for all the gcc 
'internal definitions' such as __LONG_MAX__ that might be referenced .

-- Additional comment from jvdias@redhat.com on 2006-01-19 12:57 EST --
Created an attachment (id=123451)
Program to produce perl header for C built-in definitions

Something like the output of this program needs to be prepended to limits.ph
during the build of the perl h2ph platform headers .

-- Additional comment from rc040203@freenet.de on 2006-01-19 13:15 EST --
I must be missing something, but why do you try to extract GCC proprietary,

#include <limits.h> and printing the corresponding POSIX defines would be portable.

C.f. http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html

-- Additional comment from jvdias@redhat.com on 2006-01-19 15:54 EST --
RE: Comment #3:
   /usr/include/limits.h just #includes' gcc's limits.h, unless  '__GNUC__ < 2',
   and gcc's limits.h would in any case be found first in by a 
   '#include <limits.h>' .

The whole issue of h2ph and perl's platform includes needs a major revamp, which
it will get once perl-5.8.8 comes out (soon, I hope).

-- Additional comment from jvdias@redhat.com on 2006-01-31 13:07 EST --
OK, it wasn't fixed in 5.8.8. I've now raised upstream perl bug 
#38385 : http://rt.perl.org/rt3/Ticket/Display.html?id=38385
on this issue, which includes a patch to fix it.

This will be fixed in the next perl releases for RHEL-4, FC-4, and FC-5 
(RHEL-3 is unaffected).

-- Additional comment from jvdias@redhat.com on 2006-02-02 18:15 EST --
Created an attachment (id=124075)
Program to include cpp internal built-in macros in system _h2ph_pre.ph

-- Additional comment from jvdias@redhat.com on 2006-02-02 18:21 EST --
This problem is fixed with perl-5.8.8-1 in FC-5, with the patch sent upstream,
which checks for the existence of cpp internal built-ins in Configure, and 
writes them to $Config{cppsymbols} so they are correctly written to _h2ph_pre.pl.

This patch will be applied to subsequent perl releases for FC-4 and RHEL-4 ,
but this problem probably does not warrant a complete perl respin just to fix it.

Meanwhile, simply run the 'patch_h2ph_pre.pl' script attached above, as root,
and the system _h2ph_pre.ph (which gets included by every perl header file) will
be patched to define cpp built-ins it does not already define .

-- Additional comment from updates@fedora.redhat.com on 2006-03-13 17:12 EST --
From User-Agent: XML-RPC

perl-5.8.6-24 has been pushed for FC4, which should resolve this issue.  If
these problems are still present in this version, then please make note of it in
this bug report.

Comment 1 Jason Vas Dias 2006-03-14 15:08:31 UTC
Fixed with perl-5.8.5-26.RHEL4, available for download and testing from:

Comment 6 Red Hat Bugzilla 2006-05-18 13:30:22 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.