From jon@symas.com

My company has been working with the Perl 5.00503 distribution for the last
few months, and it has been my responsibility to get the distribution
integrated into Windows NT.

I work on a product that interacts with Perl in C, via the Perl shared
library. Furthermore, the product that I work on compiles Mingw32 binaries in
a Cygwin BASH shell environment. To produce the binaries, I use Cygwin's gcc
compiler with the -mno-cygwin switch.

When it came to building Perl, I wanted to build Mingw32 binaries, but the
process was a bit too complex. As far as I could tell, I was going to have to
build with the Mingw32-native gcc compiler, and that would have been an
entirely different environment for me to set up.

As a workaround, I compiled Perl with MSVC. Once I did this, I was able to
take the set of exported symbols from the PERL.DLL file and create a
gcc-compatible import library. This process works just fine, and I'm quite
satisfied with the solution.

However, in order for me to compile (and successfully execute) external
Mingw32 binaries that link with my gcc-compatible import library (and hence
PERL.DLL), I found it necessary to change two header files in the Perl
distribution. Here are the patches with explanations​:

Index​: EXTERN.h

RCS file​: /var/CVSROOT/perl5/EXTERN.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- EXTERN.h 1999/11/08 19​:49​:08 1.1
+++ EXTERN.h 2000/01/23 02​:57​:31 1.2
@​@​ -27,7 +27,7 @​@​
# define EXTCONST globalref
# define dEXTCONST globaldef {"$GLOBAL_RO_VARS"} readonly
#else
-# if defined(WIN32) && !defined(PERL_STATIC_SYMS) && !defined(__GNUC__) &&
!de
fined(PERL_OBJECT)
+# if defined(WIN32) && !defined(PERL_STATIC_SYMS) && !defined(PERL_OBJECT)
&&
(!defined(__GNUC__) || defined(__MINGW32__))
# ifdef PERLDLL
# define EXT extern __declspec(dllexport)
# define dEXT
# define EXTCONST extern __declspec(dllexport) const
# define dEXTCONST const
# else
# define EXT extern __declspec(dllimport)
# define dEXT
# define EXTCONST extern __declspec(dllimport) const
# define dEXTCONST const
# endif
# else
# define EXT extern
# define dEXT
# define EXTCONST extern const
# define dEXTCONST const
# endif
#endif

The preprocessing in this file causes the EXT macro to expand to "extern" if
it determines that the __GNUC__ macro is defined. However, when I compile a
program with Mingw32 or Cygwin gcc, the __GNUC__ macro will be defined, and it
will still be quite necessary for the EXT macro to include the
__declspec(dllimport) keywords in its expansion.

The patch that I've supplied fixes my situation. While I look at it now, it
seems to not be a complete solution. It doesn't address the __CYGWIN32__ macro
if the target is a Cygwin binary. Also, I'm actually trying to figure out why
this expansion should be suppressed at all. As long as the WIN32 macro is
defined, we know the platform is Windows, and the __declspec keywords are
usually necessary. I can understand why it might be suppressed if the
PERL_STATIC_SYMS macro is defined (although that's not necessarily clear to
me), but I can't see why there is a dependency on any other macro.

There's also one other issue to note. The resulting config.h file that gets
generated and installed (via MSVC) into a Windows environment contains the
following, starting at line 61​:

/* HASATTRIBUTE​:
* This symbol indicates the C compiler can check for function
attributes,
* such as printf formats. This is normally only supported by GNU cc.
*/
/*#define HASATTRIBUTE /**/
#ifndef HASATTRIBUTE
#define __attribute__(_arg_)
#endif

Unless the external source file that you're compiling defines the HASATTRIBUTE
macro, the __attribute__ macro (which the gcc compiler uses and depends upon
to translate the __declspec keyword) gets redefined, and the resulting
preprocessed source will not contain the __declspec keywords.

I'm not sure what the best solution is for this, but I solved this in my
situation by necessarily defining the HASATTRIBUTE macro before including perl
header files. Perhaps these lines in the header are unnecessary since the gcc
compilers know how to take care of themselves.

Index​: win32.h

RCS file​: /var/CVSROOT/perl5/win32/win32.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- win32.h 1999/11/08 19​:49​:12 1.1
+++ win32.h 2000/01/23 02​:53​:47 1.2
@​@​ -21,7 +21,11 @​@​
# define win32_get_sitelib PerlEnv_sitelib_path
#endif

-#ifdef __GNUC__
+#if defined(__GNUC__) && !defined(__MINGW32__)
typedef long long __int64;
# define Win32_Winsock
/* GCC does not do __declspec() - render it a nop
* and turn on options to avoid importing data
*/
#ifndef __declspec
# define __declspec(x)
#endif
# ifndef PERL_OBJECT
# define PERL_GLOBAL_STRUCT
# define MULTIPLICITY
# endif
#endif

Once again, I ran into a problem where the existence of the __GNUC__ macro
caused the preprocessing to take some undesired actions. If __GNUC__ is
defined (which is is for me), the preprocessing would go ahead and define the
PERL_GLOBAL_STRUCT and MULTIPLICITY macros if the PERL_OBECT macro is not
defined (which was the case for me). I can't understand why these actions are
necessary. If fact, it caused me a lot of grief. It caused my external
binaries to (incorrectly) believe that the shared Perl library contained the
Perl global variables.

As you can see, I once again addressed my particular situation by keeping this
from happening if the __MINW32__ macro is defined. However, I'm sure there's a
better general solution.

=============

If anyone has any questions about these issue, feel free to contact me. I've
clearly left out levels of detail that I'd expect the reader to have context
for.

Jon Leichter
jon@​symas.com

From @gsar

On Thu, 03 Feb 2000 14​:45​:01 PST, "Jon Leichter" wrote​:

[details about using 5.00503 and mingw32]

I think you'll find the GCC support much improved in the development
versions. The support that's in 5.00503 reflects the state of
mingw32 at the time 5.00503 was released. Mingw32 libraries have
improved much since that time, but 5.00503 still makes the old
outdated assumptions about mingw32.

Try v5.5.640 and tell us how it goes.

Sarathy
gsar@​ActiveState.com