Description of problem:

Perl .ph files are pretty broken on rhel8.  Almost any attempt to use them produces a confusing warning about _FORTIFY_SOURCE and compiling with optimization (even when nothing is being compiled).


Version-Release number of selected component (if applicable):


How reproducible:

Package - perl-5.32.1-471.module+el8.6.0+13324+628a2397.x86_64.rpm


Steps to Reproduce:


rhel8test04.nyc|psc:~[13:53](2093) $ perl -e 'require "features.ph"'
_FORTIFY_SOURCE requires compiling with optimization (-O) at /usr/lib64/perl5/features.ph line 207.

Another reproducer:

rhel8test04.nyc|psc:~[13:55](2095) $ perl -e 'require "sys/ioctl.ph"'
_FORTIFY_SOURCE requires compiling with optimization (-O) at /usr/lib64/perl5/features.ph line 207.


Actual results:

The normal usecase where we encountered this was ...


require "sys/ioctl.ph"; # for TIOCGWINSZ
Lots of .ph files require features.ph, and they are all affected similarly.  Another example is sys/socket.ph.
.ph files are intended to obtain constants (like TIOCGWINSZ) that are defined in C .h headers. So, we think this is a normal usecase.



Additional info:


Perl .ph files are automatic, mechanical translations of C .h files, and are intended to provide access to C constants in Perl code.  The fortify.h header includes a test to ensure that -O is used when compiling with _FORTIFY_SOURCE, and the header looks for OPTIMIZE, which is set by the compiler whenever -O is used.  Perl translates this test to the .ph file, but nothing ever sets OPTIMIZE  when Perl runs, because nothing is being compiled!  This causes a warning for anything that uses features.ph.  


As a hacky workaround, we could patch anything that uses an affected .ph module to set OPTIMIZE. But that could be a good number of scripts.