|Product:||[Fedora] Fedora||Reporter:||Matthew Miller <mattdm>|
|Component:||festival||Assignee:||Matthew Miller <mattdm>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||1.96-0.11||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-03-20 19:02:04 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||232105|
Description Matthew Miller 2007-03-14 14:15:14 UTC
The changelog for Festival contains this comment: * Sun Jan 22 2006 Ray Strode <email@example.com> - 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