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

[Ralf Wildenhues]

Hi Peter, Charles,

* Peter Rosin wrote on Thu, Jul 15, 2010 at 10:39:42PM CEST:
> Den 2010-07-12 07:46 skrev Ralf Wildenhues:
> >* Peter Rosin wrote on Sat, Jul 10, 2010 at 10:15:09AM CEST:
> >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.
> 
> This is nothing new. It is the same situation that applied to GNU on
> Windows before auto-import, I think. I'm quoting this off-list
> conversation with Chuck (off-list due to some misunderstanding) that
> describes the situation quite well:

Thanks for reproducing this, it is quite enlightening, and I'm afraid I
really had forgotten most of this again since a couple of years ago.

[...]
> The above implies that you need to select one way to do this universally
> for "my target", but I don't think that you need to do the same everywhere.
> So, I just just the method that cleared up the test case in the least
> intrusive way I could think of.

OK.  The patch is fine with me then.

> [back to Ralf's message]
> 
> >Is that documentation step hidden somewhere in your queue already, or
> >does that still need to be done?
> 
> It is not hidden in my queue, so it is a TODO.

OK.  Do we need to remember it somewhere (e.g., in TODO, exept that
this is hopelessly outdated)?

> I didn't think the onus
> was on me to write this as it has been a known issue on Windows for a
> long time (I was just temporarily fooled that it was a non-issue with
> MSVC when I misguidedly thought you could always dllimport with it).

I didn't mean to imply that the onus is on you.  Just that it needs to
be done.

> The manual already says that it is not portable to export data items from
> a libtool library. At least I think it does.

The "Library tips" nodes has a bit.

Cheers, and thanks,
Ralf