Mail Archives: cygwin/1999/08/26/02:43:31
James Stern <jsternitg AT yahoo DOT com> writes:
>
> As I understand it, the situtation is this: Suppose
> that source file s1.cc used in main.exe references
> extern variable v1 from the DLL. Then s1.cc has to
> declare v1 as __declspec (dllimport). If s2.cc
> through s20.cc also use v1, they must do likewise.
>
> If this is true, I'll have to change about 140
> declarations in the legacy application I'm porting.
> Each will need a macro, M, that expands to either
> __declspec (dllimport) or to nothing.
>
> These declarations appear in header files so I'll also
> have to properly define M in every source file that
> includes one of these headers.
>
> Is there an easier way to do this? For example, is
> there a way to specify at link time that a variable is
> imported?
Not really. I did research this issue when I first started
the dllimport/dllexport implemention, but came to the
conclusion that it just won't work given how DLLs work.
There is no silver bullet, sorry.
Most software suffer from the unfortunate reality of bad
modularization, and it gets in the way of making DLLs since
the "ownership" of symbols are spread across headers shared
by various modules. Languages like C require extra care,
which just makes matters worse.
My first lecture in a corporate software engr course I used
to teach involved long boring discussions on the importance
of design before writing the first line of code. One essential,
and often overlooked, part of the design process is the layout
of the modules in terms of files (since files are what we typically
use in most implementations). Too bad that I myself often break
that guideline on a regular basis.
> I realize that the application has too many extern
> variables but it's legacy and not mine to rewrite.
First thing I do is to make sure no implementation file (eg.,
C and C++ files, not headers) *ever* use extern statements,
and that each header belongs to one particular module. If your
source files do contain extern decls, something is wrong and
needs to be handled. My last group had the misfortune of porting
a project of few million lines of C++, with a bit of C glue,
and we had two engineers working 50% of the time tackling these
issues. We did manage to turn all of the 50+ shared libraries
into DLLs, but it was a long fight.
> I also realize that fixups of this nature are harder
> to do for variables than for functions but I thought I
> should doublecheck anyway.
Functions are trivial to handle via thunks (via import
libraries created by dlltool or implib or some such tool);
it's the variables that you have to worry about, which have
no traditional way to "fix up" in the DLL model.
You'll just have to deal with it.
I know of one case where the developers talked about writing
a custom PE loader to deal with this (at the expense of
compatibility of existing tools), but that project never saw
daylight outside of the South Bay cafes.
Bearer of bad news,
Mumit
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -