Bug 41794 - Compiler switch
Summary: Compiler switch
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc   
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-05-22 06:01 UTC by Steve Snyder
Modified: 2007-04-18 16:33 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-02 19:24:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Steve Snyder 2001-05-22 06:01:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2smp i686; en-US; 0.7)

Description of problem:
Use of the "-fomit-frame-pointer" compiler switch when building the kdelib
package causes a few KDE applications to abort with an "internal error"
message at application startup.

How reproducible:

Steps to Reproduce:
[The following assumes a stock i686 RedHat v7.1 ("Seawolf") system. The
versions of the development tools used are those which shipped with that

1. Rebuild the KDE library SRPM, either the RH 7.1 distribution
"kdelibs-2.1.1-5.src.rpm" or the update "kdelibs-2.1.2-1.src.rpm", with
RPM_OPT_FLAGS="-march=i686 -O2".

2. Install the generated binary RPMs onto a RedHat v7.1 system which
includes a working KDE environment.

3. Run the KDE desktop, then launch the KDE online help (life-preserver
icon) and the Konqueror Web browser.  (The applications can be run either
sequentially or concurrently; it doesn't matter.)  Both run fine.  Exit the
KDE desktop.

4. Now rebuild that same SRPM with RPM_OPT_FLAGS="-march=i686 -O2

5. Install the generated RPMs onto that same RedHat v7.1 system,
overwriting the libraries from the previouly build.

6. Run the KDE desktop, then launch the KDE online help and the Konqueror
Web browser.  In both cases the application will not start.  Instead of the
given application, a message box is shown which says that the application
cannot run due to an internal error.  No debug symbols are available for
inspection.  Exit the KDE desktop.

7. Repeat steps #1 and #2 above, so that the installed libraries are again
built without the "-fomit-frame-pointer" compiler switch.

8. Run the KDE desktop again.  No errors are seen when attempting to run
either application.

Actual Results:  A few KDE application would not run.

Expected Results:  Application should have run normally.

Additional info:

1.  This is not a build conflict between different elements of KDE That is,
it is not a result of building some KDE RPMs with "-fomit-frame-pointer"
and some without.  I initially saw this problem after building all kde*.rpm
packages with "-march=i686 -O2 -fomit-frame-pointer".  Having seen these
failing applications work fine on another i686 machine, I knew the problem
had to be in the build.  Subsequent testing showed that the problem was
caused by building the kdelib*.rpm with "-fomit-frame-pointer" and that it
was not specific to the version of kdelibs that shipped with RH v7.1.

2.  I am reporting the as a bug in kdelibs because I have used the
"-fomit-frame-pointer" with many other RH v7.1 packages and seen no ill
effects from it.  If this is a compiler bug, then it is a very narrowly
focused one.

3.  Some hearsay: another guy on the Seawolf mailing list reported seeing
this same behavior in the use of kdelibs-2.1.1-5.src.rpm +

4. Use of the desired compiler switches wasdone by placing them in
/etc/rpmrc, where they were employed by RPM at build time.  No spec files
were edited.

Comment 1 Steve Snyder 2001-05-22 06:08:04 UTC
Damn, my summary was truncated!

Instead of:

    Compiler switch

the summary should read as:

    Compiler switch "-fomit-frame-pointer" breaks kdelibs

Sigh.  Sorry.

Comment 2 Bernhard Rosenkraenzer 2001-05-22 15:34:05 UTC
Definitely a compiler bug. KDE happens to be the only large piece of code 
using C++, that's why it isn't showing up anywhere else.

Comment 3 Steve Snyder 2002-01-16 15:05:10 UTC
What's going on with this bug?  Is building C++ code with "-fomit-frame-pointer"
still dangerous?  If not, in what version of the compiler was it fixed?

Also, regarding the comment "KDE happens to be the only large piece of code 
using C++", please see bug 51238 for another example of "-fomit-frame-pointer"
incompatibility with C++.

Comment 4 Jakub Jelinek 2004-10-02 19:24:42 UTC
If you are able to reproduce this with a contemporary GCC, please

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