Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 232226

Summary: CXXFLAGS/CFLAGS questions
Product: [Fedora] Fedora Reporter: Matthew Miller <mattdm>
Component: festivalAssignee: Matthew Miller <mattdm>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: rstrode
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 1.96-0.11 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-20 19:02:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 232105    
Bug Blocks:    

Description Matthew Miller 2007-03-14 14:15:14 UTC
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 16:05:28 UTC
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 17:43:44 UTC
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 19:28:43 UTC
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 04:23:02 UTC
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 14:33:06 UTC
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 14:45:42 UTC
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 14:55:45 UTC

Comment 8 Matthew Miller 2007-03-20 19:02:04 UTC
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.