At 11:29 04/06/2005 -0700, you wrote:
I actually have Linux installed on this machine, but for reasons which
I'm not going to get into here I use Win98 for day-to-day computing. I
therefore took it as a challenge to get Parrot to build with crufty ol'
command.com.
I used MinGW 3.1.0-1 and ActivePerl 5.8.6.811 to build Parrot.
I configured Parrot with
perl Configure.pl --cc=gcc --without-icu
I ran into a number of issues while trying to get Parrot to compile.
Problem 1 - If you try to redirect output to paths containing forward
slashes, command.com will complain (and not create the file).
Solution 1 - Configure the build system to use backslashes in Makefiles.
This functionality already exists, but was not fully enabled. I also
changed a few Perl scripts to use the 'slash' configuration parameter
instead of hard-coded forward slashes, and to perform variable
substitution before slash substitution.
I work with MinGW, ActivePerl & cmd.exe.
I introduced the configuration variable slash_exec.
On all platform 'slash' == 'slash_exec'
except with MinGW where :
slash => '/' (need by mingw32-make)
'slash_exec' => '\' (need by exec(2), cmd.exe)
Problem 2 - Redirecting output of a batch file does not redirect output
of the commands executed by it. The perldoc command supplied with
ActivePerl is a batch file.
Solution 2 - Use a command line switch to send perldoc's output to a
file instead of redirection.
Problem 3 - The value of $(MAKE) supplied by mingw32-make contains
forward slashes. This doesn't sit well with command.com.
Solution 3 - Override $(MAKE).
Problem 4 - Single backslashes in C strings are a no-no. This manifests
itself when filenames are inserted into the #line directives in
generated C code.
Solution 4 - Substitute double backslashes for single backslashes in
#line directives.
I include a patch I made for the above problems. Some of the changes are
kind of kludgey, so I would appreciate comments and suggestions on how to
improve them.
I still haven't gotten compilation to finish, but it's a lot further
along than when I started. Currently, it fails with a zillion "undefined
reference" errors on the command
On Win32, the linking of all dynclasses doesn't work.
So, I think you are near the end.
Try this special Win32 patch :
Index: config/gen/makefiles/dynclasses.in
===================================================================
--- config/gen/makefiles/dynclasses.in (revision 8281)
+++ config/gen/makefiles/dynclasses.in (working copy)
@@ -44,8 +44,8 @@
all :
@$(BUILD) generate $(PMCS)
@$(BUILD) compile $(PMCS)
- @$(BUILD) linklibs $(PMCS)
- @$(BUILD) copy "--destination=$(DESTDIR)" $(PMCS)
+# @$(BUILD) linklibs $(PMCS)
+# @$(BUILD) copy "--destination=$(DESTDIR)" $(PMCS)
test : all
cd .. ; perl -Ilib t/harness t/dynclass/*.t
Francois.
g++ -s -g -shared "C:/Users/Clement/src/parrot/parrot/src/extend.o"
-o python_group.dll "lib-python_group.o" "pybuiltin.o" "pyclass.o"
"pyobject.o" "pyboolean.o" "pycomplex.o" "pydict.o" "pyexception.o"
"pyfloat.o" "pyfunc.o" "pyboundmeth.o" "pyboundcall.o" "pynci.o"
"pystaticmeth.o" "pygen.o" "pyint.o" "pylist.o" "pylong.o" "pymodule.o"
"pynone.o" "pytype.o" "pyslice.o" "pystring.o" "pytuple.o"
"pyproxytype.o" "pyproxyclass.o" "pyiter.o"
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x306): In
function `Parrot_PMC_get_cstring_intkey':
C:/Users/Clement/src/parrot/parrot/src/extend.c:256: undefined reference
to `string_to_cstring'
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x363): In
function `Parrot_PMC_get_cstring':
C:/Users/Clement/src/parrot/parrot/src/extend.c:276: undefined reference
to `string_to_cstring'
C:/Users/Clement/src/parrot/parrot/src/extend.o(.text+0x3c6): In
function `Parrot_PMC_get_cstringn':
C:/Users/Clement/src/parrot/parrot/src/extend.c:299: undefined reference
to `string_to_cstring'
