lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Building with shared-library attributes


From: Greg Chicares
Subject: Re: [lmi] Building with shared-library attributes
Date: Thu, 05 Jan 2006 13:26:18 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

On 2006-1-1 16:29 UTC, Greg Chicares wrote:
[...]
> It is probably possible to use shared-library decorations for autotools
> builds nonetheless, if necessary, by prepending a block like this:
> 
>   #if defined HAVE_CONFIG_H
>   #   define LMI_USE_SO_ATTRIBUTES
>   #   if defined DLL_EXPORT
>   #       define LMI_BUILD_SO
>   #   else  // !defined DLL_EXPORT
>   #      define LMI_USE_SO
>   #   endif // !defined DLL_EXPORT
>   #endif // defined HAVE_CONFIG_H
> 
> but that will work only for the main binary, lmi_wx_shared$(EXEEXT).

Vadim--Do you feel we should make a change like this now? Due to the
limitation in the last quoted line, I'm guessing that this should be
postponed indefinitely. But we had talked, off this list, about such
a change, and I wanted to record some thoughts before I forget them.

1. Some comments should precede the block above. Here's an amalgam
of things you and I had written:

// For autotools builds, libtool defines DLL_EXPORT when a shared
// library is to be built; if DLL_EXPORT is not defined, then assume
// that either a static library is being built or used, or a shared
// library is being used with --enable-auto-import.
//
// TODO ?? The Autobook:
//   http://sources.redhat.com/autobook/autobook/autobook_255.html
// suggests using a macro for __declspec(dllimport) as well.

The 'dllimport' macro sounds like a nice refinement, although it
seems not to be necessary--AFAICT, it really just avoids a thunk.
OTOH, '--enable-auto-import' strikes me as a kludge, and sometimes
it requires the further '--enable-runtime-pseudo-relocs' kludge.
If we pursue this subject at all, we should decide whether to follow
the Autobook's advice or not.

2. I think it's better to put any autoconf logic in a separate block
as above, translating from autoconf to lmi macros, instead of writing
it into the already-complex conditional in 'so_attributes.hpp' as a
special case.

3. One could, of course, simply write:

#if defined DLL_EXPORT
#   define LMI_BUILD_SO
#endif // defined DLL_EXPORT

but I'd rather conditionalize that on HAVE_CONFIG_H, because
DLL_EXPORT is too obvious a name, and others have used the
same name in ways that conflict with autotools, e.g.:

  
http://herbert.the-little-red-haired-girl.org/en/software/pfi/docs/html/debian_2tmp_2usr_2include_2pfi_8h-source.html
  http://wigner.cped.ornl.gov/hpac/4.1/gpc.h
  http://www.physics.uq.edu.au/people/dawson/matrix/doc/mlapack_8h-source.html
  
http://webster.fh-hagenberg.at/amire/development/documents/html/AMIRE-0.0.1-framework-api/DllSupport_8h-source.html

I wish the autoconf developers had named their macros with more
care. We can't change that, but we can at least guard against the
ensuing problems with HAVE_CONFIG_H.




reply via email to

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