auto-import STATUS

[Charles Wilson]

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