Please send me a patch with what you needed to change in order to get it to work on Windows and I'll integrate it.

preferably against the git repo http://github.com/claesjac/javascript.git

Cheers,
Claes

To be honest I have no idea how to make patch. :( I'm pretty much a noob at perl and programming in general.

I really don't think I changed much though. I was still running into problems with the makefile.pl. Then I just decided to use the PPM shell and typed install JavaScript and that worked. I can now use the module in perl. I don't think anything I did before was a contributing factor to whether or not the Javascript.pm from the repository worked..

Either way, the only changes I made anywhere was in Makefile.PL. The first thing I did was set the JS_INC and JS_LIB keys in the ENV hash to the correct directories. I did this by just assigning them a string value of the correct directories, so ...

$ENV{JS_INC} =  "C:\\strawberry\\js\\src";
$ENV{JS_LIB} =  "C:\\strawberry\\js\\src\\WINNT5.1_OPT.OBJ";
[download]

This "fix" is obviously very specific to my situation, so I don't know if it could help others that use different directories.

Also in this section of the code, I changed $lib="js" to $lib="js32", because my .lib file was called js32.lib.

if (exists $ENV{JS_LIB}) {
    @libs = get_paths($ENV{JS_LIB});
    $ENV{DYLD_LIBRARY_PATH} = $ENV{LD_LIBRARY_PATH} = $ENV{JS_LIB};
    $lib = "js";
}
[download]

After that, the makefile.pl would give the correct gcc command with the correct directories, but now it would return a ton of compiling errors. and the first error was something like this:

C:\strawberry\cpan\build\JavaScript-1.12-mJTECJ>makefile.pl
In file included from C:/strawberry/js/src/jspubtd.h:45,
                 from C:/strawberry/js/src/jsapi.h:47,
                 from JavaScript_Env.h:10,
                 from test_js.c:2:
C:/strawberry/js/src/jstypes.h:248:6: #error "Must define one of XP_BE
+OS, XP_OS2, XP_WIN or XP_UNIX"
C:/strawberry/js/src/jstypes.h:264:2: #error No suitable type for JSIn
+t8/JSUint8
C:/strawberry/js/src/jstypes.h:277:2: #error No suitable type for JSIn
+t16/JSUint16
C:/strawberry/js/src/jstypes.h:297:2: #error No suitable type for JSIn
+t32/JSUint32
[download]

It was asking for XP_BEOS, XP_OS2, XP_WIN or XP_UNIX, and I saw that JavaScript_Env.h had a line that said

#define XP_PC

So I edited the Makefile.pl again so that it would now ouput 'XP_WIN' in place of 'XP_PC' to the .h file. This would no longer generate a super long list of compiling errors. Instead it started returning this:

C:\strawberry\cpan\build\JavaScript-1.12-mJTECJ>makefile.pl
C:\DOCUME~1\Steve\LOCALS~1\Temp/ccQm7OVj.o:test_js.c:(.text+0x2b): und
+efined ref
erence to `JS_GetImplementationVersion'
collect2: ld returned 1 exit status
Failed compiling test_js.c. ABORTING
[download]

Those are the only changes I made. If I try to run makefile.pl now, I still get that message. I don't know what causes it or how to fix it. I'm doing this all in the cpan/build folder where cpan downloads the Makefile and other module components.

The 'undefined reference' means that the library that resolves that symbol has not been located.
In the Makefile.PL there's a line:

my $cc = join(" ", $Config{cc}, $libs, @ccflags, "-l${lib}", "-o", $ex
+e, (map { "-I$_" } @incs), "test_js.c");
[download]

It would be helpful if you could insert a print "$cc\n"; into that Makefile.PL and re-run it again so we can see just what that command ($cc) actually is.
I think that ${lib} in the above command is set to 'js', so 'libjs.a' or 'js.a' or 'js.lib' needs to be found. Is there such a file in in $ENV{JS_LIB} ?

Cheers,
Rob

diff -ruN old new > patch


diff -u pp.c~             pp.c             >  patch
diff -u t/op/pack.t~ t/op/pack.t           >> patch
diff -u pod/perlfunc.pod~ pod/perlfunc.pod >> patch

# to apply run 
#  patch -p1 -N <  patch
[download]

If running diff -ruN olddir newwdir > patch, its probably wise to make clean (or make realclean) first (results in smaller patches :D).

http://perldoc.perl.org/perlhack.html#Submitting-patches http://perldoc.perl.org/perlhack.html#Patching

Here is patch (git diff > patch)
Read more... patch (4 kB)
XSUB order fixed according to this. test_js order fixed according to this. :nosearch is for bug in activeperl/strawberry/ExtUtils::LibList

This patch will get you up to this linker failure

Read more... link failure (13 kB)
All these undefined reference to _imp_, are present in the *.o files, and error is because of order of *.o files. I can't figure out the correct order.

please send any patches to claesjac@cpan.org as I don't follow perlmonks

The MinGW was in the "Mozilla Build 1.14" package that I needed to build Spidermonkey. The package also included Perl v 5.6.1, so when I tried to run Makefile.pl in MinGW, it would say that I needed v5.8. I figured this wasn't a big deal though b/c I wanted to install Javascript.pm into the strawberry folder anyway. I guess that little note was irrelevant.

perl -v in MinGW returns 5.6.1
perl -v in the windows command line says 5.10.0

Looking at makefile.pl, it creates a JavaScript_Env.h file. It also creates a test_js.c file which is supposed to do a small compile to see if libs and headers can be located. It then outputs a gcc command to the command line. I think the gcc command is causing a problem. Here is what the gcc command I'm sending looks like:

gcc -LC:\strawberry\js\src\WINNT5.1_OPT.OBJ -ljs32 -o C:\DOCUME~1\Stev
+e\LOCALS~1\Temp\b4to8dFiQI -IC:\strawberry\js\src test_js.c
[download]

dunno if that helps.

gcc -LC:\strawberry\js\src\WINNT5.1_OPT.OBJ -ljs32 -o C:\DOCUME~1\Steve\LOCALS~1\Temp\b4to8dFiQI -IC:\strawberry\js\src test_js.c

Should not produce the error you're getting - assuming that the import library identified by '-ljs32' exists in C:\strawberry\js\src\WINNT5.1_OPT.OBJ. What filename(s) matching /js32/ do you find in that directory ?

Cheers,
Rob

It sounds like he is trying to build JavaScript from within MSYS (which he used to compile SpiderMonkey). MSYS comes with perl 5.6.1.

MSYS comes with perl 5.6.1

Aaah, yes - MSYS perl is still stuck at 5.6.1.

<waffle>
One often finds that a native Win32 perl (eg ActivePerl or Strawberry Perl) works quite well in the MSYS shell. If perl gets presented with the unix-style MSYS paths (eg /usr/local) then the MSYS perl is needed. Otherwise a native Win32 perl seems to be fine.

I've even found that, to build openssl-0.9.8g in the MSYS shell (which requires that a perl installation be available), the MSYS perl is no good and one *has* to use a native Win32 perl instead.
</waffle>

Cheers,
Rob