This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 232226 - CXXFLAGS/CFLAGS questions
Product: Fedora
Classification: Fedora
Component: festival (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Miller
: Reopened
Depends On: festival1.96
  Show dependency treegraph
Reported: 2007-03-14 10:15 EDT by Matthew Miller
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.96-0.11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-20 15:02:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthew Miller 2007-03-14 10:15:14 EDT
The changelog for Festival contains this comment:

* Sun Jan 22 2006 Ray Strode <> - 1.95-5
- add a lot of compiler flags and random cruft to get
  festival to build with gcc 4.1

which appears to correspond to adding

CXXFLAGS="-ffriend-injection -fpermissive -Wno-deprecated
-Wno-non-template-friend -fPIC" CFLAGS="-ffriend-injection -fpermissive
-Wno-deprecated -Wno-non-template-friend -O0 -fPIC"

to all of the make lines.

This causes 

cc1: warning: command line option "-Wno-deprecated" is valid for C++/Java/ObjC++
but not for C
cc1: warning: command line option "-Wno-non-template-friend" is valid for
C++/ObjC++ but not for C
cc1: warning: command line option "-ffriend-injection" is valid for C++ but not
for C
cc1: warning: command line option "-fpermissive" is valid for C++/ObjC++ but not
for C

to be scattered through the build. I'm going to try taking those out of CFLAGS
to see if that still works.

Ray, if you don't mind, can you explain the need for these flags for me?

Plus, as far as I can see in the makefiles, the libraries are already built with
fPIC -- should the other binaries really be built that way too?

We've also got this:

%ifarch ppc
export CFLAGS

which is of course overridden by the above lines further down. Don't we want
$RPM_OPT_FLAGS on all archs?

Also, does anyone know the reason for the -O0? I can test without, of course,
but I note that the package's own makefiles default to -O3. Was there a specific
problem with the -O2 in the default $RPM_OPT_FLAGS?

Comment 1 Ray Strode [halfline] 2007-03-14 12:05:28 EDT
IIRC, festival wasn't building because of some way it was treating friend
functions.   I don't really remember the details.  I think I just added compiler
flags until it built because it was blocking a lot of other packages from
getting built and we were nearing some release.

Comment 2 Matthew Miller 2007-03-14 13:43:44 EDT
Okay, thanks. :)

I'm going to try and see what I can do with a less gigantic hammer. :)
Comment 3 Matthew Miller 2007-03-14 15:28:43 EDT
At least one of the build problems: In member function 'int
rt() const': error: cast from 'EST_UItem*' to 'int' loses precision In member function 'int
t(int) const': error: cast from 'EST_UItem*' to 'int' loses precision

is a 64-bit cleanliness issue. Working on getting that fixed upstream.
Comment 4 Matthew Miller 2007-03-15 00:23:02 EDT
Okay, so I have a patch for the comment #3 issue, and everything seems to be
working at this point with "$RPM_OPT_FLAGS -fPIC -fno-shared-data
-fno-strict-aliasing" for speech_tools, and just $RPM_OPT_FLAGS for the main
festival program.

Turning off strict aliasing is necessary to get -O2 (or higher) to work.

-fPIC is because I can't easily sort out the library objects from the rest
without a lot of digging, and I'm not sure it's worth the trouble because -fPIC
doesn't, as far as I know, cause any harm and may even be good.

And -fno-shared-data because the upstream makefile references that for building
the shared libs and it seemed good to play along.

This is all in my latest version of the package -- see bug #232105.
Comment 5 Ray Strode [halfline] 2007-03-15 10:33:06 EDT
Cool. I'm just going to mark this a dupe of 232105, because we'll get the fixes
when we switchover to your new and improved festival package.

*** This bug has been marked as a duplicate of 232105 ***
Comment 6 Matthew Miller 2007-03-15 10:45:42 EDT
For my own keeping track of things, I'd rather do it as having these bugs
blocked by that one, actually....
Comment 7 Ray Strode [halfline] 2007-03-15 10:55:45 EDT
Comment 8 Matthew Miller 2007-03-20 15:02:04 EDT
This issue should be resolved by the release of festival-1.96-0.11, now in the
development tree. (See bug #232105 for details.)

Please reopen if there's still a problem. Thanks.

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