X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <474E6042.ED82EC76@dessent.net>
Date: Wed, 28 Nov 2007 22:46:26 -0800
From: Brian Dessent <brian AT dessent DOT net>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
MIME-Version: 1.0
To: Peter Novak <peter DOT novak AT tu-clausthal DOT de>
CC: cygwin AT cygwin DOT com
Subject: Re: Ad: [app porting to cygwin] Invoking DLL exported routine problem -   resolution(?)
References: <20071125114321 DOT GS5783 AT aronde DOT net> <20071125152255 DOT GT5783 AT tu-clausthal DOT de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Peter Novak wrote:

> What I forgot to mention in my previous e-mail and what turned out to be
> crucial, is that my DLL uses std::cout for writing output to the
> console. I found, that whenever I have a print to cout in a routine, the
> subprocess crashes even *before* entering the routine(!). Struggling
> with gdb and multi-threaded application showed that the crash occurred
> in an esoteric place of:

The reason it crashes before your routine is called is that (assuming
PR26123 is in fact the cause) the problem has to do with the order of
static constructors.  This happens at program startup (for objects in
the .exe) or at DLL load time (for objects in the .dll).

> The code there lists a remark about supposedly an issue of GLIBC (???):
> 59   template<typename _CharT, typename _Traits>
> 60     basic_ostream<_CharT, _Traits>&
> 61     basic_ostream<_CharT, _Traits>::
> 62     operator<<(__ostream_type& (*__pf)(__ostream_type&))
> 63     {
> 64       // _GLIBCXX_RESOLVE_LIB_DEFECTS
> 65       // DR 60. What is a formatted input function?
> 66       // The inserters for manipulators are *not* formatted output functions.
> 67       return __pf(*this);
> 68     }

The symbol/namespace _GLIBCXX in this context refers to gcc's libstdc++,
not glibc, so that's kind of a red herring.  I don't think the above
comment has anything to do with your problem per se, as DR 60 is about
formatted input:
<http://gcc.gnu.org/onlinedocs/libstdc++/ext/lwg-defects.html#60>.

> Can somebody explain me why this worked the way it did? My guess is that
> it has something to do with Linux loading a shared library into the
> memory space of the running process, while on Win32 the DLL has it's own
> memory space (?)...

On both Win32 and Linux, shared libraries are in the same memory address
space as the executable; there's no difference in that respect.

> Anyway, it does not explain why loading DLL from the
> main thread was OK, while loading it from a subprocess wasn't (all
> components, i.e. main process, subprocess and DLL use cout to print
> stuff to console).

Well again, if the bug is in fact related to the order that static
constructors are run, then the difference in behavior could simply be
due to the fact that under the hood PE and ELF use different methods of
dispatching static ctors, so it follows that the order (which is
unspecified) could be volatile.  By explicitly adding a
std::ios_base::Init static object I suppose you are somehow affecting
this order to cause it to be correct.  I can't say for sure why this is,
but it's in general a very tricky aspect of C++, see also:
<http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12>.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/