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: <3B6B6D15.1010804@ece.gatech.edu>
Date: Fri, 03 Aug 2001 23:33:41 -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: Robert Collins <robert DOT collins AT itdomain DOT com DOT au>
CC: Danny Smith <danny_r_smith_2001 AT yahoo DOT co DOT nz>,
        Paul Sokolovsky <paul DOT sokolovsky AT technologist DOT com>,
        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> <996892555 DOT 8222 DOT 13 DOT camel AT lifelesswks>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Robert Collins wrote:

>
> --export-all should NOT be used with --auto-export. They have different
> uses!


Technically, there is no "--export-all" option.  It's 
"--export-all-symbols".  However, the getopt() that ld uses will match 
--export-all to --export-all-symbols.  Also, there is no "--auto-export" 
option either.  There is, however, an "--enable/disable-auto-IMPORT" 
option pair.


> --export-all is used to get _every_ symbol exported, and then filtered -
> as the current cvs libtool does, using dlltool. 
> 
> --auto-export provides aliases exports for data symbols allowing
> --auto-import to work.


Nope.  There is no --auto-export option.  The auto_export() function is 
a filtering function that strips out "bad" symbols that are "considered 
for export" -- but the only thing that would make ld create this list of 
"possible exports" is:
  explicit(1): --export-all-symbols or
  implicit(2): (no def file) && (no __declspec(dllexport) directives)
The auto_export() filter is NOT called unless (1) or (2).  (or a third 
option, not germane here: --add-stdcall-alias, in case the stdcall alias 
is on our "banned symbol" list).

On further inspection of the code, it looks like the data aliases are 
added always.  The only thing auto_export() does is make 
--export-all-symbols (either in its explicit form (1) or its implicit 
form (2)) behave properly.

I didn't realize this until now; perhaps the "add wicked thunking 
symbols to dll" should not happen automatically -- maybe we DO need an 
--enable/disable-auto-export option.


> I don't know why --export-all keeps comingup in these auto-import
> discussions - BUT IT SHOULDN'T.


Not true; it's still needed if (a) you have a partial .def file but it 
isn't complete, or (b) you have some __declspec() decorators, but not on 
everything.  Anyway, a quick look at the code shows that 
"--export-all-symbols" sets pe_dll_export_everything = 1.  Then only 
place that variable is referenced in a test is here:

pe-dll.c process_def_file(): (line 494)

       if no def file, set the pe_def_file = def_file_empty()
       search all objects looking for .drectve sections, pushing
           those into the pe_def_file structure (this takes care
           of explicitly __declspec(dllexport) decorated items)
494:  if (pe_dll_export_everything || pe_def_file->num_exports == 0)
       {  -- search for global symbols
          -- call the auto-export() filtering routine
       }

So, if you have NO .def file, AND you have no "hand-decorated" 
__declspec(dllexport) exports, THEN the result is EXACTLY the same as if 
you had typed --export-all-symbols.

But the combination of cond(1) and cond(2) above is EXACTLY the case we 
want: here's this "unported package" and I want a dll.  Sure, in that 
case --export-all-symbols is overkill, but it just makes BOTH clauses of 
the if statement true, instead of just one.


> WARNING: --export-all will export data symbols without aliasing AFAICT,
> so things will link, BUT NOT RUN.


It sure looks to me that you're wrong on this one.  Pls give a code 
reference or empirical evidence for this statement.


>>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.
>>
> 
> My guess is that it's the use of --export-all that is causing you
> headaches.


My guess is there may still be a few bugs.  :-)

--Chuck