Sisyphus <[EMAIL PROTECTED]> writes:
>> My guess is that 'mpz_add' has been #defined to something like
>>
>>     (*FunctionTablePtr->MPXADD)
>>
>> which is a common trick with dynamicaly loaded code.
>>
>> Try just preprocessing the file (dmake GMP.i might work for this??)
>>
>
>D:\gmp-4.1\demos\perl>dmake gmp.i
>dmake.exe:  Error -- Don't know how to make `gmp.i'
>
>Is that what you meant ?

Yes that is what I meant.
So you have to do it the hard way:
  del GMP.o 
  dmake -n GMP.o 
Note the command would be used to compile that it prints with all the -I flags
etc etc.
then add a -E and change -o GMP.o to -o GMP.i 

Then look and see what happens after pre-processing.

>>
>
>Yes, I posted to the GMP list as well, and received similar advice. To
>quote - "Hmm, yep, DLL imported functions don't work in initializers" (with
>gcc). Another option mentioned was to try with a statically-built GMP.
>
>So, with a fresh slate, I ran 'perl makefile.pl' and edited the generated
>makefile to specify 'CC = g++'. That had the desired effect of invoking g++
>instead of gcc, but unfortunately led to parse errors:
>GMP.xs:294: parse error before `{'
>GMP.xs: In function `void class_or_croak(...)':
>GMP.xs:295: parse error before `,'
>GMP.xs:296: parse error before `;'
>dmake.exe:  Error code 1, while making 'GMP.o'
>
>where the relevant code (starting at line 292) is:
>static void
>class_or_croak (SV *sv, classconst char *class)
>{
>  if (! sv_derived_from (sv, class))
>    croak("not type %s", class);
>}

Well know gotcha that - 'class' is a keyword in C++ 
I usually do something like:

perl -pi.old -e "s/\bclass\b/Class/g" GMP.xs

>
>I might just use the msvc-built binaries in my gcc-built perl.
>My reluctance in doing so is that my msvc compiler is non-optimising. Given
>that GMP dll *was* built with an optimising compiler, it may well be
>insignificant whether or not the actual perl module gets built with an
>*optimising* compiler. (Anyone have any thoughts on that aspect ?)
>
>One further question:
>Since gcc, or g++, as the case maybe, is compiling GMP.c (afaik), why is it
>that the errors are being reported in GMP.xs (not the file that's actually
>being compiled) ?

xsubpp puts in #line directives to point you at the right place to change
the file.

>
>I'm sure that I have, in building other modules, received errors pertaining
>to both xs and c files (mostly the xs file,  but sometimes the c file) - but
>I'm just wondering what it is that determines whether the error is going to
>be reported as being in the xs file or the c file.

There are parts of GMP.c which are verbatim stuff. At one time 
I tried to add more #line directives to poing at the boiler-plate 
code in xsubpp itself. Another place code can comefrom is the 
typemap file ...


Reply via email to