Bug 232226 - CXXFLAGS/CFLAGS questions
Summary: CXXFLAGS/CFLAGS questions
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: festival
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Matthew Miller
QA Contact:
URL:
Whiteboard:
Depends On: festival1.96
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-14 14:15 UTC by Matthew Miller
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 1.96-0.11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-03-20 19:02:04 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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.


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