----- Original Message -----
From: "Jan Dubois" <[EMAIL PROTECTED]>
.
.
>
> Well, let me correct a little what I said: We do link against perl58.lib,
not
> against perl58.dll.
Didn't occur to me that gcc would find perl58.lib acceptable - even though I
have in the past linked gcc against Visual Studio import libs. (I've also
from time to time tried to link cl against gcc import libs - but that has
never worked.)
>You can only link against an import library and not directly
> against the dll.
With gcc (but not VC++) you can usually link against the dll - no need for
an import lib. You can test that out by renaming/removing the perl import
lib, setting $Config{libperl} to 'perl58.dll' and placing a copy of
'perl58.dll' in 'perl/lib/CORE'. Modules still build fine with gcc. (At
least the one I tested did - namely Math::FFT.) I've also frequently linked
gcc directly to other dll's in a non-perl environment.
> This is true for VC++ as well. It just seems like perl58.lib
> is working fine with at least the latest version of MinGW, so we decided
not to
> bother with creating a redundant libperl.a.
>
I fired off an email to Mattia Barbon to find out why he has EU::FC build a
libperl58.a. He replied that older versions of gcc such as 2.95.2-1 (which
was what he was using when he first created EU::FC) are unable to link to VC
import libs. He still has it build libperl58.a because he has not felt the
need to change that behaviour .... which is fair enough.
> >
> > Building with MinGW/dmake and AS build 815 doesn't quite work, however.
> > Compilation fails early on because an inappropriate 'pdl.h' gets
created. It
> > contains the line:
> >
> > typedef __int64 PDL_LongLong;
>
> You can probably fix this yourself by providing additional compiler
> overrides in site/lib/ActivePerl/Config.pm for "i64type", "u64type",
> "quadtype" and "uquadtype". This would be preferable to modifying
> pdl.h.PL.
>
That would work for this machine, but I'm more interested in having PDL
buildable (straight out of the box) on *all* Win32 machines. When building
PDL, many of the source files get created on the fly by the running of perl
scripts. Many of those scripts query %Config - eg one of those scripts has a
subroutine that returns $Config{i64type} (and hence the problem quoted
above). If I'm running AS build 815 and VC++, then there's no problem. But
if I'm running AS build 815 and MinGW that subroutine still returns
'__int64' instead of 'long long'. One solution would be to modify any of
the scripts that are affected by this, so that they firstly detect that some
%Config values need to be overwritten, and that they secondly go ahead and
change those %Config values appropriately.
Current instructions for building PDL (using MinGW) on MSVC-built perl
incorporate the use of ExtUtils::FakeConfig. I wonder whether
ExtUtils::FakeConfig would work nicely with build 815. If so, then I could
just let the same build instructions stand ..... and not have to change
anything.
In any case, since it's planned that this issue is going to be fixed with
the release of build 816, I don't plan on getting too worried about it :-)
Cheers,
Rob
_______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
