strange problem

[Antonio Coralles]

I'm writing on a program [C++] for about six month. Recently I tried to 
switch from my hand coded makefiles to autoconf/automake.  I removed all 
my makefiles, replaced them with the according Makefile.am's and managed 
to build my program with ./configure; make after two days. So far, so 
good. Now the problem is, that the resulting executable contains lot's 
of bugs - bugs which didn't occur with my hand crafted make files. I 
tried to track them down for the last two days, without succes. To make 
that clear: I've made no modifications to my source code - I only 
changed the way my code gets compiled and linked.

Additionally, I've written tests for all nontrivial core-components of 
my programm. This tests work without problems - even when compiled with 
with the GNU-autotools. In particular I've a test for the internals 
responsible for loading/saving - and this test works. But when I try to 
load a file from the main program [this works well when built with my 
hand written makefiles] i get a strange segfault [gdb output]:

#0  0x409d13bb in mallopt () from /lib/libc.so.6
#1  0x409d0521 in malloc () from /lib/libc.so.6
#2  0x4091afaf in operator new(unsigned) () from 
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/libstdc++.so.5
#3  0x08250b89 in 
rule<boost::spirit::sequence<boost::spirit::action<boost::spirit::rule<boost::spirit::nil_t, 
boost::spirit::nil_t, boost::spirit::nil_t>, 
ruleParser::durToArgFunctor>, 
boost::spirit::kleene_star<boost::spirit::sequence<boost::spirit::sequence<boost::spirit::sequence<boost::spirit::kleene_star<boost::spirit::space_parser>, 
boost::spirit::chlit<char> >, 
boost::spirit::kleene_star<boost::spirit::space_parser> >, 
boost::spirit::action<boost::spirit::rule<boost::spirit::nil_t, 
boost::spirit::nil_t, boost::spirit::nil_t>, 
ruleParser::durToArgFunctor> > > > > (this=0xbfffcbb0, address@hidden)
   at rule.hpp:130
#4  0x0824c93c in ruleParser::parse(char const*) const (this=0xbfffccb0,
   str=0x8321fcc "10000: 47:00:00;\n20000: 14:00:00;\n") at parsers.cc:273
#5  0x082349c0 in dataStorage::loadTreaties(sqlite*, unsigned) 
(db=0x83238b8, context=0) at dataStorage.cc:540
#6  0x0822fb4e in dataStorage::loadFileIntoContext(char const*, 
unsigned) (fileName=0x8321d14 "source.dpm", context=0)
   at dataStorage.cc:156
#7  0x0818f600 in main (argc=2, argv=0xbffff204) at main.cc:17

"#4" is the last point in my source. At parsers.cc273 you find:
....
const rule<> timeDurationList = timeDuration[durFunc] >>
                                   *(
                                       *space_p >> ch_p(',') >>       
                               <-------------.....
                                       *space_p >> 
timeDuration[durFunc]                  <-------------272
                                    );                                 
                                               <------------ 273
....

which is part of a boost::spirit grammar specification. This statemant 
doesn't contain the dereferencing of a pointer explicitly [* is just 
overloaded in this context] or implicitly [durFunc is a simple functor - 
timeDuration a rule for parsing time durations]. Because my code works 
with my old makefiles and because of the fact that this SIGSEGV apears 
without any connection, my assumtion is that there is something wrong in 
the way my program gets built. Maybe i should mention the libraries I 
use (appart from the C++ standard library):
1.) boost::smart_ptr
2.)boost::spirit
3.)boost::date_time
4.)gtkmm-2.4.8 [I use PKG_CHECK_MODULES(...) in my configure.ac, 
`pkg-config gtkmm-2.4 ....` in my old makefiles]

Now, one may ask if there is any significant difference between the 
building process with automake and the one with my old makefiles. Well, 
the only differenece I see [so far] is that with automake [i use the 
AC_PROG_RANLIB macro in my configure.ac] for every subdirectory of my 
source, all the *.o files are merged into one static *.a archife file 
which is then used for linking, while my handwritten makefiles use the 
*.o files directly [for every *.cc one *.o].

As a user of gentoo-linux all the applications I'm using on my computer 
are built on this computer - so the change that there is something wrong 
with my environement is fairly low. By the way I'm using gcc-3.3.5, 
autoconf-2.59  automake-1.8.5 and make-3.80.

Maybe someone can give me a hint - or a location where this question is 
more likley to get a sensible answer. If somebody want's to have the 
full source tree just ask - the only reason the program is not yet 
published under the GPL is that I want to fix my automake problems first 
....

thanks,
             antonio