Mail Archives: cygwin-apps/2001/08/04/14:39:23
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
- Raw text -