UNIX and Linux Applications

When ran configure for speech tools 1.2.96-beta (festival speech synthesis) on Slackware 13.0 seems it is erroneously coded.
This code sequence gets flagged 5 times in configure:

Code:

int main() {
int j= 
                #if __GNUC__ == 3 
                3;
                #endif 
; return 0; }
EOF

Will the following fix it?

Code:

int main() {
int j = 3;
return 0;
}

My C ++ has been replaced by classic C but maybe this is something else!!

2 Questions:

---------- Post updated at 07:54 ---------- Previous update was at 07:50 ----------

Quote from the GCC documentation So your example seems to be a cheap trick to check the compiler version. The reason might be that there are some problems if it's compiled with GCC version 3, and this code disables/enables some compiler features or code parts that caused that problem.

configure runs to completion with no warning/errors (flags being either) displayed to console.
The recommended procedure is to make a change to lines 18 & 64 in config/config.
In speech-tools directory I then examined config.log (which is supposed to be the output of the configure script) where I found the following errors (I'll show only 1 for brevity but they are all identical. Here is the requested error from config.log (sorry I said configure earlier, which it is, but the error is shown in config.log):

Code:

configure: In function 'main':
configure:1114: error: expected expression before ';' token
configure:1110: warning: unused variable 'j'
configure: failed program was:
#line 1107 "configure"
#include "confdefs.h"
#include <stdio.h>
int main() {
int j= 
                #if __GNUC__ == 2 && __GNUC_MINOR__ == 95
                3;
                #endif 
; return 0; }

My recollection is that C would not like the ";" preceeding the return nor the embedded comment in the assignment statement. Is that correct?
As you can see this is a consequence of the configure script running i.e. configure:...
An alternative of this is that some mods were not made at run time to configure that should have fixed this to prevent these "errors"

My initial running of configure (since there were no errors on standard output) was followed by a make. Make produced (standard out) errors for -fno-shared-data option for the gcc compiler because that option is not available for version 4.3.3 of gcc.
This is yet to be resolved but it was reportedly fixed for the Debian distro but I presume it was not fixed for the .tar.gz files (Debian, I believe uses rpm or similar).

Just as I posted above I vaguely remembered that note you made about version.release.patch. The is what I was referring to as an alternate. My group & I quit using macros back as they caused too much confusion, we abandoned them. Yeh, I know the management mantra!
Since this is looking for an earlier version what can be done?? If I am forced to back up to release 95 of festival I going to junk this.

You're right, C doesn't like empty assignments. But in this case that's probably wanted because configure is using the __GNUC__ defines as a way to check whether it's using GNU C at all, and which version. Any other compiler won't set those defines at all, and those that set it define it with the current version information.

As for the "fix". Debian uses the .deb format (short for "Debian"), and sometimes modifies the software so that it will run. Slackware, OTOH, uses (almost) exclusively vanilla (unmodified) code. But you can try and apply the Debian fix yourself, the patch is available here

Pludi want to thank you for your help! I googled info on configure looking for what does this type of error mean as opposed to my direct query you responded to. Consequently, I learned not to use the configure file which comes with the package. Rather to run autoconf against configure.in then run that process's configure file. But alas I can't get a break. I am getting new errors which are are not for me resolvable since I cannot get a direct relationship between the error and cause. When I look back into configure where config.log points I am not finding what is flagged as the culprit and on and on whine!
The business about preprocessing may yield some info now that I know more about the options available for configure and make. Funny there was no man page for configure.
Thanks again

While often perceived as such, configure is not, and never was, a part of any UNIX standard. It's basically just a script that checks for certain capabilities in the building system, but there's no predefined options to influence that process, or even a definition of how that should be done. And since every package is responsible for it's own configure script (if it even has one) there can't be a system-wide man page for it.

I would beg to differ slightly with what you said about not predefined options. There are options. Just do ./configure --help. There are options to just do checking without setting up the makefile and a bunch of stuff. That was why I made the comment about not being a man page for it.
As to "how it should be done" look at this site:
http://www.linuxtutorialblog.com/pos...stall-tutorial
Apparently some of the developers have established some constraints for themselves when building configure scripts.
Told you I had been slogging about <);^)