View Issue Details

IDProjectCategoryView StatusLast Update
0000170ascendbuild-linuxpublic2009-05-01 17:48
Reporterjohn 
Assigned Tojohn 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target Version0.9.7Fixed in Version0.9.5.113 
Summary0000170: Error with YY_USE_CONST redefined in FC4 / GCC 4.0.2
DescriptionI found that with the current autotools build on FC4, I had to remove the -DYY_USER_CONST in the compiler makefile before I could get a successful build. Don't know if this is something I have wrong in my ./configure options, but I'm commiting a fix for it anyway. Let me know if any problem with that.
TagsNo tags attached.

Relationships

related to 0000176 closedjohn Jam build system doesn't update correctly on change to ascParse.y 

Activities

john

2005-12-20 09:19

administrator   ~0000115

Fixed in changeset 155

ben

2005-12-20 19:55

manager   ~0000118

Please describe the actual problem instead of just saying 'won't work for me'.
When I compile with this flag on the command line per the usual make
on fc4 with
cc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
the compiler builds just fine. there's a warning, but not a significant one.
YY_USE_CONST is needed to make ascend work on other OS's and less recent
versions of yacc/lex. The latest greatest gnu tools is not our only requirement.

john

2005-12-21 00:59

administrator   ~0000121

The error message that I saw on this bug was that YY_USE_CONST was being *redefined*. It was an error and not a warning. I would have changed the #define macros to fix this but I couldn't find where they come from -- scanner.l doesn't have any #defines relating to YY_USE_CONST and I didn't find this token anywhere else either. If you can point me to where I can fix this properly, I'll happily do that.

ben

2005-12-21 05:07

manager   ~0000130

if your gcc thinks this is an error rather than a warning, your cflags
probably include something that converts warnings to errors or is being otherwise
extremely pedantic. What is the complete compile line (cc invocation) displayed before the error?
A good definition of 'too picky' for compiler options is 'breaks spuriously on the
output from flex or yacc', which appears to be the case here.

I believe the cited link is dead comment refers to some link to gcc 4 docs mentioned in the max macro discussion.

john

2005-12-21 05:54

administrator   ~0000141

I had this error, which I thought was related, but now I'm not so sure:

../generic/compiler/scanner.l: In function ?zz_lex?:
../generic/compiler/scanner.l:412: error: ?zz_lval? undeclared (first use in this function)
../generic/compiler/scanner.l:412: error: (Each undeclared identifier is reported only once
../generic/compiler/scanner.l:412: error: for each function it appears in.)

john

2005-12-21 08:52

administrator   ~0000142

I think the problem with the zz_lex thing is simply a Jam configuration problem.

john

2005-12-21 11:34

administrator   ~0000144

Can fix Jam build by removing YY_USE_CONST define:

Index: jam/Jamfile
===================================================================
--- jam/Jamfile (revision 159)
+++ jam/Jamfile (working copy)
@@ -249,9 +249,6 @@
   # tools. If not, copies of pre-generated files are used instead.
   #----------------------------------------------------------------------

- # ascParse.c needs a special define
- CCFLAGS on ascParse$(SUFOBJ) += -DYY_USE_CONST ;
-
   rule make_ascParse
   {
       if $(YACC) && $(SED)
@@ -306,9 +303,6 @@
   # the a copy of a pre-generated file is used instead.
   #----------------------------------------------------------------------

- # scanner.c needs a special define (Watcom requires the '=""'. )
- CCFLAGS on scanner$(SUFOBJ) += -DYY_USE_CONST="" ;
-
   scanner_c = [ FGristSourceFiles scanner.c ] ;
   scanner_h = scanner.h ;
   scanner_l = scanner.l ;

john

2006-05-10 04:00

administrator   ~0000332

This may be a Jam-only issue; I haven't seen it using SCons of late. Perhaps it's fix.

john

2009-05-01 17:34

administrator   ~0000489

not sure when this was fixed exactly, but currently builds OK on Fedora 9.

Issue History

Date Modified Username Field Change
2005-12-20 08:14 john New Issue
2005-12-20 09:19 john Note Added: 0000115
2005-12-20 09:19 john Status new => feedback
2005-12-20 19:55 ben Note Added: 0000118
2005-12-21 00:59 john Note Added: 0000121
2005-12-21 05:07 ben Note Added: 0000130
2005-12-21 05:54 john Note Added: 0000141
2005-12-21 08:52 john Relationship added related to 0000176
2005-12-21 08:52 john Note Added: 0000142
2005-12-21 11:34 john Note Added: 0000144
2006-02-07 13:19 john Target release => 1.0
2006-02-07 13:24 john Target release 1.0 => 0.9.6
2006-05-10 04:00 john Target release 0.9.6 => 1.0
2006-05-10 04:00 john Note Added: 0000332
2008-02-10 17:58 john Status feedback => assigned
2008-02-10 17:58 john Assigned To => john
2009-05-01 16:52 john Target Version => 0.9.7
2009-05-01 17:34 john Note Added: 0000489
2009-05-01 17:34 john Status assigned => resolved
2009-05-01 17:34 john Fixed in Version => 0.9.5.113
2009-05-01 17:34 john Resolution open => fixed
2009-05-01 17:48 john Status resolved => closed