[Top][All Lists]
[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.