[ts-gen] status update -- on the g++4 road; also x86_64

[R P Herrold]

Just a quick note on the road to g++, v4 builds; also I pushed 
the code to an AMD Opteron, for a peek at x86_64; we have a 
US market holiday tomorrow, and so it is time to do some 
development.  ;)

On the garden variety g++ , v 3, on CentOS, all is well; All 
of Bill's targetted tests pass, and all of my extended unit 
tests (which are independently derived from his, as I have 
uncovered issues from time to time, so that I can then 
reproduce them in his test harness), _all_ complete with no 
new unknown issues.

(We see two tonight: a known one that the TWS may not be 
accepting a connection on its listening socket from time to 
time [known: workarounds are either to slow down the pace of 
the tests hammering on the TWS, or simply restart it as such 
errors are transient]; and a strange one I saw for the first 
time today, where the TWS seems to have lost track of a 
submitted order across a socket connection [Bill has seen it 
before; it is exceedingly rare to me as I have seen it only 
this once tonight; as it seems to be some artifact in the 
upsteam code, there is not a lot we can do to run it down (we 
CANNOT reproduce it deterministically); a restart of that test 
succeds with nothing out of the ordinary.])


Bill has detailed in the NEWS file of the slipstreamed daily. 
Please refer to it for his commentary.
 	http://www.trading-shim.org/capitals/?NEWS

As before, on the Debian box, fully updated as per te process 
outlined in the prior communique, I ran the daily updates from 
Debian:
 	apt-get update
 	apt-get -y upgrade
to make sure I was fully current; the expected message came 
back:
 	0 upgraded, 0 newly installed, 0 to remove and 0 not  upgraded.

root at 0[~]# g++ --version
g++ (GCC) 4.0.2 (Debian 4.0.2-2)
Copyright (C) 2005 Free Software Foundation, Inc.

I then untarred the day's release, and patched out the distcc, 
again as mentioned before.

Without distcc, I find it (as expected) painfully slow 
[wallclock of real 10m22.757s, userspace time of 4m13.050s, 
and system of 1m6.160s !!  vs. the under 30 seconds I am used 
to; Bill's faster box gets through to the link phase in more 
like 10 seconds], but unhappily the exercise ends:

g++ -Wall -g -I/usr/include/mysql  -c -o send.o src/send.c
src/type.c: In constructor 
'TradingShimDaemon1_0::ObjectTypeSystem::Predicate::Predicate(const 
TradingShimDaemon1_0::ObjectTypeSystem::Wrapper&, const 
TradingShimDaemon1_0::ObjectTypeSystem::SrcTagVer&, const 
MinimalModeMixedParadigm::ArraysVectorsAndTables::Block<const 
TradingShimDaemon1_0::ObjectTypeSystem::Type>&, const char*, 
const TradingShimDaemon1_0::AppFiniteDomains::Identity&, 
int)':
src/type.c:479: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see <URL:file:///usr/share/doc/gcc-4.0/README.Bugs>.
make[1]: *** [type.o] Error 1
make[1]: *** Waiting for unfinished jobs....


YOUR help is solicited -- please return a: g++ --version and 
results on a test of the tarball (mention that version as well 
please) at:
 	ftp://ftp.trading-shim.org/pub/local/trading-shim/
and share YOUR results into this mailing list.  There 
absolutely (to steal a quote from Jay bailey, are No Dumb 
Questions;  your feedback on coverage is essential to us.

Hoping to better my luck, on the x86_64, we progress well, but 
die off on this:

g++ -Wall -g -I/usr/include/mysql   -c -o type.o src/type.c
In file included from src/../lib/glossary.h:38,
                  from src/glossary.h:16,
                  from src/once.c:10:
src/../lib/interfaces.h:16: error: `operator new' takes type 
`size_t' (`long unsigned int') as first parameter

which we will get to in the future after we solve the g++ v4 
issues.

Thank you for your interest; we welcome feedback and comment.

-- Russ