Hi
I am trying to walk through the examples of perlXstut infact hello world!
I eventually was able to run the xsub(after building perl from its source
rather than using the activestate installer) and succesfully obtain the results
but when i tried to modify the XS to add a new routine it (odd even sample) it
broke again
one curious change i notice now is the way it searches for my dll
Can't load 'C:\newext\blib\arch/auto/newext/newext.dll'
this was earlier 'C:\newext\blib\arch\auto\newextnewext.dll' and have no clue
what propogated this change
This error continues even after reverting back to the hello world example -
My XS file looks like this.
#include "EXTERN.h"
#include "perl.h"
#include "XSUB.h"
#include "ppport.h"
MODULE = newext PACKAGE = newext
void
hello()
CODE:
printf("Hello world");
Would be glad if i get some insight into this strange behaviour.
Sisyphus <[EMAIL PROTECTED]> wrote:
----- Original Message -----
From: prashanth paramanandan
> Firstly about the "nmake test" - it too has the same issue wherein it
> cannot load the dll generated
I'm wondering whether COREdll.dll is a dll you need when you use Visual
Studio 8.0 . Perhaps someone can confirm that it *is* needed by Visual
Studio 8 ... or that it's *not* needed. (I certainly don't know.)
Could it be something in your XS code that's creating the need for
COREdll.dll ?
If you're simply working through the perlxstut examples, then the answer to
that question is probably "No". (Which perlxstut example is giving the
problem ?)
Otherwise, it might be a good idea to show us the XS code. (In fact, it
wouldn't hurt to provide that XS code, anyway.)
As an alternative to the Visual Studio 8 compiler, (assuming you have
ActiveState build 817 or later) you could use the freely available MinGW
compiler - I would recommend doing that ahead of using Visual Studio 8 (as
you'll probably get better milage, less bugs and less frustration). If you
do that, you just need to make sure that the MinGW\bin folder occurs in your
path before the Visual Studio bin folder. One would usually use dmake
(freely available from CPAN) with the MinGW compiler, but I think it should
also be fine with nmake.
With MinGW installed, and the path amended appropriately, running
'perl -V:cc' should produce something very similar to:
Set up gcc environment - 3.4.4 (mingw special)
cc='gcc';
If it still tells you that cc is 'cl', then you haven't configured things
correctly, and Visual Studio 8 is still being found as the compiler.
Cheers,
Rob
---------------------------------
Access over 1 million songs - Yahoo! Music Unlimited._______________________________________________
Perl-Win32-Users mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
