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: <3B6C4156.7060404@ece.gatech.edu>
Date: Sat, 04 Aug 2001 14:39:18 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010713
X-Accept-Language: en-us
MIME-Version: 1.0
To: Danny Smith <danny_r_smith_2001 AT yahoo DOT co DOT nz>
CC: 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
Subject: Re: auto-import STATUS
References: <20010803233635 DOT 73332 DOT qmail AT web14506 DOT mail DOT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Danny Smith wrote:

>
> 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.


And Danny Smith later wrote:

> Yes this is what I know:  --export-all-symbols is used when building
> the dll, full stop.
> It is a lazy substitue for a def file.  It is used  implicitly if you
> don't have a def file or haven't used attributes to mark dllexport
> attributes.
> The same behaviour as with dlltool.
> It works fines, and puts the correct prefixess on DATA symbols.
> 
>  
> That  is not what was causing the problem, because:
> --export-all when building lib and using __attribute__(dllimport) when
> building client then linking works.
> --export-all when building lib; using --enable-auto-import when linking
> works too, but... I have to change other things in the way classes are
> defined  
> 
> there are other considerations on when and where things get constructed
> and destroyed that can cause problems with C++ dlls.  And that is the
> caveat.  There is (sometimes) more to building a C++ dll than just
> getting the DATA symbols marked correctly.  Ralf has run into some
> others.  If you go through some of the VC++ user list archives you will
> find more. 
>  All I was trying to point out that --enable-auto-import is a
> quick-fix, but not always the best fix.


Okay, I only VAUGELY remember this, but....

Forget for a moment the recent auto-import improvements.  Think plain 
old-fashioned DLL support, requiring declspec(dll[ex|im]port) markings 
on data.

Wasn't there some discussion many months ago about ld and C++ DLL's, 
something about needing to explicitly mark data fields within classes as 
declspec(), EVEN when the class ITSELF is marked declspec() ?

Now, perhaps that got fixed.  Perhaps it didn't.  But, since an inner 
class is probably implemented as a field OF the enclosing class, maybe 
Danny's problem is related?  (a) the old problem never got fixed, and is 
rearing its head here, or (b) the old problem got fixed -- but only 
partially and the fix needs to be extended to cover the "inner class" 
case.  Or I'm just blowing smoke.

Does anybody remember this?

Now, returning to the new auto-import case:

So, perhaps the logic that adds thunking symbols for DATA exports in 
DLLs needs to be re-examined, to make sure it covers these special 
cases, esp. "static" fields of classes, and inner classes, (and "static" 
fields OF inner classes...)

Unfortunately, I can't really pursue this -- or anything else 
cygwin-related -- for the next week or so.  My laptop broke (mechanical) 
and I have to send it back to Dell for repair.  But, I have no other 
machine that's configured for cygwin development, so I'm out of action 
for more than a week.  (Plus, for a different reason, I'll be out of 
email contact Sunday/Monday.)

Can somebody else please pursue this (and perhaps the other things 
mentioned in the first message of this thread), now that I've managed to 
push the initial auto-import into binutils CVS ?

--Chuck