Re: [Gnucap-devel] Build failure with version 2007-08-20

[al davis]

Thank you .. Stuart for testing it on 3.3, and the bug report, 
and David for a diagnosis and quick fix.

I ran some tests on 3.3 
- confirmed the problem
- and that David's patch works
- and there are still more problems with 3.3, that I was able to 
work around, sort of.

I ran into a little problem with the patch ..  I build with lots 
more warnings enabled than you see in the distribution version.  

static const CS_STDIN          _CS_STDIN = CS_STDIN();

results in an "unused" warning in any file that doesn't use it.

It then occurred to me that it could be an enum instead.  All 
that is needed is an object with a type that is known at 
compile time..

enum CS_STDIN {}  // works just like the original
.. and
enum CS_STDIN {_CS_STDIN} // works just like David's, except 
that it doesn't give the "unused" warning, or create lots of 
static objects that are not used.

Then it occurred to me that it might be a better design to use 
one constructor instead of four, with the first arg being an 
enum, and the action determined by checking its value.  I 
didn't change it. ... still thinking about it.

A little history of this code ...  Originally, there was one 
constructor taking a string that was copied in.  Then a second 
one was added, initializing from a file.  Conceptually, a file 
and string are different types, but here they were both 
represented by something of type std::string.  An ID argument 
was added for the file only.  Still later, an incremental file 
(as opposed to a whole file) was added, with another ID 
argument.  Then the original string got the ID argument too, 
for consistency.


Anyway ... this problem seems to only happen with g++-3.3.  It's 
a compiler bug.

There are other problems with 3.3 ..

There is a link problem related to template resolution, 
apparently triggered when one template function calls another 
template function.  I could work around this one by commenting 
out the calls to the problem function, with the consequence 
that certain input text would be parsed different.

There is an optimizer problem leading to a compiler stack 
overflow on one file.  I could work around this one by turning 
optimization off (-O0) or omitting that file, with the 
consequence of a missing model.

3.4 fixes all but the template link problem.  The "mingw" 
compiler, which is 3.4, does not appear to have this problem.

On Saturday 25 August 2007, David Fang wrote:
> BTW, src/ap.h and modelgen/ap.h are identical (same patch
> applied to both), and since modelgen builds with -I
> $(top_srcdir)/src, modelgen's copy can probably be removed to
> avoid confusion.

The ap files, and several others are identical.  My version uses 
symlinks, and older distribution tarballs also did.  It was 
converted to dereference the symlinks to make it work on 
certain operating systems that do not support symlinks.

When developing, I still use the old build system.  It is still 
there .. "configure.old" ..... ..  It provides a lot more 
flexibility that helps a lot for development, but lacks the 
targets needed for installation.  The old one doesn't have 
the "-I $(top_srcdir)/src", but it could.  I forgot that it is 
there in the autoconf version.

The only real reason not to change it is that I am planning a 
big rearrangement anyway.  The current way of having those 
files either symlinked or copied is not good.  "-I" back to a 
directory shared with the files for another program isn't a 
good way either.  The rearrangement will put the common files 
in their own directory.  Having a "-I" back to a place where 
the common includes live makes more sense.  That is what will 
happen.  The big rearrangement will also put pluggable modules 
in a proper place, attempt to put the separate plugin libraries 
in their proper place, etc.  I figured I would get most of the 
plugin system working, then deal with the layout once.


Back to the 3.3 issue ... I need to decide where to draw the 
line on supporting old compilers.  Using an enum here is no 
problem.  If that was all that is needed, I would do it.  I 
have concerns about the other problems with g++-3.3, 
particularly the stack overflow, which happens on both 32 and 
64 bit systems.  (Actually, all of the mentioned problems 
happen both on an AMD-64 and Intel-32.)