[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnucap-devel] Build failure with version 2007-08-20
From: |
al davis |
Subject: |
Re: [Gnucap-devel] Build failure with version 2007-08-20 |
Date: |
Wed, 29 Aug 2007 16:48:37 -0400 |
User-agent: |
KMail/1.9.7 |
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.)