[Bug 185406] New: h2ph problem with gcc internal defines

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185406 Summary: h2ph problem with gcc internal defines Product: Red Hat Enterprise Linux Version: 4 Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl AssignedTo: jvdias(a)redhat.com ReportedBy: jvdias(a)redhat.com QAContact: dkl(a)redhat.com CC: fedora-perl-devel-list@redhat.com,prockai(a)redhat.com +++ This bug was initially created as a clone of Bug #178343 +++ Description of problem: 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: 100% 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(a)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 2147483647 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(a)redhat.com on 2006-01-19 12:57 EST -- Created an attachment (id=123451) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=123451&action=...) 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(a)freenet.de on 2006-01-19 13:15 EST -- I must be missing something, but why do you try to extract GCC proprietary, internals? #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(a)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(a)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(a)redhat.com on 2006-02-02 18:15 EST -- Created an attachment (id=124075) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124075&action=...) Program to include cpp internal built-in macros in system _h2ph_pre.ph -- Additional comment from jvdias(a)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(a)fedora.redhat.com on 2006-03-13 17:12 EST -- 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.