Jonathan Stowe wrote:
>On Fri, 2005-01-14 at 15:29, Steve Hay wrote:
>
>
>>The only "solution" that I've come up with in cases where sharing CRT
>>resources in this way is unavoidable is to recommend that users use the
>>same compiler to build my modules as was used to build Perl. I don't
>>even have a good way of checking for this, so I just have a note in my
>>INSTALL file to this effect.
>>
>>
>>
>
>In this particular case (building an extension using a different MS C
>compiler than that which built ActivePerl) it would be possible to
>determine the particular build and the version of the C compiler you are
>going to use (either by compiling and running a small program that
>output the value of _MSC_VER or by examining CL.EXE's banner) and then
>exit Makefile.PL with a message if they are incompatible. In the more
>general case it becomes more difficult.
>
>
I guess I'd been trying (and failing) to come up with a more general way
of doing things, but on reflection the check that you suggest would
probably catch most cases that need catching -- anyone not using
ActivePerl on Win32 is quite likely to have built Perl themselves and
would therefore (a) be more aware of this issue in the first place, and
(b) be likely to use the same compiler to build their modules anyway.
>
>
>>If anyone has any better solutions, I'd love to hear them!
>>
>>
>>
>
>In principle would it be possible to determine the compiler and/or CRT
>version at configure time and make that available to test in cases like
>this?
>
Yes, $Config{[g]ccversion} should really hold the compiler version, but
currently doesn't. I can fix that fairly easily for cl and gcc. (I
don't know about Borland's compiler.)
This well help in the future, so is worth doing, but clearly doesn't
help in spotting conflicts in existing Perls which are out there :(
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
