Re: Building Parrot with MinGW, ActivePerl & command.com
Jens Rieks
> 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 have a Win98 installation, too. (But I use it only for testing...)
I noticed the problems you describe, but had no time to fix them yet.
So, thanks for that patch, I'll have a look at it this week (or, maybe at the
begin of the next week).
jens
François PERRAD
>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 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'
Andy Dougherty
> 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)
For those who follow, could you please include a specific definition
comment inside config/init/data.pl defining those two terms and when
to use (or not use) them?
--
Andy Dougherty doug...@lafayette.edu
Jens Rieks
> kind of kludgey, so I would appreciate comments and suggestions on how to
> improve them.
jens
Nick Glencross
> 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
>
> -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'
>
>
I've been working on getting dynclasses working on Cygwin. I've made
some changes to build_tools/build_dynclasses.pl (or strictly speaking
the file from which it is generated), and can now build dynclasses.
My understand is that on Windows DLLs must be self-contained and cannot
have unreferenced symbols, and so I've linked against libparrot.so which
of course pulls in much of its code. I see this also being done in the
MSWin32 case...
However... now for the bit I don't understand. Globals are now going to
exist in both the executable and another copy in the dynamically loaded
library. How does this usually get resolved?
At the moment I get a segfault in get_new_pmc_header in pmc.c when it
tried to access the wrong copy of the global Parrot_base_vtable which
hasn't been initialised (the code path is that loadlibs loads foo.dll
which in its load callback it calls pmc_new which eventually gets to
this routine).
Do dynclasses work with Windows or MinGW, or is this something that's
going to be a general problem on Windows?
Cheers,
Nick
p.s. Leo: Like HP-UX, cygwin also seems to require execute permissions
on the libraries in runtime/parrot/dynext/ for them to be dlopened
Nick Glencross
> My understand is that on Windows DLLs must be self-contained and cannot
> have unreferenced symbols, and so I've linked against libparrot.so which
> of course pulls in much of its code. I see this also being done in the
> MSWin32 case...
Sorry, I typed libparrot.so when what I really meant was libparrot.a.
I thought I'd also include the changes that I've made for cygwin as I've
reordered the link line so that libraries (in particular libgdbm) are
nearer the end of the line. [I'll submit it offically when I've actually
got more things working!]
Nick
Matt Diephouse
> +# Here comes some stuff for Cygwin
> +if ($^O eq 'cygwin') {
> + $LD_LOAD_FLAGS .= ' ../src/parrot_config.o';
> + $LIBPARROT = qq[-L../blib/lib -lparrot];
> +}
Make sure this patch will work to make Tcl too (languages/tcl/), which
has PMCs inside of its classes/ directory. Using relative paths will
probably not work (Tcl is two directories deeper). Instead, use
${build_dir} to get the root parrot directory and build your paths
from there.
Thanks.
--
matt diephouse
http://matt.diephouse.com
Nick Glencross
Good advice. Yea, quick hack to see what problems lay in wait once I got
dynclasses compiled...
Nick
Ron Blaschke
> My understand is that on Windows DLLs must be self-contained and cannot
> have unreferenced symbols, and so I've linked against libparrot.so which
> of course pulls in much of its code. I see this also being done in the
> MSWin32 case...
Yes, Windows needs to know where the missing symbols come from. Isn't
that the case on every platform?
> However... now for the bit I don't understand. Globals are now going to
> exist in both the executable and another copy in the dynamically loaded
> library. How does this usually get resolved?
Well, you've got a libparrot.dll. parrot.exe got to be linked against
it, and so have the dynclasses. Once parrot.exe runs, it pulls in
libparrot.dll. If a dynclass gets loaded, it also looks for its
missing symbols from libparrot.dll, and finds them in the already
loaded one.
> At the moment I get a segfault in get_new_pmc_header in pmc.c when it
> tried to access the wrong copy of the global Parrot_base_vtable which
> hasn't been initialised (the code path is that loadlibs loads foo.dll
> which in its load callback it calls pmc_new which eventually gets to
> this routine).
Yes, that's right. The dynclasses rely on an initialized
libparrot.dll. But parrot.exe has its own static version, which is
initialized and used by everything contained in parrot.exe - that is,
everything except the dynclasses. Once a dynclass is loaded, it loads
the libparrot.dll, which is utterly useless, as it is only used
there.
I've discussed this issue previously on this list, implemented a
solution for the Microsoft toolchain (with all dynclasses tests
passing), but the solution got rejected, so I decided to leave it to
someone else.
Ron
Nick Glencross
> Well, you've got a libparrot.dll. parrot.exe got to be linked against
> it, and so have the dynclasses. Once parrot.exe runs, it pulls in
> libparrot.dll. If a dynclass gets loaded, it also looks for its
> missing symbols from libparrot.dll, and finds them in the already
> loaded one.
Ah, right. On cygwin as things stand at the moment I'm only getting a
libparrot.a. I'll see about building the dll to link that dynclasses
against.
Thanks!
Nick
François PERRAD
Please, revert this patch (r8298)
With MinGW & cmd.exe :
$ make test
perl.exe t\harness --gc-debug --running-make-test t\library\*.t
t\op\*.t t\pmc\*.t t\native_pbc\*.t imcc\t\*\*.t t\dynclass\*.t t\src\*.t
t\perl\*.t
FAILED--no tests were run for some reason.
In its initial mail, Clement Cherlin wrote : "I still haven't gotten
compilation to finish ..."
Francois Perrad.
>jens