On Mon, May 03, 2004 at 03:56:34AM +0200, Lars Roland wrote:
> Good idea, much cleaner and less ifdef's . I decided to use config.h. I
> added appropriate code to config.h.win32 in main dir and in epan. But I
> don't know where to put it for non MSVC users. Probably somewhere in
> "configure.in".
We could, although that's a little bit tricky - it'd have to arrange
that the appropriate #if be put into the config.h file.
For MSVC++, could Makefile.nmake's used to build .dlls define
ETH_VAR_IMPORT as "__declspec(dllimport) extern" if we're building a
libethereal DLL and as "extern" otherwise, and Makefile.nmake's not used
to build .dlls define it as "extern"?
(That'd work, I think, only if no Ethereal shared library's source code
includes headers for any other Ethereal shared library - if it does,
then the headers for the shared library being built needs not to have
the "dllimport" and the headers for other shared libraries presumably
*do* need to have it. How *are* you supposed to handle that with
MSVC++? The page at
http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/gnu-linker/win32.html
appears to explicitly indicate that this is ugly:
This complicates the structure of library header files, because
when included by the library itself the header must declare the
variables and functions as dllexport, but when included by
client code the header must declare them as dllimport. There
are a number of idioms that are typically used to do this; often
client code can omit the __declspec() declaration completely.
See -enable-auto-import and automatic data imports for more
imformation[sic].)
For builds that use the configure script, perhaps the Makefile.am files
could use if's (similar to, for example, what's done with HAVE_PLUGINS)
to control whether to define ETH_VAR_IMPORT as "__declspec(dllimport)
extern" or just "extern". They'd have to test whether
1) we're on Windows (is "__declspec(dllimport)" required for
MinGW *and* Cygwin, or just one of them, or neither of them?)
and
2) whether we're building a dynamically-linked libethereal.
