Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-14 Thread François PERRAD

At 12:19 10/06/2005 +0200, you wrote:

On Saturday 04 June 2005 20:29, Clement Cherlin wrote:
 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.
Thanks, applied.


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





Linking on Windows (was: Building Parrot with MinGW, ActivePerl command.com)

2005-06-11 Thread Ron Blaschke
Nick Glencross wrote:
 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



Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-10 Thread Jens Rieks
On Saturday 04 June 2005 20:29, Clement Cherlin wrote:
 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.
Thanks, applied.

jens


Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-10 Thread Nick Glencross

Clement Cherlin wrote:

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

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'





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


Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-10 Thread Nick Glencross

Nick Glencross wrote:

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

Index: dynclasses_pl.in
===
--- dynclasses_pl.in(revision 8298)
+++ dynclasses_pl.in(working copy)
@@ -46,6 +46,12 @@
 $LD_LOAD_FLAGS =~ s/(-def:)/$extraLibs $1..\\/;
 }
 
+# Here comes some stuff for Cygwin
+if ($^O eq 'cygwin') {
+$LD_LOAD_FLAGS .= ' ../src/parrot_config.o';
+$LIBPARROT = qq[-L../blib/lib -lparrot];
+}
+
 # PMC2C Config
 our $PMC2C = $PERL $PATHQUOTE . 
q[${build_dir}${slash}build_tools${slash}pmc2c.pl] . $PATHQUOTE;
 
@@ -72,11 +78,12 @@
 }
 
 return
-$LD $LDFLAGS $LD_LOAD_FLAGS $liblist $PATHQUOTE$LIBPARROT$PATHQUOTE .
-${ld_out} . $target .   .
-join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources);
+$LD $LDFLAGS $LD_LOAD_FLAGS -o $target  .
+join( , map {$PATHQUOTE$_$PATHQUOTE} @$sources) .
+ $PATHQUOTE$LIBPARROT$PATHQUOTE $liblist;
 }
 
+
 our $NOW = time();
 
 ### MAIN PROGRAM 


Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-10 Thread Matt Diephouse
Nick Glencross [EMAIL PROTECTED] wrote:
 +# 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


Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-10 Thread Nick Glencross

Matt Diephouse wrote:


Nick Glencross [EMAIL PROTECTED] wrote:


+# 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.


Good advice. Yea, quick hack to see what problems lay in wait once I got 
dynclasses compiled...


Nick


Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-07 Thread François PERRAD

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'





Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-07 Thread Andy Dougherty
On Tue, 7 Jun 2005, [iso-8859-1] François PERRAD wrote:

 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  [EMAIL PROTECTED]

Re: Building Parrot with MinGW, ActivePerl command.com

2005-06-05 Thread Jens Rieks
On Saturday 04 June 2005 20:29, Clement Cherlin 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 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


Building Parrot with MinGW, ActivePerl command.com

2005-06-04 Thread Clement Cherlin

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.


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

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'

...

Index: build_tools/ops2c.pl
===
--- build_tools/ops2c.pl(revision 8268)
+++ build_tools/ops2c.pl(working copy)
@@ -411,7 +411,11 @@
 my $line = 0; while (SOURCE) { $line++; } $line+=2;
 close(SOURCE);
 open(SOURCE, $source) || die Error appending to $source: $!\n;
-print SOURCE qq{#line $line $source\n} unless $nolines_flag;
+unless ($nolines_flag) {
+my $source_escaped = $source;
+$source_escaped =~ s|(\\)|$1$1|g; # escape backslashes
+print SOURCE qq{#line $line $source_escaped\n};
+}
 
 
 #
Index: lib/Parrot/Pmc2c.pm
===
--- lib/Parrot/Pmc2c.pm (revision 8268)
+++ lib/Parrot/Pmc2c.pm (working copy)
@@ -260,7 +260,11 @@
 my ($self, $line, $file) = @_;
 
 return '' if $self-{opt}{nolines};
-return qq{#line $line $file\n} if defined $file;
+if (defined $file) {
+my $file_escaped = $file;
+$file_escaped =~ s|(\\)|$1$1|g; # escape backslashes
+return qq{#line $line $file_escaped\n};
+}
 return qq{#line $line\n};
 }
 
Index: lib/Parrot/Configure/Step.pm
===
--- lib/Parrot/Configure/Step.pm(revision 8268)
+++ lib/Parrot/Configure/Step.pm(working copy)
@@ -223,26 +223,27 @@
 $_ = $2;
 }
 }
+s{
+  \$\{(\w+)\}
+}{
+  if(defined(my $val=Configure::Data-get($1))) {
+#use Data::Dumper;warn Dumper(val for $1 is ,$val);
+$val;
+  }
+  else {
+warn value for '$1' in $source is undef;
+'';
+  }
+}egx;
 if ( $options{replace_slashes} ) {
   s{(/+)}{
-   my $len = length $1;
-   my $slash = Configure::Data-get('slash');
-   '/' x ($len/2) . ($len%2 ? $slash : ''); }eg;
-  }
-  s{
-   \$\{(\w+)\}
-  }{
-   if(defined(my $val=Configure::Data-get($1))) {
-  #use Data::Dumper;warn Dumper(val for $1 is ,$val);
- $val;
-   }
-   else {
- warn value for '$1' in