This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ad: [app porting to cygwin] Invoking DLL exported routine problem - resolution(?)

this is a follow-up to my previous mail. It seems that after all I found
a solution to my problem described in the previous e-mail. However, I do
not fully understand what's going on as it seems to have something to do
with the specification of C++ language and it seems to be a kind of g++
issue.  Therefore, I would be glad if there's somebody who is able to
enlighten me on the details of the issue together with why it works on
Linux with gcc 4.1.3 and not on Cygwin with gcc 3.4.4. I would like to
learn something from this.

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:

#0  0x6526f575 in std::ostream::sentry::sentry ()
    at /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ostream.tcc:63

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     {
65       // DR 60. What is a formatted input function?
66       // The inserters for manipulators are *not* formatted output functions.
67       return __pf(*this);
68     }

Further research proved fruitful and I found an issue in the GCC
bugzilla speaking about a similar problem:

According to Comment #9
( the problem is
with creation of the cout object and can be healed by a creation of a
static instance of std::ios_base::Init in the routine. This indeed
resolved my problem.

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 (?)... 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).

Thanks for any explanations.



peter.novak [at] |
Department of Informatics | Clausthal University of Technology
Julius-Albert-Str. 4 | D-38678 Clausthal-Zellerfeld | Germany
Tel +49 5323 72 71 90 | Fax +49 5323 72 71 39 

Attachment: pgp00000.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]