guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DLLs and exported symbols...


From: Lars J. Aas
Subject: Re: DLLs and exported symbols...
Date: Mon, 20 Nov 2000 16:27:45 +0100
User-agent: Mutt/1.2.5i

On Sat, Nov 18, 2000 at 03:04:53AM +0100, Lars J. Aas wrote:
: When creating Windows32 .DLLs, you must explicitly specify each
: symbol that is to be exported in the .DLLs API.  One way to do
: this is to precede every public declaration with the string
: `__declspec(dllexport)'.  Every function, every data member...
: Only while building the .DLL, though.  When you compile against
: the .DLL, that string must not precede the symbols.
: 
: One of the most common ways to do this is to use a define that
: contains that string when compiling the library, and which is
: empty when you're a client.  I propose having a new define
: `SCM_PUBLIC' be the conditional container of that string, and
: adding the following code to libguile/__scm.h
: 
: | #ifdef GUILE_MAKE_DLL
: | #define SCM_PUBLIC __declspec(dllexport)
: | #endif
: |
: | #ifndef SCM_PUBLIC
: | #define SCM_PUBLIC
: | #endif

I've done some further reading on the matter, and found that if you
in addition set SCM_PUBLIC to "__declspec(dllimport)" when you compile
against the DLL, the compiler will produce more optimal code.  One
should in other words test for a GUILE_USE_DLL define too for that case
(which you should get from the autoconf guile macro, I guess).
I'm not thrilled with the name SCM_PUBLIC, maybe GUILE_API or something
similar would be better.

An alternative to flagging all the definitions in the header files is to
maintain a separate .def file for the guile DLL.  This solution introduces
the problem of keeping the .def-file in sync with the actual guile library,
so it takes more work to maintain, and you miss the option of getting more
optimal code by using "__declspec(dllimport)" when linking against Guile.
If however this alternative is more preferable, the .def-file could maybe
be "snarfed" from the header files to avoid some of the maintenance overhead.

  Lars J



reply via email to

[Prev in Thread] Current Thread [Next in Thread]