Re: MSVC: Always dllimport the variable for MSVC in link-order.at

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Sat, Jul 10, 2010 at 10:15:09AM CEST:
> Next in to MSVC queue...
> 
> This is a variation of
> 95bdbc456f7c5d6d669121cf20d62a9c28bec2bf
> "Always dllimport the variable for MSVC in link-order.at"
> 
> Patch previously discussed here:
> http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00053.html
> 
> In that discussion I claim that "With MSVC, you can declare any variable
> with __decspec(dllimport), even if you are not actually importing it"
> and I must have been thoroughly confused when I arrived at that
> conclusion. It doesn't hold when I now try it...
> 
> So, instead of just "#ifdef _MSC_VER", this version does
> #if defined _MSC_VER && defined PIC
> #  define LIBCEE_SCOPE __declspec(dllimport)
> 
> Now, the PIC part isn't truly what we want to test for, since we don't
> really want to dllimport when we a *building* a PIC library. We want
> to dllimport when we *use* a shared library. But in this case it happens
> to coincide, and the notion of using a shared vs. static library isn't
> really covered by libtool, i.e. there's no -DUSE_PIC or equivalent that
> can be used to discriminate in the code.

the patch looks fairly innocent at first sight, but your description
makes me wonder how a user is going to get that right.  In fact, I don't
see how we *can* get that right as the preferred form of linking (static
or shared) might not yet be known at compile time at all.  So I guess
the only viable route is to document the limitation somewhere, and tell
developers and users what to do and expect in face of it.

Is that documentation step hidden somewhere in your queue already, or
does that still need to be done?

Thanks,
Ralf

> 2010-07-10  Peter Rosin  <address@hidden>
> 
>        dllimport the variable for MSVC in link-order.at
>        * tests/link-order.at [MSVC]: Makes the test pass by dllimporting
>        imported variables when working with shared libraries.