[Top][All Lists]

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

Re: [patch #6448] [MSVC 7/7] Add MSVC Support

From: Peter Rosin
Subject: Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Date: Sun, 10 Aug 2008 00:05:39 +0200
User-agent: Thunderbird (Windows/20080708)

Peter Rosin skrev:
Ralf Wildenhues skrev:
Hi Peter,

* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
Peter Rosin skrev:
  31:       Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not __declspec(dllimport)ing all
these variables?

Yes: the auto-dll-import feature (was it named that?) from GCC on Cygwin
and MinGW is happy to import all these variables automatically.

I would like to somehow ensure that we expose this auto-import feature;
IOW, that we don't explicitly dllimport these variables.  That way code
that is not portable to MSVC anyway, can rely on not needing these
annotations.  Sorry to be such a pain on this point, but the GNU Coding
Standards explicitly allow developers to not go out of their way in
making stuff work on w32, and as such they come to expect that things
work smoothly without these kinds of annotations (and I for one would
like to be able to pinpoint where exactly the limits are).

So can we do something like this in the test, what do you think?

/* w32 fun.  With GCC, you can have auto-import, which will work for
 * functions and non-const variables.  With MSVC, you have to explicitly
 * import all variables.  Depending on the amount of portability, you
 * need these annotations: LIBA_SCOPE for GCC, and also LIBA_SCOPE_VAR
 * for MSVC.  Of course you can merge both to one, this test only avoids
 * that in order to expose the auto-import feature on Cygwin.
 * For users, it's best tor realize that they should not provide any
 * non-function API at all.
#if defined(LIBA_DLL_IMPORT)
#  if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__)
#    define LIBA_SCOPE extern __declspec(dllimport)
#  if defined(_MSVC)
#  endif
#  endif
#if !defined(LIBA_SCOPE)
#  define LIBA_SCOPE extern
#if !defined(LIBA_SCOPE_VAR)
#  define LIBA_SCOPE_VAR extern

and then add only LIBA_SCOPE_VAR annotations?  If you agree, then
a patch to the pr-msvc-support branch to this end is preapproved
(you know how to push changes to a branch?)

I'm sure I can read up on that in a number of git resources on the
web. Is there anything I should be aware of that is special for
libtool? But feel free to recommended a git tutorial...

Ok, managed to push this patch. I think anyway...

I haven't yet decided for myself whether I would like to see this
split-up in the other test failures too, but I would definitely like
to see it in  Maybe in too, but not in the
old-style testsuite.  I'm open to suggestions here though.

dllimport is only needed on variables, functions work just fine to
import on MSVC as well (at least I think so). So the naming
LIBA_SCOPE and LIBA_SCOPE_VAR is perhaps a bit misleading since they
are both used for variables. Also, in what cases do you need the
dllimport for gcc? I don't seen any pattern. Sure, const seems to
be involved, but if not dllimporting variables doesn't always work,
isn't it a support nightmare to only recommend dllimport when it's
desperately needed?

I was confused by const char v8[] which is apparently dll-auto-imported
by gcc even if it's const.

Oh well, I thought a bit about it and you can view it as if LIBA_SCOPE_VAR
is used for variables that truely are variable (i.e. non-const).

Please let me know if I got anything wrong in the push.


reply via email to

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