segmentation fault on GiNaC-1.2.0 using MinGW on Win XP
Gabriel Dos Reis
gdr at integrable-solutions.net
Wed Apr 14 20:00:04 CEST 2004
"Richard B. Kreckel" <kreckel at ginac.de> writes:
| On Thu, 8 Apr 2004, Christian Bauer wrote:
| > On Wed, Apr 07, 2004 at 01:28:29PM +0200, Johannes Brunen wrote:
| > > However, the initilaization of the const _num0 reference happens at some
| > > time later. Therefore it is undefined at the point of usage in the
| > > ex::construct_from_int(int i) call from function_options::initialize().
| > Ah, of course. This explains it. The ex() default ctor uses _num0_bp
| > directly, so static ex objects are always initialized correctly as long
| > as you're only using the default ctor.
| The joy of the initializion order!
| It all looks so correct until you realize that the const references
| themselves aren't initialized yet while the objects they're supposed to
| reference are already initialized. This is pervert.
| I still do hope that the C++ Committee does see the light some lucky day
| and realize that they can do a great favor to the language and its
| community by simply demanding that if dependencies form a DAG, then that
| DAG shall be established by the linker. AIX seems to do it. Patches for
| GNU ld to that effect have been suggested. It's so obviously the correct
| thing to do! Rather, they say nothing. The GNU folks then say the order
| is determined by the link line. Hahaha! Very funny. I have 855 modules
| in CLN. Under no circumstances am I going to manually arrange that link
| line. This problem is definitely the most irritating issue of C++. It is
| also the issue most insistently dodged by the Standard Committee.
I think that the committee level, the question is what can we do
about this without falling into describing a particular implementation.
At the "GNU folks" level, I think the issue is different :-)
You said, patches have been suggested for GNU ld, do you have some
More information about the GiNaC-devel