Mail Archives: cygwin-apps/2001/08/03/23:34:55
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
- Raw text -