segmentation fault on GiNaC-1.2.0 using MinGW on Win XP

[Gabriel Dos Reis]

"Richard B. Kreckel" <kreckel at ginac.de> writes:

| Hi!
| 
| 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
reference handy? 

-- Gaby