Bug 156113 - (debugperl) Perl is built with debugging support
Perl is built with debugging support
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
12
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
David Lawrence
: Reopened, Triaged
Depends On:
Blocks: FC5Blocker 514942
  Show dependency treegraph
 
Reported: 2005-04-27 12:53 EDT by Jan "Yenya" Kasprzak
Modified: 2010-03-02 11:51 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-02 11:51:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
kasal: fedora_requires_release_note-


Attachments (Terms of Use)
Disable -DDEBUGGING (384 bytes, patch)
2005-04-27 15:30 EDT, Ville Skyttä
no flags Details | Diff

  None (edit)
Description Jan "Yenya" Kasprzak 2005-04-27 12:53:08 EDT
Description of problem:
The Fedora version of Perl is build with debugging support (see perl -V |grep
DEBUGGING). This causes 25-40% slowdown for my application (mod_perl based) when
compared to running the same version of Perl without DEBUGGING.

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

Steps to Reproduce:
1. perl -V | grep DEBUGGING

  
Actual results:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
  Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS USE_64_BIT_INT
USE_64_BIT_ALL USE_LARGE_FILES PERL_IMPLICIT_CONTEXT


Expected results:
the same without -DDEBUGGING in cppflags and without DEBUGGING in Compile-time
options.

Additional info:
This is probably because the default $RPM_OPT_FLAGS contain the "-g" switch, and
Perl's ./Configure reads the "-g" in CFLAGS as an order to build the debugging
version of Perl. The following change to perl.spec should help:

- sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \
+ sh Configure -des -Doptimize="`echo $RPM_OPT_FLAGS | sed 's/-g //'`" \
Comment 1 Ville Skyttä 2005-04-27 15:30:41 EDT
Created attachment 113734 [details]
Disable -DDEBUGGING

According to docs, the extra -DDEBUGGING is indeed probably most useful for
folks hacking on Perl's internals.  However, -g is standard for all packages in
FC, so here's another approach that preserves it, but avoids addition of
-DDEBUGGING.  If I understand correctly, this would preserve most of the
ability to debug Perl (with the -debuginfo package) and possible core dumps
from it, but eliminate the performance overhead.

I took a brief look at how this is handled in a few other distros' packages:
- Debian builds a completely separate perl-debug package.
- SuSE doesn't seem to have anything related in their specfile.
- Mandriva has some implementation for flagging a debug/not debug build in
  their specfile (default: no debug) but they fail to take into account that
  if $RPM_OPT_FLAGS contains "-g", -DDEBUGGING is enabled by Configure, so I 
  guess they're failing to produce the intended results.

Call me conservative, but considering -DDEBUGGING has been (inadvertantly?) on
for quite a long time in FC perls, I tend to think this is something to look
into after FC4.  The effect on already compiled binary modules is not entirely
clear to me either, but it smells like this wouldn't cause any trouble.
Comment 2 Jan "Yenya" Kasprzak 2005-04-27 15:40:17 EDT
I have tried to upgrade perl to my patched binary without -DDEBUGGING, and
apparently my modules are still working (including binary ones such as Storable,
DBD::Oracle, Crypt::SHA1, etc.).
Comment 3 Warren Togami 2005-04-27 17:32:13 EDT
Let's test perl built this way and we'll consider this for FC4, but more likely
for FC5.
Comment 4 Ville Skyttä 2005-08-14 05:20:48 EDT
Warren, while you're rolling the Rawhide Perl updates, could you slip this one 
in (patch in comment 1) so more people could start testing? 
Comment 5 Stepan Kasal 2009-07-31 12:01:28 EDT
This bug bites again!  It seems it causes bug #514942, complicating the review bug #512726.

The patch got lost during the update to 5.10.0.

Fortunately, with 5.10.0, no patch is needed, configure option -DDEBUGGING=-g does the trick.

I guess that the Release notes should mention that unlike in Fedora 9--11, perl in Fedora 12 is compiled without -DDEBUGGING again.
Comment 6 Stepan Kasal 2009-08-05 10:39:33 EDT
(In reply to comment #5)
> I guess that the Release notes should mention that unlike in Fedora 9--11, perl
> in Fedora 12 is compiled without -DDEBUGGING again.  

No, the fix will probably come with perl 5.10.1 in F-13.
I'm afraid we won't have a production build of perl in F-12.  After all, no one noticed for three releases of Fedora...
Comment 7 Chris Weyl 2009-08-28 03:32:28 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > I guess that the Release notes should mention that unlike in Fedora 9--11, perl
> > in Fedora 12 is compiled without -DDEBUGGING again.  
> 
> No, the fix will probably come with perl 5.10.1 in F-13.
> I'm afraid we won't have a production build of perl in F-12.  After all, no one
> noticed for three releases of Fedora...  

Either that, or rebuild all the arch-specific perl-* packages out there after making this change.  That wouldn't be too complex (create a tag; loop, bump & build to the tag; merge back to dist-f12); but it would be a lot of churn for the middle of a beta cycle.  (Not that far more complicated changes haven't been introduced around this point before...)
Comment 8 Stepan Kasal 2009-08-28 13:59:20 EDT
(In reply to comment #7)
> That wouldn't be too complex (create a tag; [...]

This was also my first impression when I discovered this problem.

Fortunately, I do not have the rights to create a tag; I had to apply for it.
A discussion followed, I had to advocate that I really need the tag; as time passed, I began to see more consequences and decided that this change is not as easy as it seems to be.

First, I want to have dependencies right.  My own system is randomly updated rawhide: at random times, I do "yum update some-packages" and I suppose that the dependencies are there mo ensure that everything works.

Currently, Fedora has debug perl and debug modules, i.e., all were compiled with -DDEBUGGING.  We would like to get have production perl and production modules.
But debug modules do not work with production perl.  The dependencies should reflect this.  So the current debug modules have to require something that will not be provided by the production perl.

What could that be?

I cannot invent anything better than perl(:MODULE_COMPAT_5.10.0)
So our final production perl may not provide that; it will provide perl(:MODULE_COMPAT_5.10.1) instead.

But at beginning of August, when I consideres this move, there was still no  5.10.1 release candidate available.  Top be able to do this, I would have to start by creating a snapshot labeled 5.10.1rc0 or some such.
(The following week the alpha was postponed.  But I afraid they didn't mean it as an opprtunity to start something that might then cause anither slip.)

This was the main reason why I decide to leave fixing this bug for early dist-f13.

But there were also two supportive reasons:

Reason 1:
I wanted to do exactly what Chris said:
> create a tag; loop, bump & build to the tag; merge back to dist-f12
But that building to the tag is actually bootstrapping; you have to respect the BuildRequires and Requires.  In theory, that should be easy.
But we are not a source distribution, you cannot just "make world", so this is something which is not tested yet, so something is bound to break.
And, indeed, Tom spot Callaway witnessed from his work on packaging 5.10.0 that such a bootstrap is a real PITA.

Reason 2:
Moreover, this is not the only change bound to the version number increase.
The other one was advertised here:
http://article.gmane.org/gmane.linux.redhat.fedora.perl/9664

> [...] but it would be a lot of churn for the middle of a beta cycle.

Another consequence of asking for the tag was that they adverted me from my idea to slip in during the beta period.  The risks are not worth the gain.

I hope this all explains why we will (almost surely) stay with debug perl for Fedora 12.

This comment does not discuss whether the change should be done using a separate tag or not.  But that's an implementation issue that can be discussed on the fedora-perl-devel-list.

[the "patch" keyword is no longer relevant]
Comment 9 Bug Zapper 2009-11-16 02:49:42 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Nicolas Chauvet (kwizart) 2009-11-17 17:10:29 EST
(In reply to comment #6)
> (In reply to comment #5)
> > I guess that the Release notes should mention that unlike in Fedora 9--11, perl
> > in Fedora 12 is compiled without -DDEBUGGING again.  
> 
> No, the fix will probably come with perl 5.10.1 in F-13.
Is this still planned for F-13? When should this rebuild start?
Comment 11 Marcela Mašláňová 2010-03-02 11:51:12 EST
I believe we are since F-13 without debug. The configure is using macro DDEBUGGING=-g which should be the correct way (comment #5).

In case it still doesn't work, please reopen.

Note You need to log in before you can comment on or make changes to this bug.