Bug 232226

Summary:	CXXFLAGS/CFLAGS questions
Product:	[Fedora] Fedora	Reporter:	Matthew Miller <mattdm>
Component:	festival	Assignee:	Matthew Miller <mattdm>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	rstrode
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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:
Embargoed:
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 <rstrode> - 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
CFLAGS="$RPM_OPT_FLAGS -O0"
export CFLAGS
%endif

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?

Thanks!

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:


EST_DProbDist.cc: In member function 'int
EST_DiscreteProbDistribution::item_sta
rt() const':
EST_DProbDist.cc:313: error: cast from 'EST_UItem*' to 'int' loses precision
EST_DProbDist.cc: In member function 'int
EST_DiscreteProbDistribution::item_nex
t(int) const':
EST_DProbDist.cc:329: 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

sure

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.