Re: gcc __alignof__() surprise
On Sun, May 04, 2014 at 11:26:22AM +0100, Nicholas Clark wrote:
Just for the record:
$ cat sizer.c
#include stdio.h
int main() {
printf( sizeof(long long) = %2u
__alignof__(long long) = %2u\n, (unsigned) sizeof(long long), (unsigned)
__alignof__(long long));
printf( sizeof(struct {long long N;}) = %2u __alignof__(struct
{long long N;}) = %2u\n, (unsigned) sizeof(struct {long long N;}),
(unsigned) __alignof__(struct {long long N;}));
return 0;
}
$ gcc -Wall -o sizer sizer.c
$ ./sizer
sizeof(long long) = 8 __alignof__(long long) =
8
sizeof(struct {long long N;}) = 8 __alignof__(struct {long long N;}) =
4
Yes, this was a surprise.
Yup, this is the x86 ABI. You'll get the same results for 'double'
as well. The relevant gcc flag is -malign-double, but the man page warns:
-malign-double
-mno-align-double
Control whether GCC aligns double, long double, and long long
variables on a two-word boundary or a one-word boundary. Aligning
double variables on a two-word boundary produces code that runs
somewhat faster on a Pentium at the expense of more memory.
On x86-64, -malign-double is enabled by default.
Warning: if you use the -malign-double switch, structures containing
the above types will be aligned differently than the published
application binary interface specifications for the 386 and will
not be binary compatible with structures in code compiled without
that switch.
Sadly, I don't know any way around it.
--
Andy Dougherty dough...@lafayette.edu
Re: static inline probing for MoarVM
On Tue, Feb 18, 2014 at 03:11:01PM +, Nicholas Clark wrote: Andy, is it OK to use your Perl 5 static inline probing code in MoarVM? Absolutely. Please feel free. Perl 5's Configure script is actually public domain on purpose to encourage such sharing, so you needn't ask, though I agree courtesy is almost never inappropriate. It takes the probing C code for static inline from Perl 5's Configure pretty much verbatim, and uses that to determine what to use to get the compiler to generate inline functions that don't also have an external definition. I believe that probing is essential, as the correct magic to use varies with different versions of some compilers, and so attempting to maintain an explicit list is going to be more work than this. You might want to revisit the gcc preferences -- they were designed to allow Perl 5's cflags.SH to add -ansi (or -c89 or something similar) to enforce C89 checking. I don't know if MoarVM wants to embrace that particular constraint. Have the appropriate amount of fun, -- Andy Dougherty dough...@lafayette.edu
Re: More patches for building MoarVM on Solaris
Just following up: This patch, to 3rdparty/dyncall/dynload/dynload_syms_elf.c, is still needed. On Tue, Sep 10, 2013 at 08:51:08AM -0400, Andy Dougherty wrote: On Tue, Sep 10, 2013 at 08:46:53AM -0400, Andy Dougherty wrote: I have attached a new batch of patches to work towards building MoarVM on Solaris 11/x86 with Sun's compiler suite. One additional patch is needed to the 3rdparty/dyncall module, but since that's in a git submodule, I'll send it separately. Here is the patch I used for 3rdparty/dyncall/dynload/dynload_syms_elf.c. Since that's part of a git submodule, git diff didn't pick it up from the main MoarVM directory. I have no idea what protocol here is, so here simply is the patch I used. On Solaris 11, libelf.h only works for _FILE_OFFSET_BITS == 32. Otherwise, it dies with #error large files are not supported by libelf. diff --git a/dynload/dynload_syms_elf.c b/dynload/dynload_syms_elf.c index 07056b1..949fd7e 100644 --- a/dynload/dynload_syms_elf.c +++ b/dynload/dynload_syms_elf.c @@ -37,7 +37,7 @@ #if defined(OS_OpenBSD) # include stdint.h # include elf_abi.h -#elif defined(OS_SunOS) +#elif defined(OS_SunOS) (_FILE_OFFSET_BITS == 32) # include libelf.h #elif defined(OS_BeOS) # include elf32.h -- 1.7.9.2 -- Andy Doughertydough...@lafayette.edu -- Andy Dougherty dough...@lafayette.edu
Re: More patches for building MoarVM on Solaris
On Tue, Sep 10, 2013 at 08:46:53AM -0400, Andy Dougherty wrote: I have attached a new batch of patches to work towards building MoarVM on Solaris 11/x86 with Sun's compiler suite. One additional patch is needed to the 3rdparty/dyncall module, but since that's in a git submodule, I'll send it separately. Here is the patch I used for 3rdparty/dyncall/dynload/dynload_syms_elf.c. Since that's part of a git submodule, git diff didn't pick it up from the main MoarVM directory. I have no idea what protocol here is, so here simply is the patch I used. On Solaris 11, libelf.h only works for _FILE_OFFSET_BITS == 32. Otherwise, it dies with #error large files are not supported by libelf. diff --git a/dynload/dynload_syms_elf.c b/dynload/dynload_syms_elf.c index 07056b1..949fd7e 100644 --- a/dynload/dynload_syms_elf.c +++ b/dynload/dynload_syms_elf.c @@ -37,7 +37,7 @@ #if defined(OS_OpenBSD) # include stdint.h # include elf_abi.h -#elif defined(OS_SunOS) +#elif defined(OS_SunOS) (_FILE_OFFSET_BITS == 32) # include libelf.h #elif defined(OS_BeOS) # include elf32.h -- 1.7.9.2 -- Andy Dougherty dough...@lafayette.edu
Re: Building MoarVM on Solaris
On Sat, Aug 24, 2013 at 12:32:32AM +0200, Gerhard R. wrote: Hi. My other reply to Andy Dougherty is probably still awaiting moderation. However, I did misunderstand his problem with 'mknoisy' when specifying a compiler. The issue he encountered is due to the fact that compilers are associated with default toolchains, so switching to gcc on Solaris will generate a Makefile for GNU make. Ah, I see. You can work around that by providing an explicit override via --toolchain. Well, yes, but there wasn't a 'generic unix' toolchain to fall back on. Next time I give it a go, perhaps I'll write one. Alternatively, you can use --cc instead of --compiler, which does not affect other settings. Yes, but that does not include various other compiler-specific settings, such as warning flags, and there doesn't seem to be any way to override them. I'll take a fresh look again later next week. Thanks for the quick turnaround! -- Andy Dougherty dough...@lafayette.edu
Re: Building MoarVM on Solaris
On Fri, Aug 23, 2013 at 12:45:56AM +0200, Jonathan Worthington wrote: On 8/22/2013 20:00, Andy Dougherty wrote: I have attached an updated set of patches I used to build MoarVM. These worked on both Solaris11/x64 and on OpenBSD 5.3. They also seemed to cause no harm under Linux. The patches were made with git format-patch, but to avoid possible corruption through the mail, I am attaching them. The subjects are: [PATCH 1/5] Remove nonportable conditional commands from Makefile.in [PATCH 2/5] Make the endianness tests more robust. [PATCH 3/5] Fix mismatched types in sprintf in src/core/exceptions.c [PATCH 4/5] Add build/setup.pm section for Solaris with Solaris cc. [PATCH 5/5] Avoid 'make -C'. Use a simple cd instead. Additional details are in the commit messages. Thanks for the patches. I've applied all but [PATCH 2/5] (the endianness handling was changed more radically; hopefully what was done works out OK on Solaris also). Builds fine on Windows with these applied. Thanks. (I suspect my endianness patch would have been more useful for cross-compiling, but I'm certainly not likely to complain about using perl 5's Configure value :-). A fresh pull no longer builds because the linenoise directory is empty. I suspect some git incantations are needed but just haven't made it into the README yet. Nearly-random guessing on my part led to git submodule init git submodule update which seemed to work, but git offers so many ways to do things wrong that I hesitate to make any uninformed recommendations. Also, the new 'mknoisy' stuff incorrectly kicks in whenever I specify a compiler, so I still have to manually delete it from the generated Makefile. Anyway, with those problems avoided, today's version built fine on Solaris 11/amd64. I also got it to build on Solaris/SPARC (big-endian) with gcc. Most of the issues were configuration issues with apr, which I didn't bother trying to solve in any portable way. The only significant patch I have from this is that the old Solaris assembler required a space between -o and the output argument. I think that's pretty portable for the gcc toolchain overall, so I propose the following patch: diff --git a/build/setup.pm b/build/setup.pm index 987671e..e400dab 100755 --- a/build/setup.pm +++ b/build/setup.pm @@ -111,7 +111,7 @@ our %GNU = ( ar = 'ar', ccswitch = '-c', -ccout= '-o', +ccout= '-o ', ccinc= '-I', ccdef= '-D', Thanks again, -- Andy Dougherty dough...@lafayette.edu
Re: Building MoarVM on Solaris
I have attached an updated set of patches I used to build MoarVM.
These worked on both Solaris11/x64 and on OpenBSD 5.3. They also
seemed to cause no harm under Linux.
The patches were made with git format-patch, but to avoid possible
corruption through the mail, I am attaching them. The subjects are:
[PATCH 1/5] Remove nonportable conditional commands from Makefile.in
[PATCH 2/5] Make the endianness tests more robust.
[PATCH 3/5] Fix mismatched types in sprintf in src/core/exceptions.c
[PATCH 4/5] Add build/setup.pm section for Solaris with Solaris cc.
[PATCH 5/5] Avoid 'make -C'. Use a simple cd instead.
Additional details are in the commit messages.
I have not gotten nqp to build yet, but hope to get to that next time.
Thanks,
From ba949b5c8c943147b173ca8f9b324187460f1840 Mon Sep 17 00:00:00 2001
From: Andy Dougherty dough...@lafayette.edu
Date: Thu, 22 Aug 2013 12:33:16 -0400
Subject: [PATCH 1/5] Remove nonportable conditional commands from Makefile.in
Not all makes support conditional IF/ELSE/ENDIF statements.
Specifically, the /usr/bin/make supplied with Solaris 11 does not.
There is probably some more portable way to do what was intended,
but for now I'll just get rid of the problematic lines and move
on to other issues.
---
build/Makefile.in |6 --
1 file changed, 6 deletions(-)
diff --git a/build/Makefile.in b/build/Makefile.in
index 8d0eccf..887ad67 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -10,15 +10,9 @@ NOERR = 2 @nul@
TRACING = 0
NOISY = 0
-@mkifnoisy@
MSG = @:
CMD =
CMDOUT =
-@mkelse@
-MSG = @echo
-CMD = @
-CMDOUT = @nul@
-@mkendif@
CFLAGS= @cflags@ @ccdef@MVM_TRACING=$(TRACING)
CINCLUDES = @ccinc@3rdparty/apr/include \
--
1.7.9.2
From 2f7c44bd565807b093fcc29dffbe0239e4aa92ea Mon Sep 17 00:00:00 2001
From: Andy Dougherty dough...@lafayette.edu
Date: Thu, 22 Aug 2013 12:34:10 -0400
Subject: [PATCH 2/5] Make the endianness tests more robust.
It should be sufficient to test whether the LITTLE_ENDIAN or
BIG_ENDIAN symbols are defined. They might not necessarily
be defined to a value that evaluates to true.
---
build/config.h.in |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/build/config.h.in b/build/config.h.in
index bf98d9b..d06ccaa 100644
--- a/build/config.h.in
+++ b/build/config.h.in
@@ -37,9 +37,9 @@
#elif __BYTE_ORDER__ != __ORDER_LITTLE_ENDIAN__
# error Unsupported endianness
#endif
-# elif _BIG_ENDIAN || __BIG_ENDIAN__
+# elif defined(_BIG_ENDIAN) || defined(__BIG_ENDIAN__)
#define MVM_BIGENDIAN 1
-# elif !(_LITTLE_ENDIAN || __LITTLE_ENDIAN__)
+# elif !(defined(_LITTLE_ENDIAN) || defined(__LITTLE_ENDIAN__))
#error Failed to detect endianness
# endif
#endif
--
1.7.9.2
From 39a108930964237b9f19c9fd993ec47ed71f5ec7 Mon Sep 17 00:00:00 2001
From: Andy Dougherty dough...@lafayette.edu
Date: Thu, 22 Aug 2013 12:39:12 -0400
Subject: [PATCH 3/5] Fix mismatched types in sprintf in src/core/exceptions.c
MVM_string_utf8_encode returns an unsigned char pointer, but
the expression is expecting a signed char pointer. gcc complains,
but continues anyway. The Solaris compiler aborts.
This patch casts the MVM_string_utf8_encode return to (char *),
but somebody who understands the function might be better positioned
to understand whether the MVM function definition itself ought to
be changed instead.
---
src/core/exceptions.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/core/exceptions.c b/src/core/exceptions.c
index f5da820..98063df 100644
--- a/src/core/exceptions.c
+++ b/src/core/exceptions.c
@@ -206,8 +206,8 @@ char * MVM_exception_backtrace_line(MVMThreadContext *tc, MVMFrame *cur_frame, M
op_name,
instr,
instr ? : unknown,
- name ? MVM_string_utf8_encode(tc, name, NULL) : anonymous frame,
- filename ? MVM_string_utf8_encode(tc, filename, NULL) : ephemeral file
+ name ? (char *) MVM_string_utf8_encode(tc, name, NULL) : anonymous frame,
+ filename ? (char *) MVM_string_utf8_encode(tc, filename, NULL) : ephemeral file
);
if (tmp1)
@@ -421,4 +421,4 @@ void MVM_exception_throw_apr_error(MVMThreadContext *tc, apr_status_t code, cons
void MVM_crash_on_error() {
crash_on_error = 1;
-}
\ No newline at end of file
+}
--
1.7.9.2
From fb802b073bed06ab9bec2b300b7692170d74fcd8 Mon Sep 17 00:00:00 2001
From: Andy Dougherty dough...@lafayette.edu
Date: Thu, 22 Aug 2013 12:46:00 -0400
Subject: [PATCH 4/5] Add build/setup.pm section for Solaris with Solaris cc.
This adds a generic 'cc' compiler type, intended as a workable
default if the user does not have gcc installed. It also adds
Solaris-11 specific flags suitable for use with Solaris cc.
I have not tested other Solaris versions, nor have I tested
this with Solaris with gcc installed instead.
---
build/setup.pm | 29 +
1 file changed, 29 insertions(+)
diff --git a/build/setup.pm b/build/setup.pm
index 50eb625..61fd6fc
Re: Building MoarVM on Solaris
On Wed, Jul 24, 2013 at 11:24:25PM +0200, Tobias Leich wrote:
Hi, at one point we are moving from libapr to libuv, so we would have to
check if libuv's build scripts are usable too.
Ah, thank you for that information. I'm glad I asked before investing
any time on apr! I have never used libuv, so I don't really know anything
useful about it.
But what speaks for having our own configure system: What if you already
have libapr/libuv installed with their dev-packages?
Currently, it looks like MoarVM just ignores an installed libapr, so
that's currently not an issue. I didn't know anything about future
plans to change to libuv or to possibly use a previously-installed libuv.
And even if we knew how it was built, we can't be sure that the same
compiler toolchain is installed.
That is basically the same trouble Perl 5 XS modules have. They query
Perl 5's Config in order to get the compiler to build the module,
but often the compiler used to build Perl is not installed, because it
was built by a package maintainer and not by yourself.
So, the question can be too: Do we want to rely on somebody else's
configure that we cant tweak well? What if we want to check the
given system and then want to pass options to libapr's configure?
Understood. I am very familiar with these difficult questions, and don't
have any easy answers. More generally, though, every configuration
system has to start with some defaults somewhere, and I was looking to
understand MoarVM's approach.
For the moment I would love to see a pull request for solaris 11. (I
have a opensolaris 10 32bit somewhere in case it is needed for testing.)
Well, I don't know anything about pull requests, but I've appended
the patch I used below. It's not really suitable for applying since
it assumes the libraries and flags needed key off the toolchain, not
the operating system. (For example, this would likely fail miserably
on AIX.) But it got me a bit further into the build. It eventually
bailed out in nqp-cc/nqp/3rdparty/dyncall/dyncall with
gcc -O3 -fPIC -c dyncall_vector.c -o dyncall_vector.o gmake[2]:
gcc: Command not found
It seems dyncall is hard-wired to expect gcc. That's a battle for
another day.
Anyway, here's what I used to build on Solaris:
diff --git a/build/Config/BuildEnvironment.pm b/build/Config/BuildEnvironment.pm
index 9cfaa6f..39748a6 100644
--- a/build/Config/BuildEnvironment.pm
+++ b/build/Config/BuildEnvironment.pm
@@ -86,6 +86,30 @@ my %TOOLCHAINS = (
ldebug = '-g',
linstrument = '',
},
+ 'cc' =
+{
+# Command names
+cc = 'cc',
+link= 'cc',
+
+# Required flags
+# These would actually differ for different operating systems,
but
+# the config stuff below keys off toolchains, not operating
systems.
+# Fixing that is more involved.
+# These values worked for Solaris 11.
+cmiscflags = '-D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
+lmiscflags = '',
+llibs = '-lpthread -lsendfile -lsocket -lnsl -luuid
-lm',
+
+# Optional settings
+# : What instrumentation is available for CC?
+copt= '-O',
+cdebug = '-g',
+cinstrument = '',
+lopt= '-O',
+ldebug = '-g',
+linstrument = '',
+},
'clang' =
{
# Command names
@@ -201,12 +225,14 @@ sub detect {
%config = %{ $BUILDDEF{ $ostype } };
$config{os} = $^O; # to be generic, one must go with the flow
+my $cc = can_run('cc');
my $gcc = can_run('gcc');
my $clang = can_run('clang');
my $compiler;
$compiler = 'clang' if $clang ( $opts-{clang} || $^O =~
m!^(freebsd|darwin)$! || !$gcc );
$compiler = 'gcc' if !$compiler $gcc;
+$compiler = 'cc'if !$compiler $cc;
return ( excuse = 'No recognized operating system or compiler
found.'. found: $^O)
unless $compiler;
--
Andy Dougherty dough...@lafayette.edu
Building MoarVM on Solaris
[I am sending this to perl6-compiler list because I don't know where else to send it. Apologies if this is the wrong place.] I recently tried to build MoarVM on Solaris 11/x86 with Sun's compiler suite. After cloning moarvm and running 'perl Configure.pl' , I got the following message: Welcome to MoarVM! Checking master build settings OK (debug: YES, optimize: no, instrument: no, clang: no) Trying to figure out how to build on your system ..Sorry, I'm not sure how to build on this platform: No recognized operating system or compiler found. found: solaris FAILED It seems build/Config/BuildEnvironment.pm only knows about a few systems. It was easy enough to hack in a 'cc' block for Solaris to get past that, but I then noticed it went and ran an autoconf configure script down in 3rdparty/apr. I was wondering . . . would it make sense to run apr's configure script first and use those results to help set up Config/BuildEnvironment? That way, MoarVM could avoid building yet another Configure system, and instead could leverage the existing one that it's going to run anyway. -- Andy Dougherty dough...@lafayette.edu
Re: Parrot 2.10.1 released!
On Thu, 18 Nov 2010, Gerd Pokorra wrote: On behalf of the Parrot team, I'm proud to announce Parrot 2.10.1 (bugfix release). Parrot (http://parrot.org/) is a virtual machine aimed at running all dynamic languages. Parrot 2.10.1 is available on Parrot's FTP site, or by following the download instructions at http://parrot.org/download. New in 2.10.1 - This is a bugfix release to run perl Configure.pl without noise from git_describe and SHA1 Thank you for doing this. Incidentally, the actual problem wasn't the noise (for example there's been similar @noinline@ noise for a while). The serious problem is that (if the user has git installed) Configure.pl exits with an error status. This will stop various build tools, such as ones that one might use to make a .deb or .rpm package. Hence building packages is likely to be broken. Unfortunately, there still seems to be an error in the package (some confusion over 2_10_0 vs. 2_10_1). It needs my patch in TT #1856 in order to build. Even after that, rakudo is still unhappy and won't build off an installed parrot-2.10.1 built from the tarball. See TT #1852 for the error messages. I don't know whether rakudo is querying the wrong key for a release or parrot is not supplying the correct key, but it ought to be straightened out. -- Andy Dougherty dough...@lafayette.edu
Re: Build Rakudo with Distutils
On Sun, 28 Mar 2010, Fran?ois Perrad wrote:
2010/3/28 Andy Dougherty dough...@lafayette.edu:
I'm pretty sure this is a recurrence of [perl #66560]. See that ticket
for the diagnosis and fix currently in use in rakudo.
However, it's not at all obvious to me how someone trying to
install rakudo could fix it. At least with a Makefile, it's
often obvious how you can hand-edit the Makefile and try to fix it.
Here, it's not. Looking at the trace at the end, it refers to a file
runtime/parrot/library/distutils.pir which doesn't exist. (It may have
existed in the build directory, but that's not around anymore.) There is
a file distutils.pir in $prefix/lib/2.2.0-dev/library, but editing it
(assuming you have permission) doesn't appear to change anything. I
expect that's because the precompiled distutils.pbc file is loaded
instead.
yes, but you could modify the setup.nqp (line 7)
pir::load_bytecode('distutils.pir');
by this way, you load a distutils.pir file with your alteration.
the attached patch adds the option --no-lines
Thanks. I can verify that if I make a copy of parrot's distutils.pir in
the rakudo directory, apply this patch, and add a leading space, changing
+pmc2c .= --no-lines
to
+pmc2c .= --no-lines
then the rakudo build gets past this step. (It runs out of memory
building src/gen/perl6-actions.pir, but that happens with the plain
Makefile too, and is not relevant to the point at hand.)
Another way to attack the problem is to avoid the chdir(). Specifically,
the problem arises because pmc2c is called from one directory (and #line
directives are generated accordingly) and then chdir() is called, and the
compiler is called from a different directory (at which point the #line
directives are now wrong). In the original RT, I suggested avoiding the
chdir(), but rakudo was doing essentially
cd src/pmc cc -c *.c
and Patrick wanted to avoid having to manually maintain the list that *.c
expanded to. Since setup.nqp appears to manually maintain that list
anyway, it could avoid the cd, which would have avoided the whole problem
to start with.
More broadly, I also thought it worth highlighting how when distutils
doesn't work, it can be difficult for an ordinary user to do anything
about it. This is a portability and support question that the rakudo
folks should consider carefully before deciding what to do.
--
Andy Dougherty dough...@lafayette.edu
Re: Build Rakudo with Distutils
On Fri, 26 Mar 2010, Fran?ois Perrad wrote: Find attached a script 'setup.nqp' for building/testing Rakudo. This library removes the dependences with Makefile various make utilities, and remove the configure step. I tried this with today's parrot (r45243) and rakudo (8f7d293a6ba3a9ce4efea3278c58a5edf0210edc) on OpenSolaris with Sun's compiler. It stopped almost immediately: perl /export/home/doughera/my/parrot/lib/2.2.0-devel/tools/build/pmc2c.pl --c --include /export/home/doughera/my/parrot/src/2.2.0-devel --include /export/home/doughera/my/parrot/src/2.2.0-devel/pmc p6lowlevelsig.pmc PMC has attributes but no auto_attrs or manual_attrs at /export/home/doughera/my/parrot/lib/2.2.0-devel/tools/build/../lib/Parrot/Pmc2c/PMCEmitter.pm line 744. ccache cc -c -o src/pmc/p6lowlevelsig.o -I/export/home/doughera/my/parrot/include/2.2.0-devel -I/export/home/doughera/my/parrot/include/2.2.0-devel/pmc -I/export/home/doughera/src/parrot/rakudo -DHASATTRIBUTE_CONST -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DDISABLE_GC_DEBUG=1 -DNDEBUG -DHAS_GETTEXT -I /export/home/doughera/my/icu//include -KPIC-DHAVE_COMPUTED_GOTO src/pmc/p6lowlevelsig.c ./p6lowlevelsig.pmc, line 24: cannot find include file: ../binder/bind.h [and then a cascade of C errors based on that one, followed by the following odd error message at the end] current instr.: 'setup' pc 766 (runtime/parrot/library/distutils.pir:337) called from Sub 'MAIN' pc 236 (EVAL_1:0) called from Sub '_block11' pc 0 (EVAL_1:5) called from Sub 'parrot;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1) called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1318 (compilers/pct/src/PCT/HLLCompiler.pir:714) called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1504 (compilers/pct/src/PCT/HLLCompiler.pir:801) called from Sub 'parrot;NQP;Compiler;main' pc -1 ((unknown file):-1) I'm pretty sure this is a recurrence of [perl #66560]. See that ticket for the diagnosis and fix currently in use in rakudo. However, it's not at all obvious to me how someone trying to install rakudo could fix it. At least with a Makefile, it's often obvious how you can hand-edit the Makefile and try to fix it. Here, it's not. Looking at the trace at the end, it refers to a file runtime/parrot/library/distutils.pir which doesn't exist. (It may have existed in the build directory, but that's not around anymore.) There is a file distutils.pir in $prefix/lib/2.2.0-dev/library, but editing it (assuming you have permission) doesn't appear to change anything. I expect that's because the precompiled distutils.pbc file is loaded instead. -- Andy Dougherty dough...@lafayette.edu
Re: [perl #69466] [BUG] On OpenSolaris log(-Inf) depends on the compiler
On Tue, 29 Sep 2009, Carlin Bingham wrote: On OpenSolaris using Rakudo with a Parrot that was compiled with SunStudio CC: say log(-Inf) NaN say log10(-Inf) NaN On OpenSolaris using Rakudo with a Parrot that was compiled with gcc (both 3.4.3 and 4.3.2): say log(-Inf) -Inf say log10(-Inf) -Inf As I have no idea what is happening there, I'm not sure if this is a Rakudo bug, Parrot bug, OpenSolaris bug or GCC bug so apologise if this isn't a problem with Rakudo. This may be related to the -xlibmieee flag. See parrot/config/init/hints/solaris.pm for details. You can also see a long discussion (Solaris-specific stuff is at the end) at http://rt.perl.org/rt3//Public/Bug/Display.html?id=34549 -- Andy Dougherty dough...@lafayette.edu
[perl #66558] Re: $(LD_OUT) can't have a space after it for MS linking.
The problem on Solaris 8 is fixed in the ins2 branch by commit 69c123146f851c28fb562ca0b217c01d4610ed26 Author: pmichaud pmich...@pobox.com Date: Fri Jul 24 21:58:07 2009 -0500 Clean up compiler flags for certain compilers (RT #66558) Patch courtesy Andy Dougherty dough...@lafayette.edu .
[perl #66560] #line directives in src/pmc confuse Sun's compiler.
Omitting the line numbers worked. This is fixed in the ins2 branch by commit 5d8fc611d2b9b7eacd506f94771b5ba0f7ed8200 Author: pmichaud pmich...@pobox.com Date: Wed Jul 29 14:53:02 2009 -0500 Don't generate #line directives in pmc2c output (for Sun compilers). See RT #66560 (suggestion courtesy Andy Dougherty).
Re: [perl #66560] #line directives in src/pmc confuse Sun's compiler.
On Wed, 29 Jul 2009, Patrick R. Michaud via RT wrote: Yes, it's still there. It's the 'cd' at the beginning of this line: cd $(PMC_DIR) $(CC) -c $(CINCLUDES) $(CFLAGS) *.c If memory serves, parrot doesn't change directories like that. Instead, it sets the output location directly, with something like $(CC) -c $(CINCLUDES) $(CFLAGS) -o src/pmc/p6invocation.o src/pmc/p6invocation.c That's a bit of a pain, isn't it? It means we have to explicitly list every .c file generated from the *.pmc files explicitly in the Makefile, instead of just using *.c . Yes, it's a bit of a pain. (Though reasonably automated.) I wonder if it would be easier to convince the parrot tool to stop emitting the line numbers. I vaguely recall that at one time, at least one of the scripts had an option to do that. -- Andy Dougherty dough...@lafayette.edu
Re: [perl #66558] Re: $(LD_OUT) can't have a space after it for MS linking.
On Wed, 29 Jul 2009, Patrick R. Michaud via RT wrote: On Mon, Jul 27, 2009 at 11:56:14AM -0700, Andy Dougherty via RT wrote: On Fri, 24 Jul 2009, Patrick R. Michaud via RT wrote: I've started a new branch (ins2) based on a more recent Rakudo and the latest Parrot release (1.4.0), and incorporated this patch there. Let me know if it works better on MS and Solaris than what we had before. Yes, I think that fixes the space problem for Solaris, and, as far as I am concerned, this ticket may be closed. Unfortunately, I've been unable to test it. Building parrot with Sun's compiler fails (TT #652). I was able to build parrot with gcc, but the rakudo build got stuck on the second step, running nqp.pbc against src/parser/actions.pm. After 3 and a half hours, it still hadn't produced any obvious output. The system was swapping like mad, and I had to kill the process so I could get other work done. Is Rakudo trunk able to build on Solaris, or is it just the 'ins2' branch that is giving difficulty? I don't know for sure, but I'd expect trunk to behave similarly. That particular system doesn't have a lot of RAM, and rakudo has always been difficult to build. I don't think it's anything relevant for the ins2 branch. -- Andy Dougherty dough...@lafayette.edu
Re: [perl #66560] #line directives in src/pmc confuse Sun's compiler.
On Fri, 24 Jul 2009, Patrick R. Michaud via RT wrote: On Fri Jun 12 13:42:59 2009, doughera wrote: Trying a build with the rakudo ins branch today on OpenSolaris/x86 with Sun's compiler, I hit the following error: [...] ./src/pmc/p6invocation.pmc, line 22: cannot find include file: pmc_perl6multisub.h cc: acomp failed for p6invocation.c gmake: *** [dynext/perl6_group.so] Error 1 ... #line 1 ./src/pmc/p6invocation.pmc ... The './src/pmc/' part of the #line directive is what is confusing Sun's compiler. It tries to #include src/pmc/pmc_perl6multisub.h. However, since we are *in* the src/pmc directory already, that fails. Removing the './src/pmc/' part of the #line directive fixes it. Unfortunately, the #line directives are generated code, so I don't know that Rakudo has any direct control over this. We may need to report it as a Parrot toolchain bug. Can you verify that this is still a problem in the 'ins2' branch? Thanks! Yes, it's still there. It's the 'cd' at the beginning of this line: cd $(PMC_DIR) $(CC) -c $(CINCLUDES) $(CFLAGS) *.c If memory serves, parrot doesn't change directories like that. Instead, it sets the output location directly, with something like $(CC) -c $(CINCLUDES) $(CFLAGS) -o src/pmc/p6invocation.o src/pmc/p6invocation.c -- Andy Dougherty dough...@lafayette.edu
Re: [perl #66558] Re: $(LD_OUT) can't have a space after it for MS linking.
On Fri, 24 Jul 2009, Patrick R. Michaud via RT wrote: On Fri Jun 12 11:36:31 2009, doughera wrote: In the 'ins' branch, build/Makefile.in looks like it's heading down the same wrong road as parrot. See parrot's TT #700 for more details and a patch for parrot. I'd suggest a similar approach for rakudo. The problem is that while MS forbids a space, Solaris 8 requires one. You can't win in the Makefile. 'make' is not a reliable textual susbtitution tool when leading or trailing blanks are involved. I've started a new branch (ins2) based on a more recent Rakudo and the latest Parrot release (1.4.0), and incorporated this patch there. Let me know if it works better on MS and Solaris than what we had before. Yes, I think that fixes the space problem for Solaris, and, as far as I am concerned, this ticket may be closed. Unfortunately, I've been unable to test it. Building parrot with Sun's compiler fails (TT #652). I was able to build parrot with gcc, but the rakudo build got stuck on the second step, running nqp.pbc against src/parser/actions.pm. After 3 and a half hours, it still hadn't produced any obvious output. The system was swapping like mad, and I had to kill the process so I could get other work done. Still, the generated Makefile looks ok to me on Solaris. -- Andy Dougherty dough...@lafayette.edu
Re: [perl #66558] AutoReply: Re: $(LD_OUT) can't have a space after it for MS linking.
In the 'ins' branch, build/Makefile.in looks like it's heading down the same wrong road as parrot. See parrot's TT #700 for more details and a patch for parrot. I'd suggest a similar approach for rakudo. The problem is that while MS forbids a space, Solaris 8 requires one. You can't win in the Makefile. 'make' is not a reliable textual susbtitution tool when leading or trailing blanks are involved. This patch implements the similar aproach. I can't test this because parrot no longer builds for me on any of my usual test platforms, but it looks about right. diff --git a/build/Makefile.in b/build/Makefile.in index 16b23c2..afa7e0a 100644 --- a/build/Makefile.in +++ b/build/Makefile.in @@ -10,11 +10,9 @@ PARROT_INCLUDE_DIR = @include...@$(PARROT_VERSION) PARROT_LIB_DIR = @lib...@$(PARROT_VERSION) PARROT_SRC_DIR = @src...@$(PARROT_VERSION) -CC= @cc@ -c -CC_OUT= @cc_o_out@ +CC= @cc@ CFLAGS= @ccflags@ @cc_shared@ @cc_debug@ @ccwarn@ @cc_hasjit@ @cg_flag@ @gc_flag@ LD= @ld@ -LD_OUT= @ld_out@ LDFLAGS = @ldflags@ @ld_debug@ LD_LOAD_FLAGS = @ld_load_flags@ LIBPARROT = @inst_libparrot_ldflags@ @@ -367,9 +365,9 @@ $(DYNPMC): $(PMC_SOURCES) $(PMC2C) --dump $(PMC2C_INCLUDES) $(PMC_SOURCES) $(PMC2C) --c $(PMC2C_INCLUDES) $(PMC_SOURCES) $(PMC2C) --library $(GROUP) --c $(PMC_SOURCES) - $(CC) $(CC_OUT) $(GROUP)$(O) -I$(PMC_DIR) $(CINCLUDES) $(CFLAGS) $(GROUP).c - cd $(PMC_DIR) $(CC) $(CINCLUDES) $(CFLAGS) *.c - $(LD) $(LD_OUT)$(DYNPMC) $(GROUP)$(O) src/pmc/*$(O) $(LINKARGS) + $(CC) -c @cc_o_...@$(GROUP)$(O) -I$(PMC_DIR) $(CINCLUDES) $(CFLAGS) $(GROUP).c + cd $(PMC_DIR) $(CC) -c $(CINCLUDES) $(CFLAGS) *.c + $(LD) @ld_...@$(DYNPMC) $(GROUP)$(O) src/pmc/*$(O) $(LINKARGS) DYNOPS_TARGETS = \ $(OPS_DIR)/$(OPS)$(LOAD_EXT) \ @@ -382,22 +380,22 @@ $(DYNOPS): $(DYNOPS_TARGETS) $(OPS_DIR)/$(OPS)$(LOAD_EXT): $(OPS_DIR)/$(OPS_SOURCE) cd $(OPS_DIR) $(OPS2C) C --dynamic $(OPS_SOURCE) - cd $(OPS_DIR) $(CC) $(CC_OUT) $(OPS)$(O) $(CINCLUDES) $(CFLAGS) $(OPS).c - cd $(OPS_DIR) $(LD) $(LD_OUT)$(OPS)$(LOAD_EXT) $(OPS)$(O) $(LINKARGS) + cd $(OPS_DIR) $(CC) -c @cc_o_...@$(OPS)$(O) $(CINCLUDES) $(CFLAGS) $(OPS).c + cd $(OPS_DIR) $(LD) @ld_...@$(OPS)$(LOAD_EXT) $(OPS)$(O) $(LINKARGS) $(OPS_DIR)/$(OPS)_switch$(LOAD_EXT): $(OPS_DIR)/$(OPS_SOURCE) cd $(OPS_DIR) $(OPS2C) CSwitch --dynamic $(OPS_SOURCE) - cd $(OPS_DIR) $(CC) $(CC_OUT) $(OPS)_switch$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_switch.c - cd $(OPS_DIR) $(LD) $(LD_OUT)$(OPS)_switch$(LOAD_EXT) $(OPS)_switch$(O) $(LINKARGS) + cd $(OPS_DIR) $(CC) -c @cc_o_...@$(OPS)_switch$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_switch.c + cd $(OPS_DIR) $(LD) @ld_...@$(OPS)_switch$(LOAD_EXT) $(OPS)_switch$(O) $(LINKARGS) $(OPS_DIR)/$(OPS)_cg$(LOAD_EXT): $(OPS_DIR)/$(OPS_SOURCE) cd $(OPS_DIR) $(OPS2C) CGoto --dynamic $(OPS_SOURCE) - cd $(OPS_DIR) $(CC) $(CC_OUT) $(OPS)_cg$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_cg.c - cd $(OPS_DIR) $(LD) $(LD_OUT)$(OPS)_cg$(LOAD_EXT) $(OPS)_cg$(O) $(LINKARGS) + cd $(OPS_DIR) $(CC) -c @cc_o_...@$(OPS)_cg$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_cg.c + cd $(OPS_DIR) $(LD) @ld_...@$(OPS)_cg$(LOAD_EXT) $(OPS)_cg$(O) $(LINKARGS) $(OPS_DIR)/$(OPS)_cgp$(LOAD_EXT): $(OPS_DIR)/$(OPS_SOURCE) cd $(OPS_DIR) $(OPS2C) CGP --dynamic $(OPS_SOURCE) - cd $(OPS_DIR) $(CC) $(CC_OUT) $(OPS)_cgp$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_cgp.c - cd $(OPS_DIR) $(LD) $(LD_OUT)$(OPS)_cgp$(LOAD_EXT) $(OPS)_cgp$(O) $(LINKARGS) + cd $(OPS_DIR) $(CC) -c @cc_o_...@$(OPS)_cgp$(O) $(CINCLUDES) $(CFLAGS) $(OPS)_cgp.c + cd $(OPS_DIR) $(LD) @ld_...@$(OPS)_cgp$(LOAD_EXT) $(OPS)_cgp$(O) $(LINKARGS) -- Andy Dougherty dough...@lafayette.edu
Re: [perl #53494] [BUG] --parrot_is_shared=0 IS shared?
On Sun, 22 Feb 2009, Reini Urban wrote:
Andrew Dougherty schrieb:
On Tue, 17 Feb 2009, Will Coleda via RT wrote:
On Mon Apr 28 23:52:22 2008, coke wrote:
While trying to put the macport for 0.6.1 together, I noticed that the
install failed.
Tracked it down to the fact that --parrot_is_shared=0 seems to be
generating a parrot that relies on a shared lib.
Verified, this still fails[1] as of r36803. This, combined with TT #344,
blocks creation of a functioning macport.
[1] Generates a parrot that depends on libparrot.dylib
That's because Configure.pl doesn't allow you any way to override the hints
file. What I had in mind was a more primitive, ruthless editing of the
darwin hints file, something like this (totally untested)
This was intended as a quick hack to try to get something --- anything --
working prior to the 0.9.1 release.
What I have in mind is a more general conf approach.
1. Disallow $conf-data-set('key') at all if $conf-options-get('key')
exists, only allow $conf-data-add('key').
Users try to fix the wrong hints options, and this is not enforced. Only some
keys are cooperative, most not.
I'm not sure what, exactly, you mean here, but that's ok.
2. Allow all keys to be given at the Configure.pl cmdline as in perl5.
Append (Apply after hints), Undefine and Define.
See the related discussion in [perl #42412]. (I've updated RT with the
relevant link.)
In any case, I won't have any time to do anything parrot-related for at
least the next several weeks, so I'm afraid I can't be of further help
here.
--
Andy Dougherty dough...@lafayette.edu
Re: [perl #47940] [CAGE] mk_native_pbc stale
On Mon, 9 Feb 2009, Reini Urban wrote:
2009/2/9 Andrew Dougherty dough...@lafayette.edu:
--- tools/dev/mk_native_pbc (revision 36480)
+++ tools/dev/mk_native_pbc (working copy)
@@ -1,32 +1,130 @@
#!/bin/sh
-# generate t/native_pbc_{1,2}.pbc
-# this should be run on i386 systems to regenerate the first two
-# native tests
-# NOTE: This will need a perl compiled with long double support
+# generate t/native_pbc/_{1,2}.pbc
Actually, that hasn't been true for a while.
perl Configure.pl --floatval='long double'
should be all that is needed. I do note, however, that this will
pick the wrong printf format string for floats. The patch in TT #294
fixes that.
I saw that fix.
On cygwin the old comment is true. cygwin perl supports no hugefloat
(long double),
but use64bitint, and perl Configure.pl --floatval='long double' fails in JIT.
src/jit/i386/core.jit:921:75: macro emitm_fldt requires 6
arguments, but only 5 given
perl Configure.pl --floatval='long double' --jitcapable=0 passes.
But I don't see how that has anything to do with whether the perl used to
run Configure.pl has 'long double' or not. Or, phrased differently, that
same JIT error occurs on x86 whether or not the perl used to run
Configure.pl has long double support or not. Hence I conclude that having
a perl compiled with long double support isn't necessary.
It does look like there's a JIT bug somewhere -- probably, Configure.pl
should simply refuse to try JIT if you insist on building with
non-standard data types, but that's a different issue.
--
Andy Dougherty dough...@lafayette.edu
Re: [perl #46179] [TODO] Remove GC code depending upon -D40 before parrot 1.0
On Mon, 2 Feb 2009, Andrew Whitworth via RT wrote: On Sat Oct 06 05:46:09 2007, pcoch wrote: In src/gc/register.c:clear_regs() there is the todo item: /* depending on -D40 we set int, num to garbage different garbage * TODO remove this code for parrot 1.0 We do want to remove the current code from clear_regs(), but what do we want to change it to? The PMC and STRING registers obviously need to be nulled out for GC to avoid false positives. Do we need to clear the values of the INT and NUM registers too? If so, what values do we want them to have? Should we still use special flag values for -D40? There's a bit more history of this in [perl #38978] and [perl #39244] (and some other old tickets too, but those are enough to give the idea). The problem was that, on some compilers in some situations, the I and N registered ended up as 0 even if they weren't explicitly initialized, and various bits in the test suite worked accidentally because of that. (There used to be conditional compilation mixed in there as well, just to make it even more confusing.) Such bugs have long since been eradicated in the test suite, and nothing developed in the past couple of years could rely on accidental initialization. None of which answers your question. The original intent was that the registers are not to be initialized, which would mean deleting the second branch (with the 888's) but leaving the -D40 branch as a possible debugging tool. -- Andy Dougherty dough...@lafayette.edu
Re: [svn:parrot] r36057 - in trunk: . config/auto config/auto/format config/gen/config_h include/parrot src t/compilers/imcc/syn t/op
On Tue, 27 Jan 2009, Nicholas Clark wrote:
On Tue, Jan 27, 2009 at 10:24:46AM -0800, parti...@cvs.perl.org wrote:
+else if (thefloat != thefloat) {
The above is the valid test for a NaN.
Note, Intel chose that the default optimiser setting on their compiler should
be buggy. (Advice from Klortho #11912). The perl 5 Linux hints file suggests
that one needs to add -we147 to enable correct floating point behaviour.
The best test that I'm aware of for is it NaN or Inf? is val != val * 0;
Then, NaN is val != val, +Inf is val 0, -Inf is val 0;
Well, if they are available, isnan() and isinf() are probably worth
trying. You can piggy back on perl 5's $Config{d_isnan} and
$Config{d_isinf}. To distinguish +NaN from -NaN, I suspect you might also
want to use signbit() (which, alas, perl 5 doesn't probe for).
Some of these functions might only be available under certain compiler
options or with certain extra libraries, depending on how a particular
system attempts to adhere to different standards, but it's probably worth
trying them.
--
Andy Dougherty dough...@lafayette.edu
Re: Ticket #105 (NULL checks)
On Wed, 31 Dec 2008, chromatic wrote: On Wednesday 31 December 2008 12:26:07 Andy Dougherty wrote: This is not a hypothetical what-if situation. I have lost many hours to just this situation. See my long example in ticket RT #50684. To save everyone from looking it up, I will extract the relevant example here: Your copy and paste accidentally omitted the part where you enabled optimizations and disabled debugging assistance, which, as you might expect, made debugging more difficult. I've had similar problems when I added asserts and wondered why they weren't working. I'm not sure that's a problem we can solve. The issue I was chasing only showed up under optimization. That's why I was enabling optimization. And yes, it is a problem we can easily solve. We can solve it by getting rid of the attribute_nonnull decorations and replacing them with assert()s. -- Andy Dougherty dough...@lafayette.edu
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 17 Nov 2008, Reini Urban via RT wrote: 2008/11/17 Andrew Dougherty [EMAIL PROTECTED]: On Sun, 16 Nov 2008, chromatic via RT wrote: Storable 2.18 required in r32744, which should resolve this issue. But the ultimate problem was that the issue was an unnecessary hurdle. At the time of the bug report, I tried building with Storable-2.12 and with 2.18 and observed *no difference*. That means that Storable-2.13 wasn't really *required* at all. I agree that explicitly requiring 2.18 early on gives a failure with a clear error message right away, which is definitely much better than getting a failure a long time after you've started the process and walked away. It's just that no failure is necessary at all. 2.12 worked just fine for parrot. 2.12 only works okay for a newer perl 5.8.6. 5.8.4 fails for sure, and I forgot if it was 5.8.6, which fixed overloading in CORE. Sigh. No. 5.8.4 does not fail for sure. I tested that explicitly. Just to be sure, I decided to check again. Here is the actual script I just ran (this was on Linux, just in case the patched OpenSolaris version of 5.8.4 included a patch which happened to be relevant.) The output at the end compares the directory trees for parrot built using Storable 2.12 and 2.18. The *only* differences reported are: 1. Different values for PARROT_CONFIG_DATE. 2. Binary files differ. (Expected because of #1 above, as well as time stamps.) 3. The Storable version requirement patch (s/2.18/2.12/) I applied to get parrot to compile with plain 5.8.4. 4. The temp file names used in the test suite There were no other differences. None. Each version fared identically on the test suite. This is what I mean when I say that I tried building with Storable-2.12 and with 2.18 and observed no difference. I am not saying that there are no bugs in the older Storable. Just that version 2.12 worked fine for parrot. #!/bin/sh prefix=/tmp/perl-5.8.4 perl=$prefix/bin/perl rm -rf $prefix bzip2 -d -c perl-5.8.4.tar.bz2 | tar -xf - cd perl-5.8.4 sh Configure -Dprefix=$prefix -des make -j 4 make install cd .. wget http://svn.perl.org/snapshots/parrot/parrot-latest.tar.gz cat patch-2.12 END_of_PATCH diff -r -u parrot/lib/Parrot/Configure.pm parrot-2.12/lib/Parrot/Configure.pm --- parrot/lib/Parrot/Configure.pm 2008-11-17 03:15:14.0 -0500 +++ parrot-2.12/lib/Parrot/Configure.pm 2008-11-17 11:32:27.0 -0500 @@ -40,7 +40,7 @@ use lib qw(config); use Carp qw(carp); -use Storable qw(2.18 nstore retrieve nfreeze thaw); +use Storable qw(2.12 nstore retrieve nfreeze thaw); use Parrot::Configure::Data; use base qw(Parrot::Configure::Compiler); diff -r -u parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm parrot-2.12/lib/Parrot/Pmc2c/Pmc2cMain.pm --- parrot/lib/Parrot/Pmc2c/Pmc2cMain.pm2008-11-17 03:15:14.0 -0500 +++ parrot-2.12/lib/Parrot/Pmc2c/Pmc2cMain.pm 2008-11-17 11:32:19.0 -0500 @@ -4,7 +4,7 @@ use strict; use warnings; -use Storable 2.18; +use Storable 2.12; use Parrot::PMC (); use Parrot::Pmc2c::VTable (); use Parrot::Pmc2c::Dumper; END_of_PATCH # Build using Storable 2.12 in 5.8.4. gzip -d -c parrot-latest.tar.gz | tar -xf - cd parrot patch -p1 -N ../patch-2.12 $perl Configure.pl make make test test.log 21 cd .. mv parrot parrot-2.12 gzip -d -c Storable-2.18.tar.gz | tar -xf - cd Storable-2.18 $perl Makefile.PL make make install cd .. # Build using Storable 2.18 gzip -d -c parrot-latest.tar.gz | tar -xf - cd parrot $perl Configure.pl make make test test.log 21 cd .. mv parrot parrot-2.18 diff -r -u parrot-2.12 parrot-2.18 -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 17 Nov 2008, chromatic wrote: On Monday 17 November 2008 11:07:52 Andrew Dougherty wrote: Note, by the way, that perl-5.8.8 only shipped with Storable 2.15. Perl 5.8.8 doesn't ship with File::Which either, and we require that too. (We do bundle that in our repository, which is something we shouldn't do and something I thought we didn't do anymore). Here are my assumptions: * anyone building Parrot now can install dependencies (working C compilation environment, potentially a bignum library, some CPAN modules, potentially flex/bison or equivalents) Yes, true enough, though of course the bigger the web of dependencies, the potentially more fragile things become, and the higher the barrier to newcomers. (ICU, for example, was quite a bit of a mess at one time, except on a very few platforms where it was well supported.) As usual, a balance is called for. Parrot's current dependencies are quite mild and, in my opinion, don't present a significant barrier. * it's simpler to require a single version of a dependency that we know will work reliably across platforms and other dependency versions than to create and maintain a matrix of platforms, dependencies, and versions [. . . ] Yes, completely agreed. But my point was that I have seen no evidence that 2.12 *didn't* work reliably. The log for revision 31585 only mentions Storable-2.09. Ticket [perl #59600] contains the only vague indication of there being a problem with versions 2.13, but doesn't say what the problem actually was. It also admits uncertainty about which precise versions might be involved. So I did some testing. As far as I could determine, 5.8.4 + 2.12 worked just fine, so I reported that. When told I was wrong, I rechecked and reported, with enough detail so that it was obvious exactly what I did. I realize that requiring people to install Storable 2.18 is somewhat of a headache, but it looks like the type of headache that's much smaller than the headaches of the alternatives. No, it's not a headache. It's just that, as far as I can tell, it's totally unnecessary. I have so many different versions of perl built and installed already anway that it doesn't really affect me in any significant way. I was just trying to help keep the entry barrier low for others. But I don't really care very much, so I'll stop now. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Thu, 13 Nov 2008, chromatic wrote: On Monday 03 November 2008 09:38:11 Andy Dougherty wrote: 3. 1 of the tests appears to fail depending on how the OS initial- cases 'Inf'. Again, could this be addressed in a hints file? This too is a long-standing problem: See [perl #19183]. It stalled pending a decision on whether or not parrot should try to enforce a single spelling of 'Inf' (and 'Nan', etc.) or whether the tests should patch over the issue. What does Perl 5 do? Let's do that. (No one else has made a decision.) I'm pretty sure Perl 5 just does whatever the underlying system does. At lesat I don't remember ever writing any Configure tests to do otherwise, and a quick look doesn't turn up anything obvious, and I don't think the test suite specifically tests for it. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Sat, 8 Nov 2008, chromatic wrote: On Monday 03 November 2008 09:38:11 Andy Dougherty wrote: I wonder if this patch fixes things. Certainly it does no harm on my box. Parrot_signbit() already exists in the platform files, so we might as well use it. --- src/spf_render.c (revision 32475) +++ src/spf_render.c (local) @@ -724,7 +724,12 @@ STRING *ts; const HUGEFLOATVAL thefloat = obj-getfloat(interp, info.type, obj); +const long double ld = (long double)thefloat; +/* force negative float zero to -0.0 in output */ +if (fabsl(ld) == 0.0 Parrot_signbit(ld)) +info.flags |= FLAG_MINUS; + Unfortunately, whether or not signbit takes a double or a 'long double' appears to depend on the platform. On Linux, signbit is a macro which is supposed to work for all floating point types. On Solaris, there are separate signbitf(), signbit() and signbitl() types to deal with float, double, and long double respectively. Probably whatever piece of Configure figures out HUGEFLOATVAL should also figure out the appropriate Parrot_signbitH() or some such to use with it. (I'd guess it's almost always Parrot_signbitl().) (I'm not sure how portable fabsl() is either, though it may not matter. I don't see any harm to just omitting it here.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Sun, 2 Nov 2008, James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #60312] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60312 Thanks to some automated test reporting setups (which I think are still coming from magnachef), we are getting a steady stream of test reports on the Smolder site from FreeBSD, NetBSD and OpenBSD. Of the three, the first two generally pass 100% of tests, but OpenBSD's performance has often been much poorer. Of late, OpenBSD has been passing 99.95% of its tests, which is a clear improvement over just a month ago. So I figured it would probably be good to put all the failures we're still getting on OpenBSD in one place to see if patterns emerge. I want to stress that I have neither experience with, nor access to, OpenBSD. So I have no particular insight into these failures, nor can I directly test patches. As of today, there are 6 tests failing on OpenBSD, as reported on Smolder. Nice job pulling out the relevant tests and figuring out what's going on! Observations: 1. All 6 of these tests are marked to be skipped on Win32. So perhaps the reason they're failing on OpenBSD is the same as that for Win32. If so, then we could add 'OpenBSD' to the SKIP messages for each. I have never liked that plan -- skipping tests simply because they fail just hides the problem. As a short-term step to keep from being distracted, sure, it's a good strategy. But such sort term fixes tend to become very long-lived, leading folks to forget there even was a problem. If the failing tests themselves are the problem, they should just be deleted. 2. 4 of the tests appear to fail depending on how the OS 'spells' the negation of zero. Could we address this in a hints file? This is a long-standing problem: See [perl #28170] and [perl #30737]. The last time I looked at this, the it seemed we should probably use signbit(), if available. (If it's not available, a fallback is needed, but it's likely to usually be available.) However, I don't know why OpenBSD would differ from NetBSD in this regard. Certainly the math.c platform files are nearly identical. Are the underlying machines and perl5 configurations the same for the NetBSD and OpenBSD tests? The 'myconfig' files from each configuration would be helpful in trying to assess what's the same and what's different. 3. 1 of the tests appears to fail depending on how the OS initial- cases 'Inf'. Again, could this be addressed in a hints file? This too is a long-standing problem: See [perl #19183]. It stalled pending a decision on whether or not parrot should try to enforce a single spelling of 'Inf' (and 'Nan', etc.) or whether the tests should patch over the issue. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60312] [BUG] OpenBSD Smolder test failures
On Mon, 3 Nov 2008, James Keenan via RT wrote: Are the underlying machines and perl5 configurations the same for the NetBSD and OpenBSD tests? I believe so. I think magnachef has them set up as virtual machines on the same underlying box. He's working on getting me accounts on them and, if that comes through, I'll be able to post Configure.pl and make output. Even more immediately useful would be the 'myconfig' info for each configuration. I designed the file to be useful in precisely this sort of situation. -- Andy Dougherty [EMAIL PROTECTED]
Re: Parrot doesn't build on OS X
On Sat, 1 Nov 2008, Mark J. Reed wrote: Trunk or 0.8.0? Trunk builds fine on my iMac running the same Darwin version you report (leopard 10.5.5). There are also other issues to consider: What libraries are in use? [e.g. there is speculation that it may be a libgmp issue]. What compiler options were given? All this information, and more, is given in the 'myconfig' file. Attaching that to the problem report would likely be useful. Also, running the core tests might help pinpoint the problem. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #60190] [BUG] problems with the compiler-option -O2 on a 64bit-system
On Fri, 31 Oct 2008, Gerd Pokorra wrote: [EMAIL PROTECTED] tge]$ gdb ../../parrot (gdb) set args ../../runtime/parrot/library/PGE/Perl6Grammar.pbc --output=TGE/Parser.pir TGE/Parser.pg (gdb) run Starting program: /home/gz016/parrot-sources/debug/parrot-0.8.0/parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pbc --output=TGE/Parser.pir TGE/Parser.pg [Thread debugging using libthread_db enabled] [New Thread 0x7f543fe82700 (LWP 5203)] Another thing you might want to consider is that you can probably find a more tractable test case somewhere in the test suite. Try perl t/harness --core-tests and see what tests fail. (Obviously, ones that depend on PGE will fail, but we already know that. You're looking for simpler test cases.) Then, once you find tests that fail, try running those individual tests with parrot (and also with parrot -G to turn off garbage collection) and see what's the smallest or simplest failing test case you can find. They might be better candidates for debugging. -- Andy Dougherty [EMAIL PROTECTED]
Re: building parrot
On Sat, 25 Oct 2008, Michael P. Soulier wrote: On 15/10/08 Andy Dougherty said: No file by that name on the box anywhere. Are you *sure*? I don't know exactly what name you searched for, nor how you searched for it, but this is just the sort of error message I'd expect to see if you did have an old libparrot.so somewhere else on your system. I'm building in /home/msoulier/temp/parrot. So, I ran updatedb followed by locate libparrot. All the hits can from under that directory. Ok. Though depending on your local set-up, that doesn't really prove anything. updatedb skips various files for various reasons (filesystems, permissions, etc.) Without knowing way more details of your local set-up, I can't tell whether or nor this actually means anything. For example, note that your 'locate' command didn't actually locate blib/lib/libparrot.so, even though your 'nm' command below shows that it exists. Still, that doesn't seem to be the problem. See below. locate libparrot /home/msoulier/temp/parrot/ports/cygwin/.svn/text-base/libparrot0.hint.svn-base /home/msoulier/temp/parrot/ports/cygwin/.svn/text-base/libparrot-devel.hint.svn-base /home/msoulier/temp/parrot/ports/cygwin/.svn/prop-base/libparrot0.hint.svn-base /home/msoulier/temp/parrot/ports/cygwin/.svn/prop-base/libparrot-devel.hint.svn-base /home/msoulier/temp/parrot/ports/cygwin/libparrot0.hint /home/msoulier/temp/parrot/ports/cygwin/libparrot-devel.hint /home/msoulier/temp/parrot/ports/debian/.svn/text-base/libparrot-dev.install.svn-base /home/msoulier/temp/parrot/ports/debian/.svn/text-base/libparrot.install.svn-base /home/msoulier/temp/parrot/ports/debian/.svn/text-base/libparrot-dev.dirs.svn-base /home/msoulier/temp/parrot/ports/debian/libparrot-dev.install /home/msoulier/temp/parrot/ports/debian/libparrot.install /home/msoulier/temp/parrot/ports/debian/libparrot-dev.dirs /home/msoulier/temp/parrot/t/steps/.svn/text-base/inter_libparrot-01.t.svn-base /home/msoulier/temp/parrot/t/steps/.svn/prop-base/inter_libparrot-01.t.svn-base /home/msoulier/temp/parrot/t/steps/inter_libparrot-01.t /home/msoulier/temp/parrot/config/inter/.svn/text-base/libparrot.pm.svn-base /home/msoulier/temp/parrot/config/inter/.svn/prop-base/libparrot.pm.svn-base /home/msoulier/temp/parrot/config/inter/libparrot.pm To be specific: The first 'undefined reference' is to Parrot_new. It should be in src/embed.o and also in blib/lib/libparrot.so. What do you get for the following commands: nm src/embed.o | grep 'Parrot_new$' nm blib/lib/libparrot.so | grep 'Parrot_new$' [EMAIL PROTECTED]:~/temp/parrot$ nm src/embed.o | grep 'Parrot_new$' T Parrot_new Ok. That's normal. [EMAIL PROTECTED]:~/temp/parrot$ nm blib/lib/libparrot.so | grep 'Parrot_new$' 000defc0 t Parrot_new That's not. Look at the lower case 't'. That means Parrot_new is not a global symbol, but a local one. I have no idea how that could have happened. It was fine in the original src/embed.o file, but somehow got changed when you make blib/lib/libparrot.so. I have no idea how. I do note that you appear to be using an svn checkout, where before you were using the 0.7.1 released version. Perhaps there's something broken in the checkout you have. Or perhaps there's something not correctly cleaned up. The only thing I can think of is to start with a fresh copy and log the output of the 'make' command. Then look at the command used to build the blib/lib/libparrot.so library so we can try to figure out what happened to the Parrot_new symbol in going from src/embed.o to blib/lib/libparrot.so. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38823] [BUG] solaris 10 w gcc
On Mon, 20 Oct 2008, Andrew Whitworth via RT wrote: On Fri Mar 31 13:29:46 2006, leo wrote: I've tried: $ perl Configure.pl --cc=gcc --link=gcc --ld=gcc --cxx=gcc --verbose-step=gcc and got: Determining if your C compiler is actually gcc...gcc -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO -I./include -c test.c gcc: language arch=v8 not recognized From perl -V: Compiler: cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO', optimize='-xO3 -xspace -xildoff', That is, our config system is still using perl5 config vars blindly w/o further inspection and ignores commandline option at least partially. This ticket is over two years old and the problem described appears to be, at least in part, dependent on the faulty config system of years gone by. The ticket may be old, but we still have the same faulty config system. Do we have any Solaris users who can double-check this and see if we still have a problem here? Yes, we still have exactly the same problem. Anyone can check this by editing their perl Config settings and seeing that they get passed through unquestioningly to parrot. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #38823] [BUG] solaris 10 w gcc
On Tue, 21 Oct 2008, Andrew Whitworth wrote: On Tue, Oct 21, 2008 at 9:28 AM, Andy Dougherty [EMAIL PROTECTED] wrote: On Mon, 20 Oct 2008, Andrew Whitworth via RT wrote: On Fri Mar 31 13:29:46 2006, leo wrote: That is, our config system is still using perl5 config vars blindly w/o further inspection and ignores commandline option at least partially. The ticket may be old, but we still have the same faulty config system. Okay, then maybe we need to rename this ticket to something more appropriate, to show that this isn't just a Solaris problem. It isn't just a Solaris problem, but Solaris is probably one of the more popular platforms where this is appears. (The usual issue is that the vendor supplies a perl compiled with the vendor's compiler, but an end user wishes to use gcc.) How about something like: Configure.pl relies too heavily on perl5 ccflags settings. -- Andy Dougherty [EMAIL PROTECTED]
Re: building parrot
On Wed, 15 Oct 2008, Michael P. Soulier wrote: Hello, I'd report a bug but this link http://www.parrot.org/docs/submissions.html is broken. I'm trying to build parrot on a CentOS 4.6 box and it's failing at link time. gcc -o miniparrot src/main.o src/null_config.o \ -Wl,-rpath=/home/msoulier/downloads/parrot-0.7.1/blib/lib -L/home/msoulier/downloads/parrot-0.7.1/blib/lib -lparrot -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline -lncurses -lcrypto -L/usr/local/lib -Wl,-E src/main.o(.text+0x5c): In function `main': src/main.c:52: undefined reference to `Parrot_new' src/main.o(.text+0x6a):src/main.c:53: undefined reference to `imcc_initialize' src/main.o(.text+0x86):src/main.c:58: undefined reference to `string_from_cstring' src/main.o(.text+0x95):src/main.c:58: undefined reference to `Parrot_set_executable_name' src/main.o(.text+0xae):src/main.c:60: undefined reference to `parseflags' src/main.o(.text+0xd1):src/main.c:61: undefined reference to `imcc_run' src/main.o(.text+0xdf):src/main.c:65: undefined reference to `Parrot_destroy' src/main.o(.text+0xf2):src/main.c:66: undefined reference to `Parrot_exit' src/null_config.o(.text+0x25): In function `Parrot_set_config_hash': src/null_config.c:29: undefined reference to `Parrot_set_config_hash_internal' collect2: ld returned 1 exit status make: *** [miniparrot] Error 1 I found one bug online like this, where the fix was not using tcsh, but I don't use tcsh. Do you have a link for that bug report? I vaguely recall something like that where the tcsh was a red herring -- it was really an environment variable setting -- but I don't recall any more details offhand. -- Andy Dougherty [EMAIL PROTECTED]
Re: building parrot
On Wed, 15 Oct 2008, Michael P. Soulier wrote: I'm trying to build parrot on a CentOS 4.6 box and it's failing at link time. gcc -o miniparrot src/main.o src/null_config.o \ -Wl,-rpath=/home/msoulier/downloads/parrot-0.7.1/blib/lib -L/home/msoulier/downloads/parrot-0.7.1/blib/lib -lparrot -lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lreadline -lncurses -lcrypto -L/usr/local/lib -Wl,-E src/main.o(.text+0x5c): In function `main': src/main.c:52: undefined reference to `Parrot_new' src/main.o(.text+0x6a):src/main.c:53: undefined reference to `imcc_initialize' src/main.o(.text+0x86):src/main.c:58: undefined reference to `string_from_cstring' [ . . . ] On Wed, Oct 15, 2008 at 9:52 AM, Will Coleda [EMAIL PROTECTED] wrote: Do you have a previously installed parrot? It's possible that we're inadvertently linking against the installed libparrot instead of the one in your build dir. No file by that name on the box anywhere. Are you *sure*? I don't know exactly what name you searched for, nor how you searched for it, but this is just the sort of error message I'd expect to see if you did have an old libparrot.so somewhere else on your system. To be specific: The first 'undefined reference' is to Parrot_new. It should be in src/embed.o and also in blib/lib/libparrot.so. What do you get for the following commands: nm src/embed.o | grep 'Parrot_new$' nm blib/lib/libparrot.so | grep 'Parrot_new$' -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Tue, 14 Oct 2008, Nicholas Clark wrote: I infer from the quoted message above that bumping the dependency to 2.13 would work as well, but wouldn't cause a lot of other people who have 2.13 to 2.17 installed to need to upgrade. That's, in fact, what parrot currently requires: 2.13. However, if you only have 2.12 and go to CPAN to upgrade, you'll end up with 2.18, which is what chromatic was referring to. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
On Sat, 11 Oct 2008, Allison Randal via RT wrote: jerry gay wrote: .\src\pmc\float.c(3340) : warning C4204: nonstandard extension used : non-constant aggregate initializer there are now hundreds of these warnings in that build. we do have warnings ratcheted up pretty high, but i don't think it's worth relaxing them for this construct unless it's very difficult to change the code generator--i assume this is generated code, since it's in so many pmc .c files. i may get a chance to investigate further this evening, if somebody hasn't beaten me to it. Yes, that's generated code, it's part of the initialization of MULTIs declared in a PMC. I was hoping to avoid all those C strings. But, try r31879. Yes, that works fine. Thanks, -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #59660] Storable-2.13 requirement breaks build on OpenSolaris
On Mon, 13 Oct 2008, chromatic via RT wrote: On Mon Oct 06 12:15:49 2008, doughera wrote: Trying to compile today's parrot on an up-to-date version of OpenSolaris: SunOS xxx 5.11 snv_98 i86pc i386 i86pc Solaris it failed (after a while) with the following error: perl tools/build/pmc2c.pl --vtable Storable version 2.13 required--this is only version 2.12 at The problem is that OpenSolaris ships with (a patched version of) perl-5.8.4. I'm not sure why OpenSolaris is still shipping perl- 5.8.4, but they are. I haven't looked at tools/build/pmc2c.pl at all to see why Storable 2.13 is required, nor at how large of a burden it would be to relax that requirement. Such digging would take more time than I have available at the moment. If I remember correctly, Storable 2.12 and earlier did not restore overloading properly. Storable's changelog suggests that version 2.18 compiles properly on older versions of Perl; if it works with Perl 5.8.4 in OpenSolaris, we could keep the dependency on 5.8.1 (or whatever) and increase the Storable dependency to 2.18. Storable 2.18 builds and tests fine on OpenSolaris. (So do perl-5.8.8 and perl-5.8.9-to-be.) On the other hand, changing the requirement in lib/Parrot/Pmc2c/Pmc2cMain.pm to Storable 2.12 instead of 2.13, and then building with Storable 2.12, also seems to work. That is, there are no significant differences between the generated files. -- Andy Dougherty [EMAIL PROTECTED]
Re: New Parrot mailing list
On Fri, 19 Sep 2008, James E Keenan wrote: Allison sent me this reply: I set up the Google Group, because I know a number of people are using it. Can I see a show of hands of people who are only using NNTP and would have difficulty switching to a regular email subscription or Google Group? I use NNTP. I much prefer the command-line news interface to Google Groups, but I guess I wouldn't go so far as to say I would have difficulty switching to a regular email subscription. Or, to put it another way: If there were an NNTP interface, I would definitely use it, but I wouldn't want anyone else to be stuck implementing and maintaining it just for my occasional use. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
I think you've gone about this in the right way, but need to handle the various cases a bit more broadly. Specifically, you can't assume that everyone has strerror() at all (Solaris 8 doesn't, for example) nor that everyone who uses int strerror_r() will also define either _XOPEN_SOURCE or _POSIX_C_SOURCE (NetBSD doesn't, for example). I think perhaps a structure like the following might work: #if defined(HAS_STRERROR_R) # if defined(STRERROR_R_RETURNS_INT) /* stuff using int strerror_r(); */ # else /* stuff using char *strerror_r() */ #else /* stuff using plain strerror(). */ #endif Currently, you are trying to guess which branch based on various #defines, but non-Linux systems will fall through to the wrong branch, and systems without strerror_r will fail completely. Ideally, Configure.pl ought to figure which branch you need. Alas, it doesn't. However, perl5's Configure does (at least for Unix systems), so you could just use it's results. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Wed, 10 Sep 2008, James Keenan via RT wrote: On Wed Sep 10 09:30:37 2008, doughera wrote: That's another easy one. The test assumes that all platforms have -lrt and that all platforms have to link with it for this test. Your system clearly doesn't have -lrt, so the link fails. If you just delete the line that adds in -lrt, I'll bet the test succeeds. Generally, Configure shouldn't be unconditionally adding libraries. A better idiom is probably to try without, and then try with only if necessary. Something like this: The principle sounds good. I applied the patch and, as predicted, it DTRT on Linux, as this verbose output for auto::aio on Linux demonstrates. Unfortunately, it didn't cause AIO to be located on Darwin -- even though it changed the error message. The handles to the error files were opened, but the .out, .cco and .ldo files were all empty. It could be that aio just doesn't work on your system -- or at least aio as implemented by the author of this test. If you care to diagnose it further, you could try running the test_26632 executable directly from the command line and see what the output is. Or you could alter config/auto/aio.pm to output the errors in this case. However, I'm unsure if it's worth it. You'll might learn a little more about why it's failing, but you may not be able to do anything to fix it. $ ls -ltr test_* -rw-r--r-- 1 jimk jimk 3424 Sep 10 19:58 test_26632.o -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.ldo -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.cco -rw-r--r-- 1 jimk jimk 1330 Sep 10 19:58 test_26632.c -rw-r--r-- 1 jimk jimk 0 Sep 10 19:58 test_26632.out -rwxr-xr-x 1 jimk jimk 18148 Sep 10 19:58 test_26632 -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Sat, 6 Sep 2008, chromatic wrote:
On Saturday 06 September 2008 20:19:56 James Keenan via RT wrote:
test_17787.c: In function 'main':
test_17787.c:45: error: 'SIGRTMIN' undeclared (first use in this function)
test_17787.c:45: error: (Each undeclared identifier is reported only once
test_17787.c:45: error: for each function it appears in.)
test_17787.c:46: error: 'SIGRTMAX' undeclared (first use in this function)
If they're not in signal.h in Darwin, where are they? (And if they're not in
signal.h in Darwin, can someone squelch the rumor that Mac OS X is a
Unix-like platform? POSIX 2001!)
... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now. Mainly, I was just hoping that a minor fix would
help solve Patrick's problem of Configure.pl hanging during the aio probe.
I don't know if it actually made any difference.
Anyway, here's a minimally disruptive patch to change SIGRTMIN to SIGUSR1.
I also got rid of the completely-unused logic to add
SIGRTMIN + atoi(argv[1]), since that no longer makes any sense.
This patch also gets rid of the probing for SIGRTMIN and SIGRTMAX. If
parrot actually wants to use them, it should get them from a separate
probe, rather than relying on them as a side effect of this test. At the
moment, parrot doesn't use either one, so this does not change any
functionality.
After this patch, the probe will still be useless, since aio still isn't
used anywhere, but perhaps it will now pass on Darwin and not hang
elsewhere.
diff -r -u parrot-current/config/auto/aio/aio.in
parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-08 08:38:49.0
-0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-09 07:45:03.0 -0400
@@ -36,14 +36,7 @@
int i = 42;
int cnt = 4;
-/* For internal use, we usually use
- SIGRTMIN + argv[1].
- Usually, that's set to
- SIGRTMIN + 1
- by the calling program.
-*/
-my_sig = SIGRTMIN + atoi(argv[1]);
-printf(SIGRTMIN=%d SIGRTMAX=%d\n, SIGRTMIN, SIGRTMAX);
+my_sig = SIGUSR1;
fd = open(MANIFEST, O_RDONLY);
if (fd 0)
diff -r -u parrot-svn/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-08 08:38:49.0 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-09 07:46:14.0 -0400
@@ -49,14 +49,13 @@
my $errormsg = _first_probe_for_aio($conf, $verbose);
if ( ! $errormsg ) {
-my $test = $conf-cc_run(1); # Use signal RTMIN + 1
+my $test = $conf-cc_run();
# if the test is failing with sigaction err
# we should repeat it with a different signal number
# This is currently not implemented.
if (
-$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
-INFO=42\n
+$test =~ /INFO=42\n
ok/x
)
{
@@ -66,8 +65,6 @@
$conf-data-set(
aio= 'define',
HAS_AIO= 1,
-D_SIGRTMIN = $1,
-D_SIGRTMAX = $2,
);
}
else {
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, 9 Sep 2008, Will Coleda wrote: On Tue, Sep 9, 2008 at 8:46 AM, Andy Dougherty [EMAIL PROTECTED] wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. In general, I'd agree. However, in this particular case, fixing it was easier for me than figuring out all the steps necessary to rip it out. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Sat, 6 Sep 2008, Christoph Otto via RT wrote: On Wed May 10 11:01:34 2006, stmpeters wrote: I'm taking a look at it. I should have something working this evening for the configs. Adding the HAS_BLAH's will take some additional time. Steve Peters [EMAIL PROTECTED] when useful is vague does not indicate why the extra configuration machinery is justified by whatever benefit we'd get from using these functions. If someone would like to make the requirements a little tighter or make the case for implementing this request (or even implement it), they'd be encouraged. Otherwise this ticket isn't very useful. It would be good to either go somewhere with this or reject this request. These functions are typically used in place of the plain sprintf and strcat family as a way to be explicitly careful about buffer overflows. Plain sprintf and strcat are both widely used in the parrot source. Replacing them when it would ease future maintenance and help ensure parrot is not susceptible to buffer overflows is a quite sensible path forward. As you correctly observe, no one has actually done anything about it yet. That doesn't mean it's not worth doing, however. I'd say it should simply stay as an open ticket. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Fri, 5 Sep 2008, James Keenan via RT wrote: On Thu Sep 04 19:22:56 2008, [EMAIL PROTECTED] wrote: FWIW, here is a data point: What happens on my Darwin/PPC (10.4) Mac at auto::aio: On Darwin, Configure.pl reports that AIO is unsupported. Follow-up question: If I 'locate aio' on my Mac and come up with this (excerpted) list of files: /usr/include/aio.h /usr/include/sys/aio.h /usr/share/man/man2/aio_cancel.2 /usr/share/man/man2/aio_error.2 /usr/share/man/man2/aio_read.2 /usr/share/man/man2/aio_return.2 /usr/share/man/man2/aio_suspend.2 /usr/share/man/man2/aio_write.2 ... what *else* would I need to have AIO available on Darwin? It looks like you already have it available. If you try with my patch in verbose mode, what, exactly, goes wrong such that Configure.pl concludes AIO is unsupported? -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Thu, 4 Sep 2008, Patrick R. Michaud wrote:
On Thu, Sep 04, 2008 at 04:52:34PM -0700, James Keenan via RT wrote:
I applied the patch attached, aio.in.revised.patch.txt, in r30771. I
set the 'sleep' to 4 seconds. All the tests have been reactivated.
Thanks.
This is a patch in the sense of bandaid. What is it about the letter
'K' that means that this probe gives sloppy results on Kubuntu when on
Ubuntu it has built cleanly for me every day since I started building
Parrot?
The problem only appeared for me in Kubuntu a few weeks ago, and
then only intermittently until a week or so ago. Prior to the
beginning of August Parrot had been building cleanly for me on
Kubuntu without any difficulty.
As one of the earlier messages suggested, I think it may just be a
race condition in the signal handling.
It's a wacky test in many respects. For one thing, it tests using
signal number '35' without any regard for what that signal might
acutally mean. On Solaris, for example, 35 is 'SIGFREEZE', which is
almost certainly not what was intended.
I suspect that on someone's Linux system, SIGRTMIN got reported as 34,
and so the test just hard-coded '35'. It's quite possible that signal
35 means something different on recent versions of Kubuntu.
This patch takes the following small steps:
First, I replaced the
retval = *(int*)i-si_ptr;
line by
retval = *(int*)i-si_value.sival_ptr;
I've never fiddled with this stuff before, but it looks like the si_ptr
#define is not necessarily very portable. I replaced it by the si_value
and sival_ptr fields, which I hope are slightly more portable.
Second, it moves the small step of moving the logic of finding
SIGRTMIN + 1 into the C program, where it's trivial.
Next, it adds in an else branch for the case where the program builds
but does not run successfully.
Finally, made sure the 'aio' and 'HAS_AIO' entries are always set to
some value.
I haven't looked for race conditions at all, but with this patch, I'll at
least be more confident that it's trying to do what we think it's trying
to do.
diff -r -u parrot-current/config/auto/aio/aio.in
parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-05 08:13:19.0
-0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-05 13:04:03.0 -0400
@@ -23,7 +23,7 @@
{
if (s == my_sig) {
flag = s;
- retval = *(int*)i-si_ptr;
+ retval = *(int*)i-si_value.sival_ptr;
}
}
@@ -36,7 +36,13 @@
int i = 42;
int cnt = 4;
-my_sig = atoi(argv[1]);
+/* For internal use, we usually use
+ SIGRTMIN + argv[1].
+ Usually, that's set to
+ SIGRTMIN + 1
+ by the calling program.
+*/
+my_sig = SIGRTMIN + atoi(argv[1]);
printf(SIGRTMIN=%d SIGRTMAX=%d\n, SIGRTMIN, SIGRTMAX);
fd = open(MANIFEST, O_RDONLY);
diff -r -u parrot-current/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-current/config/auto/aio.pm 2008-08-31 12:15:34.0 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-05 12:08:23.0 -0400
@@ -49,10 +49,11 @@
my $errormsg = _first_probe_for_aio($conf);
if ( ! $errormsg ) {
-my $test = $conf-cc_run(35);
+my $test = $conf-cc_run(1); # Use signal RTMIN + 1
# if the test is failing with sigaction err
# we should repeat it with a different signal number
+# This is currently not implemented.
if (
$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
INFO=42\n
@@ -69,6 +70,9 @@
D_SIGRTMAX = $2,
);
}
+else {
+$self-_handle_error_case($conf, $libs, $verbose);
+}
}
else {
$self-_handle_error_case($conf, $libs, $verbose);
@@ -88,7 +92,11 @@
sub _handle_error_case {
my ($self, $conf, $libs, $verbose) = @_;
-$conf-data-set( libs = $libs );
+$conf-data-set(
+aio= undef,
+HAS_AIO= 0,
+);
+$conf-data-set( libs = $libs ); # Restore old values
print (no) if $verbose;
$self-set_result('no');
}
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #58076] Configure tests fail with Can't store CODE items
On Tue, 26 Aug 2008, James Keenan via RT wrote: Patched two subs in Parrot::Configure and adjusted test files in r30583. Tested with triggers in hints files on Linux and Darwin. Thanks. That closes this ticket and just leaves us with the old familiar: t/steps/auto_warnings-01.Compilation failed with 'cc' # Looks like you planned 56 tests but only ran 15. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 16-56 Failed 41/56 tests, 26.79% okay where I've told Configure.pl to use gcc, but the test still falls back on using the incorrect value of 'cc' that perl5 was built with. -- Andy Dougherty [EMAIL PROTECTED]
Re: pdd19_pir.pod: See Cdocs/imcc/macros.pod
On Thu, 28 Aug 2008, Reini Urban wrote:
Will Coleda schrieb:
On Thu, Aug 28, 2008 at 11:09 AM, Reini Urban [EMAIL PROTECTED] wrote:
We could thing of symlinking it to runtime/parrot/library
at make languages, so language_interop can be tested.
Are symlinks usable wherever we might install?
True, there's no perl -MExtUtils::Command -e ln_s
But we have LN_S = @lns@
But that's not necessarily a symbolic link. It was originally intended
only for use with files, not directories. If symlinks aren't available on
Unix, it falls back to a plain 'ln'. On Win32 versions of perl, lns is
usually defined as 'copy'.
So the short answer is that, at the moment, without additional
Configure.pl work, you can't assume $Config{lns} can be used to make
symbolic links for directories.
--
Andy Dougherty [EMAIL PROTECTED]
Re: My Parrot 0.7.0 patches (cygwin)
On Mon, 25 Aug 2008, Reini Urban wrote: Reini Urban schrieb: 2008/8/24 Allison Randal [EMAIL PROTECTED]: Reini Urban wrote: To clarify my bold statement: The ALGOL-like syntax is not sane because, * it is hard to parse, * it forbids our keywords AND, NOT and OR as config_hash keys and platform names. With lisp syntax there's a clear distinction between operator and arguments, with mixed arg op arg syntax it is not clear and as hard to understand as spoken language. #+(and foo (not bar)) is a well-established reader-macro syntax in lisp and a general life-safer in lisp, compared to less developed languages. If parrot were written in lisp, this might indeed be compelling. It's not, however. It's written primarily in C and perl, which tend to be more Algol-like. In my own case, I would have no idea what #+(and foo (not bar)) meant unless I had read your explanation that it was some sort of reader-macro syntax. And even that only gives me a vague understanding of what it actually is. What we did in perl5's build system was to recognize that we didn't have to invent or borrow any new syntax at all. The languages we were using to write the Makefiles (namely /bin/sh and perl) already had sophisticated interpolation and conditional syntax capabilities. We used here-documents and interpolation instead of macro substitution. We used the language's built-in conditional and flow control syntax to express complex ideas. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57814] Bug Report: Error running make on Red Hat Enterprise v 3.6.9
On Wed, 13 Aug 2008, Christoph Otto via RT wrote: On Mon Aug 11 16:21:07 2008, [EMAIL PROTECTED] wrote: src/main.o(.text+0x5c): In function `main': src/main.c:52: undefined reference to `Parrot_new' src/main.o(.text+0x6a):src/main.c:53: undefined reference to `imcc_initialize' src/main.o(.text+0x86):src/main.c:58: undefined reference to `string_from_cstring' src/main.o(.text+0x95):src/main.c:58: undefined reference to `Parrot_set_executable_name' src/main.o(.text+0xae):src/main.c:60: undefined reference to `parseflags' src/main.o(.text+0xd1):src/main.c:61: undefined reference to `imcc_run' src/main.o(.text+0xdf):src/main.c:65: undefined reference to `Parrot_destroy' src/main.o(.text+0xf2):src/main.c:66: undefined reference to `Parrot_exit' src/null_config.o(.text+0x25): In function `Parrot_set_config_hash': src/null_config.c:29: undefined reference to `Parrot_set_config_hash_internal' collect2: ld returned 1 exit status make: *** [miniparrot] Error 1 The solution was to run Configure.pl and make under bash instead of tcsh. Since the problem has been solved, I'm resolving this ticket. Just running under tcsh seems unlikely to have been the root cause. I suspect that what really happens is you have different environment variables set under tcsh and bash. This error looks like the one we see when there is an already-installed libparrot.so somewhere that conflicts with the the one you're trying to build. (You don't show the compiler command line that generated the error, so this is only a guess.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41508] [BUG] Configure losing flags...
On Sat, 9 Aug 2008, James Keenan via RT wrote: I think that many of the things you say are interesting, but they are part of a much broader discussion. In a conversation I had with particle and chromatic at YAPC, particle indicated that we would be revisiting the design of our configuration at a point before 1.0. So what I'm doing now is largely focused on responding to particular needs expressed by our developers which do not require a complete re-thinking of our configuration system right now. So, for example, here I'm trying to respond to a particular issue raised by Coke that I think can be remedied relatively simply. That's a reasonable idea, but I was trying to point out that your proposed remedy, if implemented as you described, won't work. This makes it a keep it working issue. But let me ask this: On Sat Aug 09 09:37:49 2008, doughera wrote: On Sat, 9 Aug 2008, James Keenan via RT wrote: For example, how can you know which compiler flags to suggest if you don't even know which compiler you're using yet? Do you believe that the search for the C compiler (and, presumably, related things like the linker) should be moved earlier in the configuration process? It's probably ok where it is. It's the dependency flow that's tricky. The hints files need to come very early -- before the compiler searching. (For example, you can't know whether to consider xlc_r unless you already know you're on the appropriate version of AIX.) After the hints file, you can get the compiler. However, now that you know the compiler, you can *apply* information from the hints file. That's what triggers do. So the information flow is: read hints file. Note information for later use. inter::progs -- Choose compiler. Apply information stored at hint-file time. So the current order could be made to work ok, provided the hint file information was applied after the compiler was chosen. Up till at least recently, the hidden unspecified assumption was that users only made non-default choices for the compiler on the Configure.pl command line, so that the Choose compiler step actually happened at the very beginning, long before the inter::progs step. The working assumption was that no one ever changed the compiler during the interactive steps. Thus the real, effective flow of information was: Choose compiler (by Configure.pl command-line option) read hints file apply information right away at hint-file time inter::progs -- don't change anything. By removing the command line options from the hints files without adding triggers to the hints files, you're effectively proposing changing the information flow to: read hints file apply information right away at hint-file time inter::progs -- Choose compiler (by Configure.pl command-line option) -- accept hints file settings, whether they apply to this compiler or not. See the discussion in [perl #41195] for some more background and examples. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57900] solaris hints no longer work
On Wed, 13 Aug 2008, Andrew Johnson via RT wrote: On Wed Aug 13 10:41:22 2008, [EMAIL PROTECTED] wrote: Does this patch help? Almost, you just missed the executable itself (-o arg). This patch works for me. [patch using test_$$ everywhere] That looks like it should work, but it feels like we're cheating a little bit too. We're relying on special knowledge of how cc_gen works internally. I'd think that a better solution might be to have cc_gen() return what name it actually generated, and then explicitly use that name as an argument to the build and run commands. But for now, this at least should work, which is better than it was! Thanks, -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41508] [BUG] Configure losing flags...
On Sat, 9 Aug 2008, James Keenan via RT wrote: Last weekend tetragon and I had considerable discussion on #parrot about this problem. My diagnosis was that we should not be handling command-line options at all in 'hints' files; they should be handled in inter::progs. I didn't see any of this discussion, so I apologize if this was discussed already. Moving command-line options out of the hints files probably means more hints files should use triggers. For example, how can you know which compiler flags to suggest if you don't even know which compiler you're using yet? I think using triggers is a good idea anyway, but it's generally not implemented. (And my last patch to try implementing it for dec_osf was rejected, so don't look at me.) In perl5's Configure, we've found that users sometimes want to do different things to hints file settings. Sometimes they want to completely replace the hints file setting; other times they want to augment that setting. As a result, Configure offers a rich array of options to deal with hints. I've included below the output of sh Configure -h. Note, in particular, the variety of options available with the -A option. I think parrot would ultimately benefit from some similar sort of flexibility. Note that I'm not saying parrot has to use the identical syntax, only that perl5 users have found at least some of these features useful. Thus before implementing and testing a change, it might be worthwhile to specify and document what the overall intended behavior is. For example, how does one override a hints file setting? How does one augment a hints file setting? Lastly, note that these questions are not specific to ccflags or any other inter::progs variable. They could apply to *any* variable determined by Configure. Usage: Configure [-dehrsEKOSV] [-f config.sh] [-D symbol] [-D symbol=value] [-U symbol] [-U symbol=] [-A command:symbol...] -d : use defaults for all answers. -e : go on without questioning past the production of config.sh. -f : specify an alternate default configuration file. -h : print this help message and exit (with an error status). -r : reuse C symbols value if possible (skips costly nm extraction). -s : silent mode, only echoes questions and essential information. -D : define symbol to have some value: -D symbol symbol gets the value 'define' -D symbol=value symbol gets the value 'value' common used examples (see INSTALL for more info): -Duse64bitintuse 64bit integers -Duse64bitalluse 64bit integers and pointers -Dusethreads use thread support -Dinc_version_list=none do not include older perl trees in @INC -DEBUGGING=none DEBUGGING options -Dcc=gcc choose your compiler -Dprefix=/opt/perl5 choose your destination -E : stop at the end of questions, after having produced config.sh. -K : do not use unless you know what you are doing. -O : let -D and -U override definitions from loaded configuration file. -S : perform variable substitutions on all .SH files (can mix with -f) -U : undefine symbol: -U symbolsymbol gets the value 'undef' -U symbol= symbol gets completely empty e.g.: -Uversiononly -A : manipulate symbol after the platform specific hints have been applied: -A append:symbol=value append value to symbol -A symbol=value like append:, but with a separating space -A define:symbol=value define symbol to have value -A clear:symbol define symbol to be '' -A define:symbol define symbol to be 'define' -A eval:symbol=value define symbol to be eval of value -A prepend:symbol=value prepend value to symbol -A undef:symbol define symbol to be 'undef' -A undef:symbol= define symbol to be '' e.g.: -A prepend:libswanted='cl pthread ' -A ccflags=-DSOME_MACRO -V : print version number and exit (with a zero status). -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41508] [BUG] Configure losing flags...
On Fri, 1 Aug 2008, Will Coleda wrote: On Thu, Jul 31, 2008 at 7:44 PM, James Keenan via RT [EMAIL PROTECTED] wrote: Are you still experiencing these problems? The problem is still there. Note that the problem isn't can't find GMP[1], but that configure is ignoring the --ccflags argument. Right. The problem is still exactly the same -- the hints file is still unconditionally overwriting ccflags. Since that hasn't changed, the problem is still there. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #41508] [BUG] Configure losing flags...
On Fri, 1 Aug 2008, James Keenan via RT wrote: On Fri Aug 01 07:31:55 2008, doughera wrote: Right. The problem is still exactly the same -- the hints file is still unconditionally overwriting ccflags. Since that hasn't changed, the problem is still there. Okay. When I was writing tests for the config step classes, I never went down to the level of the hints packages. If I apply the same refactor-and-test approach I applied to the steps themselves, I think I can flush the problem out. I'm not sure what there is to flush out. There's one line in the hints file that has $ccflags = . . . . That's the line that's wrong. It obviously doesn't honor any command-line flags. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57386] Configure.pl tests create bad dirs in $TMP
On Wed, 30 Jul 2008, James Keenan via RT wrote: On Tue Jul 29 11:08:30 2008, doughera wrote: After running the Configure.pl test suite, I'm seeing some annoying-to-remove directories staying behind in /tmp. $ ls -lR /tmp/qdEG6yqmCn/ qdEG6yqmCn/: total 16 drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/ qdEG6yqmCn/alpha: total 16 d-wxrx 2 doughera faculty 117 Jul 29 13:48 include/ qdEG6yqmCn/alpha/include: qdEG6yqmCn/alpha/include: Permission denied I don't recall writing any tests which call for such strange permissions, but I will nonetheless look into this problem. I suspect it's the icu tests. Or at least a quick 'grep' for 'alpha' and 'include' suggest it's the icu tests. -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP
On Wed, 30 Jul 2008, James Keenan via RT wrote:
On Tue Jul 29 11:08:30 2008, doughera wrote:
After running the Configure.pl test suite, I'm seeing some
annoying-to-remove directories staying behind in /tmp.
$ ls -lR /tmp/qdEG6yqmCn/
qdEG6yqmCn/:
total 16
drwxr-xr-x 3 doughera faculty 181 Jul 29 13:48 alpha/
qdEG6yqmCn/alpha:
total 16
d-wxrx 2 doughera faculty 117 Jul 29 13:48 include/
qdEG6yqmCn/alpha/include:
qdEG6yqmCn/alpha/include: Permission denied
I don't recall writing any tests which call for such strange
permissions, but I will nonetheless look into this problem.
Ahh -- it's just an octal/decimal mix-up. Here's the patch:
--- parrot-current/t/steps/auto_icu-01.t2008-07-30 13:45:19.0
-0400
+++ parrot-andy/t/steps/auto_icu-01.t 2008-07-30 14:15:44.0 -0400
@@ -228,7 +228,7 @@
my $expected_include_dir =
$expected_dir . $conf-data-get('slash') . q{include};
mkdir $expected_dir or croak Unable to make testing directory;
-mkpath($expected_include_dir, 0, 755)
+mkpath($expected_include_dir, 0, 0755)
or croak Unable to make second-level testing directory;
($icuheaders, $without) =
$step-_handle_icuheaders($conf, qq{$expected_dir\n}, 0);
Mind you, the directories still aren't cleaned up automatically, but this
at least makes that less tedious.
--
Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Re: [perl #57386] Configure.pl tests create bad dirs in $TMP
On Wed, 30 Jul 2008, chromatic wrote:
On Wednesday 30 July 2008 11:20:33 Andy Dougherty wrote:
Ahh -- it's just an octal/decimal mix-up. Here's the patch:
--- parrot-current/t/steps/auto_icu-01.t2008-07-30 13:45:19.0
-0400 +++ parrot-andy/t/steps/auto_icu-01.t 2008-07-30 14:15:44.0
-0400 @@ -228,7 +228,7 @@
my $expected_include_dir =
$expected_dir . $conf-data-get('slash') . q{include};
mkdir $expected_dir or croak Unable to make testing directory;
-mkpath($expected_include_dir, 0, 755)
+mkpath($expected_include_dir, 0, 0755)
or croak Unable to make second-level testing directory;
($icuheaders, $without) =
$step-_handle_icuheaders($conf, qq{$expected_dir\n}, 0);
Mind you, the directories still aren't cleaned up automatically, but this
at least makes that less tedious.
Good catch. Does this revision of the patch perform the cleanup
appropriately?
Yes, but we might as well clean up the other two cases as well. So this
goes on top of yours:
--- parrot-svn/t/steps/auto_icu-01.t2008-07-30 15:05:43.0 -0400
+++ parrot-x86/t/steps/auto_icu-01.t2008-07-30 15:06:34.0 -0400
@@ -193,7 +193,7 @@
my $cwd = cwd();
{
-my $tdir = tempdir();
+my $tdir = tempdir( CLEANUP = 1);
chdir $tdir or croak Unable to change to temporary directory;
my $expected_dir = q{alpha};
my $expected_include_dir =
@@ -207,7 +207,7 @@
}
{
-my $tdir = tempdir();
+my $tdir = tempdir( CLEANUP = 1);
chdir $tdir or croak Unable to change to temporary directory;
my $expected_dir = q{alpha};
my $expected_include_dir =
--
Andy Dougherty [EMAIL PROTECTED]
Re: Parrot_sprintf_c question.
On Mon, 28 Jul 2008, Peter Gibbs wrote:
- Original Message - From: Will Coleda [EMAIL PROTECTED]
To properly support $tcl_precision in tcl, I need to change how I'm
currently implementing {$tcl_precision == 0}. Right now, I just fake
A few points to ponder.
1) The default precision for %g in C is 6 significant digits, i.e. 1.57080
(but sprintf drops trailing zeroes)
2) 1.5707963267948966 actually corresponds to 17-digit precision (which is the
limit for double), not 16
3) tcl uses its own special handling for tcl_precision = 0, refer to
http://www.tcl.tk/cgi-bin/tct/tip/132.html for more information
4) Look at David Gay's code (see http://www.netlib.org/fp/index.html,
specifically gdtoa) for similar logic
5) Although I haven't looked, the tcl source code must contain their actual
implementation
I don't know whether we expect enough usage of Parrot in mathemetical circles
to be worthwhile adding one of these implementions to our version of sprintf.
Perl5 certainly gets used in situations where such issues are relevant.
Every time we make a change that affects that last digit, we receive bug
reports about it.
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56716] [TODO]: speed up the configure tests
On Tue, 29 Jul 2008, James Keenan via RT wrote: For those of you who are interested in benchmarking the difference, I recommend you do a checkout of the parallel branch and run 'perl Configure.pl --test=configure', as I've included a line reporting the elapsed time. Then do a fresh checkout from trunk, copy the version of lib/Parrot/Configure/Options/Test.pm found in 'parallel' into trunk and running Configure.pl there in the same way. Since, as I said in a previous post, there is considerable variance in the time Configure.pl takes, you should probably configure in each branch 3 times to get a good idea of any speed improvements. The parallel branch does seem to run in about half the time. This is with perl-5.8.8 on Solaris/SPARC, where perl was built with Sun's cc, but I'm trying to build parrot with gcc. Here are the particulars. trunk: Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_warnings-01.t 255 6528021 12 16-21 t/steps/auto_warnings-02.t 255 6528020 10 16-20 t/steps/auto_warnings-03.t 255 6528020 10 16-20 t/steps/auto_warnings-04.t 255 6528021 12 16-21 t/steps/auto_warnings-05.t 255 6528021 12 16-21 t/steps/auto_warnings-06.t 255 6528022 14 16-22 t/steps/auto_warnings-07.t 255 6528021 12 16-21 t/steps/auto_warnings-08.t 255 6528022 14 16-22 16 tests and 1 subtest skipped. Failed 8/287 test scripts. 48/3945 subtests failed. Files=287, Tests=3945, 910 wallclock secs (388.00 cusr + 84.00 csys = 472.00 CPU) branches/parallel: Failed TestStat Wstat Total Fail List of Failed --- t/steps/auto_snprintf-01.t 255 6528038 34 22-38 t/steps/auto_warnings-01.t 255 6528056 80 17-56 t/steps/inter_progs-01.t255 6528044 56 17-44 1 test and 67 subtests skipped. Failed 3/133 test scripts. 85/3331 subtests failed. Files=133, Tests=3331, 533 wallclock secs (202.64 cusr + 42.48 csys = 245.12 CPU) The new-looking failures all look like this: t/steps/inter_progs-01...Can't store CODE items at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/_freeze.al) line 339, at lib/Parrot/Configure.pm line 509 # Looks like you planned 44 tests but only ran 16. # Looks like your test died just after 16. dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 17-44 Failed 28/44 tests, 36.36% okay -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #43302] [TODO] config/gen/makefiles.pm: Write unit tests
On Sat, 26 Jul 2008, James Keenan via RT wrote:
In the course of working on unit tests in the 'parallel' branch, I came
across this inline comment in config/gen/makefiles.pm:
# Why is this here? I'd think this information belongs
# in the CFLAGS.in file. -- A.D. March 12, 2004
if ( $conf-data-get('cpuarch') =~ /sun4|sparc64/ ) {
# CFLAGS entries must be left-aligned.
print {$CFLAGS} EOF;
src/jit_cpu.c -{-Wcast-align}# lots of noise!
src/nci.c -{-Wstrict-prototypes} # lots of noise!
EOF
}
My guess is that this code is not found in the CFLAGS.in template file
because it is platform-specific. There is no platform- or OS-specific
code in CFLAGS.in.
The comment was a thought about what ought to be, not a statement about
what is. Just because there is no platform-specific code in CFLAGS.in
today doesn't mean that there shouldn't be. If there is a need to make
any kind of adjustments to the CFLAGS file, I think that the logical place
to make them is in CFLAGS.in. Certainly that's where I would look first.
So, is there any reason why we shouldn't delete the comment?
Yes. The comment correctly points out an organizational weakness in the
generation of configure files. I'd say that's worthy of a brief comment
of some sort, though, obviously, one could word it in many different ways.
That said, the first additional line (for src/jit_cpu.c) is no longer
relevant, since JIT on the SPARC hasn't worked for years anyway. I don't
know if the second one is relevant any more, though I'd be surprised if it
were truly a SPARC-specific issue.
So another reasonable possibility is to just delete that whole section of
code and make no sparc-specific changes to CFLAGS.
--
Andy Dougherty [EMAIL PROTECTED]
Re: 'make' concludes noisily on Darwin
On Fri, 18 Jul 2008, James E Keenan wrote: Parrot has been building successfully, albeit slowly, for me on Darwin for several months now. But I must say that the very last line of 'make' output always shows a lot of warnings of multiple definitions of symbol. Can anyone evaluate these? Thanks. /usr/bin/g++ -o pbc_merge \ src/pbc_merge.o \ src/parrot_config.o \ src/string_primitives.o \ -L/Users/jimk/work/parrot/blib/lib -L/Users/jimk/work/parrot/blib/lib -lparrot -lm -lgmp -lreadline -framework OpenGL -framework GLUT -lcrypto -lintl -undefined dynamic_lookup -L/sw/lib /usr/bin/ld: warning multiple definitions of symbol _str_dup src/string_primitives.o definition of _str_dup in section (__TEXT,__text) /Users/jimk/work/parrot/blib/lib/libparrot.dylib(string_primitives.o) definition of _str_dup [more similar warnings omitted] The problem is that src/string_primitives.o is being included twice: It is already included in libparrot.dylib, but it is also being included explicitly on the link line. That strikes me as quite odd. I suspect the explicit linking to src/string_primitives.o can be omitted when building pbc_merge. The other odd thing about this link line is the trailing -L/sw/lib at the very very end. That's odd. Usually, the -L flags go *before* the libraries. It may be that Darwin's linker is insensitive to such details, but, parrot shouldn't assume that all linkers are similarly insensitive. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56928] [TODO]: Remove config step auto::pack
On Fri, 18 Jul 2008, James Keenan via RT wrote:
On Fri Jul 18 08:22:48 2008, doughera wrote:
Oh yes -- I did remember one other. Configure.pl currently offers you
the
opportunity to specify different sizes for opcode_t and INTVAL. However,
parrot itself assumes they are the same size. (See [perl #56810] for a
little more background.)
This is outside my area of competence, but I suspect the relevant code
is this part of config/inter/types.pm:
sub runstep {
my ( $self, $conf ) = @_;
my $intval = $conf-options-get('intval') || 'long';
my $floatval = $conf-options-get('floatval') || 'double';
my $opcode = $conf-options-get('opcode') || 'long';
if ( $conf-options-get('ask') ) {
$intval = prompt( \n\nHow big would you like your integers to
be?, $intval );
$floatval = prompt( And your floats?,
$floatval );
$opcode = prompt( What's your native opcode type?,
$opcode );
print \n;
}
$conf-data-set(
iv = $intval,
nv = $floatval,
opcode_t = $opcode
);
return 1;
}
Would you care to submit a patch? Thanks.
I just had something trvial in mind, perhaps like this (completely
untested). It still allows the choice via command line options (which
need a reworking, so I didn't touch them) but defaults to using the same
size for both.
--- prompt.orig 2008-07-21 08:46:34.0 -0400
+++ prompt.new 2008-07-21 08:46:24.0 -0400
@@ -3,17 +3,15 @@
my $intval = $conf-options-get('intval') || 'long';
my $floatval = $conf-options-get('floatval') || 'double';
-my $opcode = $conf-options-get('opcode') || 'long';
if ( $conf-options-get('ask') ) {
$intval = prompt( \n\nHow big would you like your integers to
be?, $intval );
$floatval = prompt( And your floats?,
$floatval );
-$opcode = prompt( What's your native opcode type?,
- $opcode );
print \n;
}
+my $opcode = $conf-options-get('opcode') || $intval;
$conf-data-set(
iv = $intval,
More generally, I was just making my usual rant that prior to extensive
refactoring or testing of any file, it makes sense to consider whether the
existing behavior is even worth refactoring or testing. (Specifically,
I'm thinking about the auto/pack.pm stuff. This opcode_t stuff is more
subtle, but it came up recently in another context, so I thought I'd
mention it.)
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56928] Failing tests in t/steps/auto_pack-01.t
On Mon, 14 Jul 2008, Andy Dougherty wrote: On Mon, 14 Jul 2008, James Keenan via RT wrote: 3. Are there any other configuration steps which are no longer needed? Well, I proposed eliminating the attributes and warnings tests, but I was overruled on that. Other than those, nothing occurs to me off the top of my head. Oh yes -- I did remember one other. Configure.pl currently offers you the opportunity to specify different sizes for opcode_t and INTVAL. However, parrot itself assumes they are the same size. (See [perl #56810] for a little more background.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu, 17 Jul 2008, Christoph Otto via RT wrote: On Thu Jul 17 15:53:12 2008, julianalbo wrote: On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: trick. The attached patch (v5) properly fixes the problem on my system. There shouldn't be any remaining issues, but the patch ought to be tested on a another *nix and Windows. [ . . . ] char *errstr = strerror_r(errno, errmsg, ERRBUF_SIZE); Unfortunately, that's not portable. The POSIXy version of strerror_r returns an integer, specifically 0 if successful, and something else otherwise. (What that something else actually is seems to be defined differently by different vendors, alas. OpenBSD and Solaris return errno. Linux/glibc returns -1.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
On Wed, 16 Jul 2008, Andrew Whitworth via RT wrote: Is this still not resolved? This ticket has not seen any discussion since 2006. To double-check, I think we need people to check t/op/trans.t on: *Solaris *OpenBSD *NetBSD *Cygwin If it passes all these platforms, I think the ticket is resolved. If not, maybe we need to break this into more-specific sub-tickets for each failing platform. It still fails in the identical way on Solaris 8/SPARC with gcc. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56928] Failing tests in t/steps/auto_pack-01.t
On Mon, 14 Jul 2008, James Keenan via RT wrote: On Mon Jul 14 10:55:35 2008, doughera wrote: Some of the new tests for auto::pack fail for me: t/steps/auto_pack-01.t4 1024334 12.12% 14-17 1. This is a test that I wrote, so I would be interested in at least knowing which OS, platform, C-compiler combination you were using here. It might help me write better tests in the future. This was on OpenSolaris /x86 using Sun's compiler and Sun's pre-built perl (which, if memory serves, is 5.8.4 and was built using -Duse64bitint). Rather than exhaustively testing the existing behavior of config/auto/pack.pm, it would have been worthwhile to first to consider whether the existing behavior was worth maintaining. A quick examination shows that the config step is determing types for the perl pack function, but these types are never used anywhere. They haven't been used for years. 2. Apart from deleting the step, then running 'make' and 'make test', is there any other way to demonstrate that these types are not used? Yes. Look at the Config variables that are set, and then grep for them in the source tree. You'll find they are never used. There was also a recent thread on the mailing list [perl #56484] that brought up a closely-related issue. 3. Are there any other configuration steps which are no longer needed? Well, I proposed eliminating the attributes and warnings tests, but I was overruled on that. Other than those, nothing occurs to me off the top of my head. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56810] [CAGE] pf_items assumes sizeof(INTVAL) == sizeof(opcode_t)
On Thu, 10 Jul 2008, Andrew Whitworth wrote: I found this while tracking a nasty GC-related bug. In src/packfile/pf_items.c:PF_fetch_integer, we have the following two notes: XXX assumes Csizeof (INTVAL) == sizeof (opcode_t) - we don't have INTVAL size in the PackFile header XXX assume sizeof (opcode_t) == sizeof (INTVAL) on the machine producing this PBC This raises the question, are the two always defined to be the same (which makes this a non-issue), or are there platforms where they are different? I suspect a fix would not be too too difficult if they aren't always the same, and if the behavior wasn't already implemented elsewhere. I'm pretty sure that a very very long time ago, the configuration sizeof(INTVAL) != sizeof(opcode_t) worked (or at least worked about as well as any other configuration). The two types have logically different roles, and so different sizes worked. However, both types ought to be a flavor of integer that is at least 32 bits and that is efficient on the system running parrot. Practically speaking, that means both probably ought to be the same size, and, indeed, that's probably the only case that anyone ever runs. Consequently, I suspect having different sizes probably hasn't worked for years. Curiously, though, Configure.pl does offer the option of picking different sizes, and doesn't warn about it. Configure.pl *does* warn if sizeof(INTVAL) != sizeof(void *). Thus while it's probably generally true that sizeof(opcode_t) == sizeof(INTVAL), it's not enforced at the Configure.pl level. In sort, it certinaly shouldn't be hard to include INTVALSIZE in the PackFile header, but you can also probably temporarily stick an assert() in there along with a note that perhaps Configure.pl ought to enforce this equality. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56716] speed up the configure tests
On Tue, 8 Jul 2008, Jerry Gay wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #56716] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56716 the configure tests take too much time to run, and should be sped up by whatever means necessary so as to take a much smaller percentage of the overall time for the test suite. from the looks of it, there's a lot of setup and teardown in each step test file that requires the same code to be repeated. To give some sense of scale: On my aging-but-busy Solaris 8/SPARC system, the configure tests take about 15 minutes to run, and account for about 1/4 of the total run time for 'make test'. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #51652] [PATCH] Possible alignment issues with new STRING structures
On Mon, 7 Jul 2008, Andrew Whitworth via RT wrote: On Thu Mar 13 18:06:21 2008, doughera wrote: I don't know if those calculations are still correct, now that strings are not bufferlike. Most of the memory management code uses a cast to (Buffer *) or (PObj *) to test a generic object's flags field. So long as a particular item's flag field can be found in this method, the alignment of the rest of the item should neither be assumed nor expected. To that end, I would say that strings are indeed bufferlike because you can cast them to a buffer to test for the flags field. Maybe it's worthwhile for us to test the offset values of the flags field for each type of item (string, buffer, pobj, pmc, stack_chunk_t) to ensure they are properly aligned and interchangable, as the memory system treats them. But each of those types explicitly starts with the same two elements UnionValcache; Parrot_UInt flags; so no casting is necessary to find the flags. Why do you need to do any casting at all? Now I'd certainly agree that this requirement should be documented in the pobj.h and stacks.h header files, and I could easily imagine either a 'coding-standard' type test (as part of Cmake test) or a series of asserts() somewhere in the parrot runtime to ensure that the structures are as claimed, but for now, I think that if there's a problem finding the flags, it's likely a side effect of a problem elsewhere. My original post that started this thread had to do with interchanging the position of the 'strstart' and 'bufused' elements in the parrot_string_t structure. In principle, that shouldn't matter at all. In practice, it caused parrot to die with an alignment error. I could well believe that the alignment error was a consequence of some other error, and using the word 'alignment' in the Subject line might, in hindsight, have been misleading. However, the error went away if you padded the string structure with an extra element, so it does indeed smell like an alignment assumption somewhere. My first guess was that calculations involving sizeof(Buffer) were now questionable, but that was just a guess. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #51652] [PATCH] Possible alignment issues with new STRING structures
On Mon, 7 Jul 2008, Andrew Whitworth via RT wrote: On Thu Mar 13 18:06:21 2008, doughera wrote: I don't know if those calculations are still correct, now that strings are not bufferlike. Most of the memory management code uses a cast to (Buffer *) or (PObj *) to test a generic object's flags field. So long as a particular item's flag field can be found in this method, the alignment of the rest of the item should neither be assumed nor expected. To that end, I would say that strings are indeed bufferlike because you can cast them to a buffer to test for the flags field. Maybe it's worthwhile for us to test the offset values of the flags field for each type of item (string, buffer, pobj, pmc, stack_chunk_t) to ensure they are properly aligned and interchangable, as the memory system treats them. The casting you refer to should be fine, since all the structures in question are isomorphic (at least for the first few elements). So casting to (Buffer *) to find the flags is fine. The particular calculations I was referring to are ones that involve using sizeof(Buffer), when the objects in question no longer have a Buffer. In terms of testing offsets, yes, I could see generating a file that was compiled and run at Configure.pl time that verified that structures look like we think they look. I suspect it would pass just fine. My worry was more related to memory constructs that are not explicit structures, but that are managed by hand (e.g. the refcount in src/resources.c). -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: [perl #56484] Re: The long long and The Short of It
On Mon, 30 Jun 2008, chromatic wrote: On Mon, Jun 30, 2008 at 3:55 PM, Ron Blaschke [EMAIL PROTECTED] wrote: Given a regular x86 (GNU/Linux) box, using GCC 4.2.3, should the following produce a working Parrot, using 64-bit ints? perl Configure.pl --intval=long long int --opcode=long long int If fails for me on Cmake while building PGE. ../../parrot -o PGE.pbc --output-pbc PGE.pir ../../parrot ../../runtime/parrot/library/PGE/Perl6Grammar.pir --output=PGE/builtins_gen.pir PGE/builtins.pg make[1]: *** [PGE.pbc] Segmentation fault make[1]: *** Deleting file `PGE.pbc' Ron, do you get any warning messages during Configure? I see: Figuring out how to pack() Parrot's types...Configure.pl: Unable to find a functional packtype for intvalsize. 'q' failed: Invalid type 'q' in pack at config/auto/pack.pm line 62. That's an irrelevant historical artifact. A very long time ago, parrot used perl to create packfiles (now known as .pbc files), and so had to have a way to pack INTVALs and opcodes. If your perl is not natively 64-bit and is not configured with 64-bit integers (e.g. configured with Csh Configure -Duse64bitint, then you will see this warning. Since parrot doesn't use perl to create packfiles, this warning is irrelevant. I have no idea why Configure.pl still probes for it. There are also plenty of build warnings, such as: src/headers.c: In function ‘Parrot_destroy_header_pools’: src/headers.c:912: warning: cast to pointer from integer of different size It's certainly possible that casting from a 64-bit integer down to a 32-bit pointer could cause a problem, though if the integer involved is small, then there shouldn't be a problem. More generally, though, I don't think this configuration has worked for a very long time. Looking back at my (very incomplete) archives, the last success I had with this configuration was on Dec 19, 2002. There is a very old ticket [perl #18189] on this issue too. There are some remarks in there that might still be relevant. (Odd. That ticket seems to be marked resolved, though I thought by replying to it I would have reopened it.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #56012] ccs make on solaris 8
On Wed, 18 Jun 2008, [EMAIL PROTECTED] (via RT) wrote:
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #56012]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56012
Hi,
I have a bug using ccs make (/usr/ccs/bin/make). The following error
happens when I run make.
NOTE: /usr/xpg4/bin/make succeeds on the same host
$PATH =
/usr/openwin/bin:/opt/perl588/bin:/bin:/usr/bin:/opt/boksm/bin:/opt/perl588/site/git-1.5.5/bin:/opt/perl588/site/postgres/bin:/opt/SUNWspro/bin:/usr/ccs/bin
uname -a == SunOS cmtnoc5-mx45 5.8 Generic_117350-38 sun4u sparc
SUNW,Sun-Fire-V490
[irrelevant lines deleted]
mksh: Fatal error in reader: Loop detected when expanding macro value
`$(PERL) -e 'chdir shift @ARGV; system q{$(MAKE)}, @ARGV; exit $$? 8;''
Current working directory /home/j911649/PARROT/solaris8
Odd. I've built parrot numerous times with /usr/ccs/bin/make and have
never seen this problem. There's even specific code in _set_make_c in
config/inter/make.pm to avoid it:
# RT#43171 this is an ugly hack
# replace the value for $(MAKE) with the actual path or we'll end up
# with a variable that recursively refers to itself
$make_c =~ s/\$\(MAKE\)/$prog/;
$conf-data-set( make_c = $make_c );
One way to reproduce this problem is to set an environment
variable named 'MAKE' to point to a program that is not in your $PATH.
For example (this is /bin/sh syntax; I don't recall the csh equivalent)
MAKE=/bin/bogus perl Configure.pl
will give the result you see. It's not at all clear to me what the author
of make.pm actually intended in such a case, so I'm hesitant to offer
a patch. Normally, I'd say a workaround would be to explicitly supply
a --make=/usr/ccs/bin/make argument on the Configure.pl command line,
but make.pm deliberately chooses to prefer the environment to a command
line option. Again, I don't know why, and it seems backwards to me,
but I'm reluctant to suggest changing it in case it was deliberate.
More generally, the default MAKE setting ought not to be recursive. I
really don't know why that variable is called MAKE instead of something
like MAKE_C. Using MAKE_C would eliminate the recursive issue without
the ugly hack.
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #39742] [BUG] installed parrot conflicts with dev parrot.
On Sat, 14 Jun 2008, James Keenan via RT wrote: Can we get an update as to the issues raised in this ticket? The general issue installeld parrot conflicts with dev parrot -- at least when a shared libparrot.so is used is, as far as I know, unsolved. A longer discussion can be found here (and the surrounding thread): http://www.nntp.perl.org/group/perl.perl6.internals/2006/03/msg33340.html -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Re: [perl #44379] config/auto/attributes.pm ought to use its own test_c.in
On Sat, 14 Jun 2008, chromatic via RT wrote: On Tuesday 07 August 2007 10:11:20 Andy Dougherty wrote: This next patch does a little more cleanup on the attributes checking. I revised config/auto/attributes.pm to use the existing Configure routines cc_build() and conf-data_add() rather than re-implementing them. I also removed some now unnecessary #includesparrot/compiler.h statements and cc_inc fiddling in config/init/hints/solaris.pm I've applied everything but the attributes.pm part as r28365, because there was some fuzz and my best approach to getting it to work disabled attribute detection from me. (That's what I get for not applying patches much more frequently; sorry!) I'd take a new patch for the latter, if you're interested. Thanks for the offer. However, given that the related ticket [perl #44381] was rejected, I'm not inclined to invest more effort in attribute detection. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #40059] [CAGE] Fix symbol table namespace pollution
On Sun, 8 Jun 2008, James Keenan via RT wrote: On Thu Aug 03 11:58:02 2006, chip wrote: Extern functions and variables must have names that begin with CParrot. Do we indeed have any extern functions or variables whose names do not begin with CParrot? How would one determine this? Could this be converted into a coding standards test? On a Unix-like system, you can use nm(1) to look at blib/lib/libparrot.a. (The appropriate options are system-dependent, but 'nm -p' is usually a good bet.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #47395] [BUG] [PATCH] t/configure/115-auto-warnings.t assumes cc -Wall works.
On Thu, 5 Jun 2008, Will Coleda via RT wrote: On Tue Jan 15 20:08:22 2008, [EMAIL PROTECTED] wrote: Patches applied to trunk in r24898. Can we close this ticket if the patches are applied? Yes, this one can be closed. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #37819] [PATCH] Sun4 builds fail linking against jit.o
On Thu, 5 Jun 2008, Will Coleda via RT wrote: On Tue May 15 14:54:01 2007, [EMAIL PROTECTED] wrote: On Wednesday 09 May 2007 07:21:44 Andy Dougherty wrote: [appending to an old ticket, since if anyone wants to ever get this working again, they'll probably have to fix up the blind guesses I made in that old patch too.] Thanks, applied as r18562 (er, oops -- r18561, due to an excruciatingly slow commit). -- c If the patch is applied, is this ticket safe to close now? No. It's still the case that the sun4/SPARC jit is broken. The patch just documented two things: which specific function does not exist, and which other broken functions also need to be fixed. However, realistically, I don't think anyone's ever going to fix the SPARC jit, so you may certainly mark it as stalled or whatever else seems to suit. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #37819] [PATCH] Sun4 builds fail linking against jit.o
On Fri, 6 Jun 2008, Steve Peters wrote: On Fri, Jun 6, 2008 at 8:12 AM, Andy Dougherty [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008, Will Coleda via RT wrote: If the patch is applied, is this ticket safe to close now? No. It's still the case that the sun4/SPARC jit is broken. The patch just documented two things: which specific function does not exist, and which other broken functions also need to be fixed. However, realistically, I don't think anyone's ever going to fix the SPARC jit, so you may certainly mark it as stalled or whatever else seems to suit. Is it only sun4/SPARC that's broken or are all Solaris/SPARC's also broken? I would guess that if its all SPARCs, Linux or Solaris, that this might be a bigger issue. It's all SPARCs -- Solaris, Linux, and *BSD -- for which parrot's jit is broken. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #54992] [CAGE] Add a 'codetest' make target
On Fri, 30 May 2008, James Keenan via RT wrote: That will probably be possible. But as I was staring at config/gen/makefiles/root.in, I couldn't figure out where $(PARROT_ARGS) is originally defined in line such as this: test : test_prep $(PERL) t/harness $(EXTRA_TEST_ARGS) $(PARROT_ARGS) So can anyone identify the source of $(PARROT_ARGS)? I believe that it was originally intended as a mechanism for the end user to pass additional arguments to the parrot executable. For example, make test PARROT_ARGS=-D40 (though that -D40 has been useless for a couple of years now) Alas, I suspect it probably doesn't generally work. I seem to recall that t/harness doesn't pass through unrecognized arguments, so something sensible-looking like make test PARROT_ARGS='--runcore=gcdebug' won't actually work. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #54920] [PATCH] Compiling pcc.c on Solaris10-x86
On Wed, 28 May 2008, Andrew Johnson wrote: tiger% ./parrot -t t/dynoplibs/myops_3.pir 0 print neither here\n neither here 2 hcf Segmentation fault Welcome to the club of people who've wasted time chasing this particularly silly test. 'hcf' is supposed to stand for 'halt and catch fire'. I gather it was supposed to be funny. The immediate problem is that the test suite doesn't handle all the possible ways that this operation could crash parrot. For example, as happened here, the process might simply hang and need to be killed. Here's an earlier set of postings about just this same problem: http://groups.google.com/group/perl.perl6.internals/browse_thread/thread/73c18b45ff002077 At a minimum, the test should be deleted. More generally, there is no guarantee what the system will actually do when presented with the code int *a, i; a = NULL; i = *a; The actual result you get will depend on the compiler, the optimization level, and the runtime environment. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Rearrange PObj Struct Members
On Sun, 27 Apr 2008, chromatic wrote:
Here's another proposed patch for testing on various platforms. I'm trying
to
get rid of some dodgy casts (which likely don't help C++ and processors with
stricter alignment than 32-bit x86). I'd also like to remove unnecessary
members from a few structs. This is the next step.
Are there any weird errors or unexpected crashes on anything more exotic than
32-bit x86 GNU/Linux?
/* Parrot Object - base class for all others */
typedef struct pobj_t {
+Parrot_UInt flags;
UnionVal u;
-Parrot_UInt flags;
} pobj_t;
On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
padding. (UnionVal will be aligned on an 8-byte boundary, but
Parrot_Uint is only 4 bytes long.) This is, of course, not an error in
and of itself, but if any of those dodgy casts assume no padding, then
there will be an error.
I'll try building, but since there are 4 permutations to try (cc and gcc,
and with and without this patch) and since each build takes 1 to 2 hours
if everything goes well, it won't be until tomorrow at the earliest that
I can report anything back. (Longer, if manual intervention is required
to fix unrelated errors.)
--
Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Rearrange PObj Struct Members
On Mon, 28 Apr 2008, chromatic wrote:
On Monday 28 April 2008 10:24:37 Andy Dougherty wrote:
On Sun, 27 Apr 2008, chromatic wrote:
/* Parrot Object - base class for all others */
typedef struct pobj_t {
+Parrot_UInt flags;
UnionVal u;
-Parrot_UInt flags;
} pobj_t;
On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
padding. (UnionVal will be aligned on an 8-byte boundary, but
Parrot_Uint is only 4 bytes long.) This is, of course, not an error in
and of itself, but if any of those dodgy casts assume no padding, then
there will be an error.
I don't believe they rely on padding, but that's why I ask.
And wisely so! I sometimes (ok, often) find it a bit hard to tell what
the underlying assumptions are.
Does 32-bit SPARC align all pointers on 8-byte boundaries?
No. It's the double inside the UnionVal cache that forces the 8-byte
alignment.
My ultimate goal is to get pobj_t down to:
typedef struct pobj_t {
Parrot_UInt flags;
void *GC_next;
} pobj_t;
That should not require any padding. So my objection about wasting space
can be ignored, since it would only be a temporary issue that would
ultimately go away.
... where GC_next is a pointer to the next pobj_t in a linked list. This'll
let us get rid of all of the dodgy casts required to maintain arena free
lists as well as to remove the UnionVal member from GCable structures that
don't need it, saving two pointers from every Stack_Chunk_t, for example.
Sounds like a worthy goal. A cache is a nice-sounding idea, but perhaps
not quite at this lowest level.
--
Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: [perl #53264] [PATCH] Re: [svn:parrot] r27144 - in trunk: include/parrot src src/pmc
On Thu, 24 Apr 2008, Andy Dougherty wrote:
On Wed, 23 Apr 2008, Andy Dougherty wrote:
2. There are some casting and type-punning warnings that have, as their
ultimate cause, the STACK_DATAP() macro. Getting rid of the
type-punning warning gives rise to a cast alignment warning.
Looking up a level, the only uses for that macro are to return
Stack_Entry_t pointers. Why not be explicit about it in the definition
in include/parrot/stacks.h? The attached patch tries to do just that.
I haven't tested this, but it looks like it ought to work.
Oops. It won't work because I missed a level of indirection.
Ok. Fixed. This version avoids both type-punning and cast alignment
warnings by declaring the 'data' element of a Stack_Chunk_t to be
of type Stack_Entry_t, since that's the only way it is ever used,
at least as far as I could tell.
Oops. I can only say I was fooled by the function signatures that these
functions returned 'void *', when they actually return 'void **'.
Now they return Stack_Entry_t *, since their return values always were
cast to that type anyway.
I have tested this on Solaris/SPARC with Sun's cc. It introduces no
new warnings or failures that I can detect. (The build actually doesn't
complete either with or without this patch, but it does get far enough
that I can run most of the core tests.)
diff -r -u parrot-x64-before/include/parrot/stacks.h
parrot-x64/include/parrot/stacks.h
--- parrot-x64-before/include/parrot/stacks.h 2008-04-23 13:58:26.0
-0400
+++ parrot-x64/include/parrot/stacks.h 2008-04-25 10:12:42.0 -0400
@@ -33,7 +33,7 @@
Parrot_UInt refcount;
union { /* force appropriate alignment of 'data'. If alignment
is necessary, assume double is good enough. 27-04-2007. */
-void *data;
+Stack_Entry_t data;
#if PARROT_PTR_ALIGNMENT 1
double d_dummy;
#endif
@@ -158,7 +158,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void* stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
+Stack_Entry_t* stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t
**stack_p))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*stack_p);
@@ -166,7 +166,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void* stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
+Stack_Entry_t* stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t
**stack_p))
__attribute__nonnull__(1)
__attribute__nonnull__(2)
FUNC_MODIFIES(*stack_p);
diff -r -u parrot-x64-before/src/stack_common.c parrot-x64/src/stack_common.c
--- parrot-x64-before/src/stack_common.c2008-04-25 07:55:48.0
-0400
+++ parrot-x64/src/stack_common.c 2008-04-25 10:12:20.0 -0400
@@ -110,7 +110,7 @@
/*
-=item Cvoid* stack_prepare_push
+=item CStack_Entry_t* stack_prepare_push
Return a pointer, where new entries go for push.
@@ -121,7 +121,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void*
+Stack_Entry_t*
stack_prepare_push(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
{
Stack_Chunk_t * const chunk = *stack_p;
@@ -138,7 +138,7 @@
/*
-=item Cvoid* stack_prepare_pop
+=item CStack_Entry_t* stack_prepare_pop
Return a pointer, where new entries are popped off.
@@ -149,7 +149,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
PARROT_CANNOT_RETURN_NULL
-void*
+Stack_Entry_t*
stack_prepare_pop(PARROT_INTERP, ARGMOD(Stack_Chunk_t **stack_p))
{
Stack_Chunk_t * const chunk = *stack_p;
diff -r -u parrot-x64-before/src/stacks.c parrot-x64/src/stacks.c
--- parrot-x64-before/src/stacks.c 2008-04-25 07:55:49.0 -0400
+++ parrot-x64/src/stacks.c 2008-04-25 10:14:06.0 -0400
@@ -60,7 +60,6 @@
mark_stack(PARROT_INTERP, ARGMOD(Stack_Chunk_t *chunk))
{
for (; ; chunk = chunk-prev) {
-void **entry_data;
Stack_Entry_t *entry;
pobject_lives(interp, (PObj *)chunk);
@@ -68,8 +67,7 @@
if (chunk == chunk-prev)
break;
-entry_data = STACK_DATAP(chunk);
-entry = (Stack_Entry_t *)entry_data;
+entry = STACK_DATAP(chunk);
if (entry-entry_type == STACK_ENTRY_PMC UVal_pmc(entry-entry))
pobject_lives(interp, (PObj *)UVal_pmc(entry-entry));
@@ -140,7 +138,6 @@
stack_entry(PARROT_INTERP, ARGIN(Stack_Chunk_t *stack), INTVAL depth)
{
Stack_Chunk_t *chunk;
-void **entry;
size_t offset = (size_t)depth;
if (depth 0)
@@ -159,9 +156,7 @@
if (chunk == chunk-prev)
return NULL;
-/* this looks bad, but it avoids a type-punning warning */
-entry = STACK_DATAP(chunk);
-return (Stack_Entry_t *)entry;
+return STACK_DATAP(chunk);
}
/*
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #53264] [PATCH] Re: [svn:parrot] r27144 - in trunk: include/parrot src src/pmc
On Wed, 23 Apr 2008, Andy Dougherty wrote: 2. There are some casting and type-punning warnings that have, as their ultimate cause, the STACK_DATAP() macro. Getting rid of the type-punning warning gives rise to a cast alignment warning. Looking up a level, the only uses for that macro are to return Stack_Entry_t pointers. Why not be explicit about it in the definition in include/parrot/stacks.h? The attached patch tries to do just that. I haven't tested this, but it looks like it ought to work. Oops. It won't work because I missed a level of indirection. -return STACK_DATAP(new_chunk); That used to return (new_chunk-u.data) +return new_chunk-u.stdata; And this returns new_chunk-u.stdata instead. Oops. I can only say I was fooled by the function signatures that these functions returned 'void *', when they actually return 'void **'. I'll try to fix that. I apologize in advance if I wasted anyone's time trying this out. (I still think my basic premise is right -- we can avoid pointer cast warnings and problems if we declare more explicitly what we wish to do.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #52818] readline detection failing (linux x86_64)
On Thu, 17 Apr 2008, James Keenan via RT wrote: On Thu Apr 17 10:51:10 2008, ambs wrote: A solution was implemented at revision 27020. They might be cases where this doesn't work. (hope not) This is what I got on Linux at r27021: Determining if your platform supports readline... [successful cc -c omitted ] cc -L/usr/local/lib -Wl,-E test.o -o test -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lreadline /usr/bin/ld: cannot find -lreadline collect2: ld returned 1 exit status But whenever I say 'sudo apt-get install libreadline5', I'm told the package is up-to-date. Debian-derived systems usually offer two packages: A run-time-only library and a development library. libreadline5 is the run-time-only version. You probably need to do sudo apt-get install libreadline5-dev (According to the notes in perl5's hints/linux.sh, Red Hat uses a similar naming convention.) -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #53034] [PATCH] Sensible error message for missing config step test
On Thu, 17 Apr 2008, Geoffrey Broadwell wrote:
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #53034]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53034
The attached small patch makes Configure give a sensible error message
when a config step has no associated test files, rather than exploding
obtusely.
+my $these_tests = $steps_tests{$temp[0]}{$temp[1]}
+or croak No tests exist for configure step $step;
Thank you. That's definitely an improvement. I know I wasted a lot
of time trying to figure out what the previous failure mode meant.
Still, why croak? Is the lack of a test really so fatal that it should be
impossible to Configure or build parrot -- even if you're just starting to
develop the configure step?
This seems to me more of the level of a coding standard warning, not a
fatal error.
--
Andy Dougherty [EMAIL PROTECTED]
Re: parrot benchmarking
If optimized builds are to be the default, however, someone needs to either hunt down and fix all the wrong attribute_null decorations, or apply a patch similar in spirit to the one I proposed in [PATCH] Re: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86 Linux) Otherwise core dumps will ensue. -- Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: build failure with gmake on Solaris
On Sun, 13 Apr 2008, James E Keenan wrote: I recently obtained shell accounts on some Solaris boxes. Today I made my first attempt to compile and build Parrot on one of them. Configuration was very smooth. See log attached. Note for reference: Determining if your platform supports GMP.yes. ... Determining if your platform supports crypto..yes, 0.9.8g. At the completion of configuration, I was prompted to use gmake to build. The build generated many warning: statement not reached messages. (See log attached.) Then the build failed completely here: /opt/SUNWspro/bin/CC -o miniparrot src/main.o \ -L/home/kid51/work/parrot/blib/lib -lparrot -lsocket -lnsl -ldl -lm -lpthread -lrt -lgmp -lcrypto -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro/prod/lib/sparc -L/opt/SUNWspro/prod/lib -L/lib -L/usr/local/lib -xlibmieee src/null_config.o ld: fatal: library -lgmp: not found ld: fatal: library -lcrypto: not found ld: fatal: File processing errors. No output written to miniparrot gmake: *** [miniparrot] Error 1 It's not clear why 'ld' failed to find gmp or crypto, because Configure.pl located them without difficulty. (Incidentally -- gmake is not necessary. I don't know why Configure.pl suggests it. You should try regular 'make' instead (you may have to add /usr/ccs/bin to your PATH). If you want to check out parallel builds, you can try 'dmake' if it's installed.) This failure is probably due to the order of the arguments to CC. Traditional Unix linkers look things up in the order specified on the command line. You don't say where libgmp and libcrypto are installed, but I'll guess they are in /usr/local/lib. The link line specified should have the -L flags before listing -lgmp -lcrypto. This untested patch probably will fix it. I didn't go through the whole Makefile; there are probably other similar instances. However, if this works, you can them apply the same strategy to other parts that break. diff -r -u parrot-current/config/gen/makefiles/root.in parrot-andy/config/gen/makefiles/root.in --- parrot-current/config/gen/makefiles/root.in Mon Apr 14 07:35:09 2008 +++ parrot-andy/config/gen/makefiles/root.inMon Apr 14 08:59:04 2008 @@ -784,8 +784,8 @@ lib/Parrot/OpLib/core.pm $(SRC_DIR)/parrot_config$(O) \ $(MINIPARROT) $(LINK) @[EMAIL PROTECTED]@ \ -$(SRC_DIR)/main$(O) @rpath_blib@ $(ALL_PARROT_LIBS) $(LINKFLAGS) $(LINK_DYNAMIC) \ -$(SRC_DIR)/parrot_config$(O) +$(SRC_DIR)/main$(O) @rpath_blib@ $(LINKFLAGS) $(LINK_DYNAMIC) \ +$(SRC_DIR)/parrot_config$(O) $(ALL_PARROT_LIBS) pbc_to_exe.pir : $(PARROT) tools/dev/pbc_to_exe_gen.pl $(PERL) tools/dev/pbc_to_exe_gen.pl \ Since this is a shell account on an OS on which I am just beginning, debugging will not be that easy for me. It appears 'svn' is not available. Suggestions? I use three different methods; each has its benefits and drawbacks, depending on details of your setup, connectivity, and what software is installed. 1. Use rsync. rsync is very useful for this, when it works. Unfortunately, the parrot rsync server tends to be a bit unreliable, but it's working today. Use something like: rsync -avz --delete svn.perl.org::parrot-HEAD parrot-current (rsync is not standard on solaris -- you'd have to build your own.) 2. Use svn on one system where you have it installed. From there, use MANIFEST to build an archive that you copy to the other system. I typically use 'scp' to do the remote copy. 3. Fetch the current snapshots with something like wget http://svn.perl.org/snapshots/parrot/parrot-latest.tar.gz (wget is not standard on solaris -- you'd have to build your own.) Note too that many of the Configure.pl problems I have reported are not Solaris-specific. Rather they result from two factors easily reproduced on other systems: 1. The hints files use callbacks. This is easily ported to other systems. Some time ago, I posted patches to implement such callbacks for Linux, for example; though other systems are just as easy to do. 2. The configuration used to build 'perl5' doesn't necessarily match the configuration available to build parrot. This too is easy to mimic elsewhere. Some time ago I also posted step by step instructions for simulating this on any other system. Some things are Solaris-specific[*], however, so Solaris testing is indeed a good idea. [*] Or, more commonly, non-GNU specific. -- Andy Dougherty [EMAIL PROTECTED]
Re: build failure with gmake on Solaris
On Sun, 13 Apr 2008, James E Keenan wrote: I recently obtained shell accounts on some Solaris boxes. Today I made my first attempt to compile and build Parrot on one of them. 'myconfig' and the output of uname are attached. [parrot] 52 $ uname -a SunOS 5.10 Generic_120011-14 sun4v sparc SUNW,Sun-Fire-T1000 I'm not familiar with this hardware, but a few of the compilation probes looked odd to me. [parrot] 53 $ cat myconfig Summary of my parrot 0.6.0 (r0) configuration: configdate='Sun Apr 13 13:52:28 2008 GMT' Platform: osname=solaris, archname=sun4-solaris-64int jitcapable=0, jitarchname=nojit, jitosname=solaris, jitcpuarch=sun4 Compiler: cc='/opt/SUNWspro/bin/cc', ccflags='-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHASATTRIBUTE_CONST -DHASATTRIBUTE_FORMAT -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED ', What version of the compiler is this? (You can check with cc -V.) I didn't know that Sun's compilers supported those attributes. Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 The ptr_alignment=1 also surprises me. SPARC chips have traditionally had ptr_alignment=4 (at least in the 32-bit mode you're using here). It may well be correct, but I'd also be tempted to look at the cc man page and see if there are any flags that could or should be set to make the compiler choose an alignment appropriate for the architecture. It may be that something like perl Configure.pl --optimize='-xtarget=native' will allow the compiler to choose the optimal alignment and it might improve performance measurably. (Or it could be that this doesn't make much of a difference anymore, the way it used to with older SPARCs.) It may also be worthwhile to run Configure.pl in verbose mode (or even run them by hand) to check how each of those alignment tests is passing. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #52712] Build broken
On Thu, 10 Apr 2008, Mark Glines via RT wrote: On Thu Apr 10 14:16:58 2008, infinoid wrote: Oddly, adding config/auto/macports.pm to MANIFEST didn't help. It is copied, but I don't think this module is getting use'd, for whatever reason. What the heck? When I added t/steps/auto_macports-*.t to MANIFEST (in r26916), it started working. Yes. The fact that lib/Parrot/Configure/Step.pm lists auto::macports implicity *assumes* that there will be corresponding tests in t/steps/auto_macports-*.t, and if there aren't, Configure bails out with a fatal error during build time. This is just really strange. For example, it makes it more difficult to develop a new step because you can't even begin to develop the new step unless you already have the tests in place. So, uh, fixed in r26916 and r26914. Though I have no idea why r26916 fixed it and r26914 didn't. Well, adding those tests works around the design oddity, but I wouldn't really call it fixed. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #43048] [BUG] imcc constant folding div by zero
On Wed, 9 Apr 2008, Will Coleda via RT wrote:
On Fri Apr 04 22:28:31 2008, [EMAIL PROTECTED] wrote:
On Thursday 03 April 2008 11:22:16 Andy Dougherty wrote:
parrot-andy/compilers/imcc/optimizer.c ---
parrot-svn/compilers/imcc/optimizer.c 2008-03-31 15:14:39.0
-0400
+++ parrot-andy/compilers/imcc/optimizer.c2008-04-03
13:14:52.0
-0400 @@ -976,8 +976,10 @@
* from the result
*/
branched = eval_ins(interp, op, found, r);
-if (branched == -1)
+if (branched == -1) {
+*ok = 0; /* XXX Is this return value sensible? */
return NULL;
+}
Sadly, this part doesn't work because of the other call to this
function.
I've applied the rest of the patch with some tweaks as r26763.
Andy, does this test pass for you now?
Yes, it should, since the initialization is now done in the calling
function. I'd be happier if the following comment-only patch were
applied, so that next time someone tries to address the deeper problem
there's at least a flag in the code about one of the question spots.
--- parrot-svn/compilers/imcc/optimizer.c Mon Apr 7 09:26:28 2008
+++ parrot-andy/compilers/imcc/optimizer.c Wed Apr 9 17:47:43 2008
@@ -980,8 +980,10 @@
* from the result
*/
branched = eval_ins(interp, op, found, r);
-if (branched == -1)
- return NULL;
+if (branched == -1) {
+/* XXX Deliberately not setting *ok. See [perl #43048] */
+return NULL;
+}
/*
* for math ops result is in I0/N0
* if it was a branch with constant args, the result is
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #52504] [PATCH]: Refactor repeated code into auto::ports
On Sat, 5 Apr 2008, James Keenan wrote: # New Ticket Created by James Keenan # Please include the string: [perl #52504] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52504 In http://rt.perl.org/rt3/Ticket/Display.html?id=51622, Alberto Sim??es and I discussed the merits of creating a new configuration step class, to be run on Darwin only, which would detect the installation of Macports in the same way that step class auto::fink detects Fink. Did you mean to call this auto::macports, or is this step intended to eventually encompass the FreeBSD-style ports collection as well. I don't know if macports is a derivative of FreeBSD ports or not. I do know that NetBSD and OpenBSD both also have a ports collection, though I think all the *BSD collections are reasonably similar. If macports is indeed similar to FreeBSD ports, then this is good step forward. If it is not, however, you might want to reserve the name auto:ports for the FreeBSD-style ports collection. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] Re: [perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Wed, 2 Apr 2008, chromatic wrote:
On Wednesday 02 April 2008 06:26:40 Andy Dougherty wrote:
This very minimal patch at leasts gives a brief warning about the issue.
+# Parrot can't necessarily handle a pre-existing installed shared
+# libparrot.so. At this point, we don't know the actual name
+# of the shared parrot library. However, 'libparrot.so' will catch
+# at least some of the problems.
+my $old_version = File::Spec-catfile($conf-data-get('libdir'),
+ 'libparrot.so');
Would the use of $Config{so} (or the configuration system's equivalent) and
possibly DynaLoader help make this more robust?
Yes. Another good catch. The undocumented variable
$conf-data-get('libparrot_shared_alias') is built using the undocumented
$conf-data-get('share_ext'), so looking for 'libparrot' .
$conf-data-get('share_ext') would the next thing to try.
You can't necessarily use the undocumented 'libparrot_shared_alias'
because it's not initialized everywhere -- only in some hints file.
--
Andy Dougherty [EMAIL PROTECTED]
[PATCH] Re: [perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Wed, 2 Apr 2008, �~Xл�~L�~O wrote:
Yep!
ls /usr/local/lib | grep 'parrot'
give my many targets for rm and after that parrot making very well. Thanks!
This very minimal patch at leasts gives a brief warning about the issue.
On a closely related topic, I thought about changing the default in this
case to not build a shared libparrot, but dealing with the combination of
undocumented Configure.pl variables and the inability to use command-line
overrides made that patch become too large a project for me to tackle
today.
--- parrot-svn/config/inter/libparrot.pm2008-03-31 15:15:42.0
-0400
+++ parrot-andy/config/inter/libparrot.pm 2008-04-02 09:20:30.0
-0400
@@ -20,6 +20,7 @@
use base qw(Parrot::Configure::Step);
use Parrot::Configure::Utils ':inter';
+use File::Spec qw(catfile);
sub _init {
@@ -41,6 +42,17 @@
$parrot_is_shared = 0 unless $conf-data-get('has_dynamic_linking');
+# Parrot can't necessarily handle a pre-existing installed shared
+# libparrot.so. At this point, we don't know the actual name
+# of the shared parrot library. However, 'libparrot.so' will catch
+# at least some of the problems.
+my $old_version = File::Spec-catfile($conf-data-get('libdir'),
+ 'libparrot.so');
+if (-e $old_version) {
+warn(\nWarning: Building a shared parrot library may conflict .
+ with your previously-installed $old_version\n);
+}
+
if (
$conf-options-get('ask')
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Wed, 2 Apr 2008, chromatic wrote: We're not seeing the problem in the parrot executable, just the pbc_to_exe executable, which makes me believe that the attached patch will fix the problem. We rearranged the linker flags for the parrot executable to avoid this a while back, so we ought to rearrange the linker flags for pbc_to_exe in the same way. Yes. Well spotted. I had leaped ahead to the next problem -- the already-installed-shared-library -- but you are quite right. This more immediate problem also needs solving. Your patch ought to do it. Thanks. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Tue, 1 Apr 2008, �~Xл�~L�~O wrote: Hi! I was done make realclean, svn up(and new checkout too), perl Cofigure.pl and new make many times before I send bug report. So, I done it again, but with same results :( Do you need any additional information about my system? anything else can help? pbc_to_exe.o: In function `main': pbc_to_exe.c:(.text+0x64): undefined reference to `Parrot_set_executable_name' collect2: ld returned 1 exit status linking failed current instr.: 'link_file' pc 769 (pbc_to_exe.pir:369) called from Sub 'main' pc 124 (pbc_to_exe.pir:32) Do you have a previously installed copy of libparrot somewhere where this version might be finding it? Specifically, looking at your link command cc -o pbc_to_exe pbc_to_exe.o -Wl,-E -L/usr/local/lib -Wl,-E -L/home/ihrd/svn/parrot/blib/lib -lparrot -Wl,-rpath=/home/ihrd/svn/parrot/blib/lib -ldl -lm -lpthread -lcrypt -lrt -lgmp -lreadline -lcrypto /home/ihrd/svn/parrot/src/parrot_config.o I see that /usr/local/lib is listed before ./blib/lib, so that an earlier copy of libparrot in /usr/local/lib might be getting picked up. I don't see the command line used to build parrot itself, but I think that the flags are in a different order so ./blib/lib comes earlier. -- Andy Dougherty [EMAIL PROTECTED]
