Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-apps-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/lists.html#faqs>
Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com
Message-ID: <20010803233635.73332.qmail@web14506.mail.yahoo.com>
Date: Sat, 4 Aug 2001 09:36:35 +1000 (EST)
From: =?iso-8859-1?q?Danny=20Smith?= <danny_r_smith_2001 AT yahoo DOT co DOT nz>
Subject: Re: auto-import STATUS
To: Charles Wilson <cwilson AT ece DOT gatech DOT edu>,
        Paul Sokolovsky <paul DOT sokolovsky AT technologist DOT com>,
        Robert Collins <robert DOT collins AT itdomain DOT com DOT au>,
        cygwin-apps AT cygwin DOT com
In-Reply-To: <3B69F92E.1000501@ece.gatech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

 > 
> 3. Danny Smith reports an esoteric problem:
>     "I am still having some (sorry, one very specific) problem
>     with C++ and auto-import.  It is with cerr, cin, cout in
>     the STLport of the SGI iostream lib.  These are initialised
>     before main.  When building dll with auto-export and using
>     auto-import to link (no dllimport attributes), I get
>     successful link, but runtime failure of app at initialisation
>     (before main). When building dll with --export-all, but
>     marking DATA with dllimport when compiling client, I get
>     successful link and run."
> 


In the event, the problem I reported with STLPort probably has nothing
to do with dllimport/dllexport attributes.  Instead, I think it stems
from differences in the way basic_[io]stream::sentry is constructed in
dll vs static lib in this implemntation. In dll, sentry is typedef
(within scope of surronding stream class) for standalone separate
class, in static lib sentry is an inner class, defined within the basic
stream classes. Another difference between dynamic linking and static
linking revolves around what is exposed in the header: with DLL linkage
cannot expose the "general" template definitions of helper templates,
unless explicitly declare each and every  char and wchar_t  that does
reside in the dll as a specialisation.

If I use the static lib class definitions and --export-all to build the
lib, but the dll class definitions (sans __attribute__(dllimport)) 
when building the client and --enable-auto-import, I get no errors with
dll-dependent test app.  

I still don't understand the logic completely, but I cannot get
iostreams to initialise properly, using DLL,  with  [io]stream::sentry
defined as inner class by client app, regardless of the dllimport
attribute markings.

There is a caveat here somewhere about C++ dlls. One of them being not
to let DS lose around templates.

Danny



_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more!