libtool-patches
[Top][All Lists]
Advanced

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

Re: [PATCH] tests: import variables for MSVC.


From: Charles Wilson
Subject: Re: [PATCH] tests: import variables for MSVC.
Date: Fri, 24 Sep 2010 13:30:25 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666

On 9/23/2010 6:25 PM, Peter Rosin wrote:
> I don't know how to set up the defines so that EXTERN becomes
> 
> 1. "extern" when you use a static library
> 2. "extern" when you build a static library
> 3. "extern declspec(dllimport)" when you use a shared library
> 4. "extern declspec(dllexport)" when you build a shared library
> 
> I could fix 2 and 4, but separating 1 and 3 is not possible. Since
> extern declspec(dllimport) works everywhere with MSVC I'm taking the
> easy option with this patch.
> 
> Or should I add -DBUILDING_FOO to Makefile.am and variations of the below
> to the code?

That is the typical approach.  The drawback -- usually an acceptable one
-- is that if you are building a "stack" of dependent DLLs:

EXE --> C.DLL -> B.DLL
    --> A.DLL

Then (a) you must link exe using .obj's compiled as pic (e.g. with
-DDLL_EXPORT, even tho the EXE *itself* is not a "shared library").
libtool does this by default IIRC.  (b) You MUST link EXE against shared
C.DLL and shared A.DLL; you can't link against static C.lib and B.lib,
but dynamic A.DLL, or vice versa (because DLL_EXPORT, for EXE's objs,
either IS, or IS NOT, defined).

We already enforce the restriction that C.DLL can't depend on B.lib, so
that "complication" is a non-issue.

> #ifdef _MSC_VER
> # ifdef BUILDING_FOO
> #  ifdef DLL_EXPORT
> #   define EXTERN extern declspec(dllexport)
> #  endif
> # else
> #  define EXTERN extern declspec(dllimport)
> # endif
> #endif
> #ifndef EXTERN
> # define EXTERN extern
> #endif

More indepth review against your revised version.

--
Chuck



reply via email to

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