Re: AIX I/O failures

[Benjamin Kosnik <bkoz at redhat dot com>]

mark this has been discussed in this thread:
http://gcc.gnu.org/ml/libstdc++/2001-01/msg00158.html

It's currenly unresolved.

One approach would be to use init_priority, but portability issues on non 
ELF/COM platforms make it less attractive.

The array of chars idea seems pretty opaque. 

> I now know at least one reason why I/O is not working on AIX.
> 
> The basic problem, of course, is that AIX does not do the SVR4-ish
> depth first ordering of shared library initializers.  Instead, they
> are run in a "random" order, i.e., one that is not useful to us. :-)
> 
> The ios::Init::Init trick is supposed to help with this -- every file
> that includes I/O facilities gets one of these objects, and the first
> one to get constructed sets things up.
> 
> But, in contrast to the placement-new patch that I first proposed, the
> current sources contain explicit initializations of `cin' and friends
> in `ios.cc':
> 
>  istream cin(NULL);
> 
> This is wrong, because these initializers run *after* the initializers
> for the main program -- the ones that did placement new on these
> objects to make sure that they were all set up nicely.  So, we
> essentially blow away the work we did.
> 
> That's why my original patch used the trick:
> 
>   char cin[sizeof(istream)]
>      __attribute__ ((__align (__alignof__ (istream))));
> 
> (or something similar) to make sure that the storage was allocated,
> but that it was never actually initialized.  This is the only reliable
> I know of to make this work, given the AIX constraints.
> 
> We have to design with the following basic constraint in mind:
> 
>   - We cannot assume initializers for libstdc++ will run before 
>     initializers for other libraries.
> 
> Therefore, *any* use of static initializers in libstdc++ constitutes a
> bug -- other than the ios::Init::Init trick where you call a function
> that can safely be called more than once, and is guaranteed to be
> called by any object that makes use of that functionality.
> 
> That means that all global objects that need what looks like static
> initialization need to use the array of chars trick (or something else
> I haven't thought of yet!) and placement new; that way they *look*
> like global objects of the right type, but they're initialized when
> needed, and only once.

the array of chars trick seems less than ideal. I haven't thought of 
anything better myself though, so if the init-priority bits can't be 
worked out maybe this is the approach that should be used.

-benjamin