p5pRT
commented
24 years ago 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
Migrated from rt.perl.org#2088 (status was 'resolved')
Searchable as RT2088$