Re: DLLs and exported symbols...

[Dale P. Smith]

Dirk Herrmann wrote:
> 
> On Mon, 20 Nov 2000, Lars J. Aas wrote:
> 
> > : | #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.


> What about a SCM_BUILD_ prefix for build-time options?  SCM_BUILD_INFO
> already exists and defines a full set of such options.  Examples:
>   SCM_BUILD_INFO as already used
>   SCM_BUILD_DLL instead of GUILE_MAKE_DLL or SCM_MAKE_DLL
>   SCM_BUILD_WITH_THREADS instead of USE_THREADS
>   SCM_BUILD_WITH_DYNAMIC_LINKING instead of DYNAMIC_LINKING
>   SCM_BUILD_WITH_... for other --with-<foo> configure options

Maybe SCM_COMPILE_ ??  But that's even longer.  I hate 

> Regarding the SCM_PUBLIC macro, however, I currently have not yet a good
> idea how that should be solved.  Please forgive the following question,
> but:  Have you checked all possible compiler options as well as #pragma
> directives of the compiler that you are using?  It seems almost
> unbelievable to me that everybody should be forced to change their code
> like that, just to produce a DLL for windows.  (On the other hand, it
> would fit into _their_ concept, I guess :-)

That's just the way it is.  Just another way that Ms tries to lock you
into their tools.

Last place I worked we used gcc on all platforms. Except windows.  (I
actully had a gcc win32 compiler running on Solaris, it worked great,
but I couldn't generate win32 debug information.) We had to use macros
like SCM_PUBLIC above. Dll code and code that calls the dll needed
protypes to be declared differently.  Something like "export" for one
and "import" for the other.  But my memory (gladly!) fades.

One thing that is sort of nice about dll's, you can define *exactly*
what your public interface is.  In .so type systems, every global is (a
potential) part of your api.  We had a mandate that no application
needed a recompile for new .dll's or .so's.  It was much easier to
control with .dlls.

Lars, what are you planning on exporting?  Just the init code?  All the
gh_ interface?  Lot's of Guile C modules dip in beyond the gh_ interface
when necessary.

-Dale 

-- 
Dale P. Smith
Altus Technologies Corp.
address@hidden
440-746-9000 x309