Re: Fwd: perl@10517 (Fail)
Ken Williams [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Jarkko Hietaniemi) wrote: Ken wrote: Looking at the GNUmakefile produced during Configure, I see this: # The following are used to build and install shared libraries for # dynamic loading. LDDLFLAGS = -bundle -undefined suppress -L/usr/local/lib SHRPLDFLAGS = -L/usr/local/lib -dynamiclib -compatibility_version 1-current_version 5.0 -image_base 0x4be0 -install_name $(shrpdir)/$@ CCDLFLAGS = DLSUFFIX = .bundle PLDLFLAGS = LIBPERL = libperl.dylib LLIBPERL= $(LIBPERL) SHRPENV = env LD_RUN_PATH=/System/Library/Perl/darwin/CORE Try commenting that line out with # and then retrying the build. Since PerlIO seems to be part of the problem, do the build like this env LD_RUN_PATH=$PWD PERLIO=stdio make all No dice, I get the same bus error as before. Jarkko's suggestion does not help directly. PERLIO=stdio is still using PerlIO infrastructure, but using stdio as the implementation. The before-interpreter-exists issue is with the infrastructure (I am using AVs and HVs in the infrastructure and the is no intepreter to anchor them in :-( - I need to re-invent a hash table and a list-of-things structure in perlio.c and use those.) ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum -- Nick Ing-Simmons who is looking for a new job see http://www.ni-s.u-net.com/
Re: Fwd: perl@10517 (Fail)
Please let me know if I should send reports to a different address. I'm sending to P5P ([EMAIL PROTECTED]) and CC-ing Jarkko and the OSX-perl list. Sounds okay. `sh cflags libperl.dylib perly.o` perly.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -I/usr/local/include -O3 perly.c: In function `Perl_yyparse': perly.c:1539: warning: suggest parentheses around assignment used as truth value Known, suspceted harmless, maybe bogus (I tried adding parentheses but couldn't make it (gcc) happy...) util.c: In function `Perl_cast_ulong': util.c:2936: warning: decimal constant is so large that it is unsigned util.c:2936: warning: decimal constant is so large that it is unsigned util.c: In function `Perl_cast_i32': util.c:2954: warning: decimal constant is so large that it is unsigned util.c:2954: warning: decimal constant is so large that it is unsigned Hmm, I wonder why no other gccs seem to care? What's the version of gcc? CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -I/usr/local/include -O3 pp_sys.c: In function `Perl_pp_system': pp_sys.c:3961: warning: variable `sp' might be clobbered by `longjmp' or `vfork' pp_sys.c:3961: warning: variable `mark' might be clobbered by `longjmp' or `vfork' Ditto, why other gccs don't pick this up? I can mark those variables as volatile to make gcc happier, but it would be nice to know why the Mac OS X gcc feels more strongly than others? [...snip...] You may see some irrelevant test failures if you have been unable to build lib/Config.pm. cd t (rm -f perl; /bin/ln -s ../miniperl perl) \ DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./perl TEST base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t pragma/*.t /dev/tty make[1]: *** [minitest] Bus error make: [extra.pods] Error 1 (ignored) DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./miniperl configpm configpm.tmp make: *** [lib/Config.pm] Bus error Ouch. This definitely isn't some irrelevant (test) failure. Could you: rm -f config.sh sh Configure -des -Dusedevel -Doptimize=-g make miniperl gdb ./miniperl (gdb) run (gdb) where -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Fwd: perl@10517 (Fail)
[EMAIL PROTECTED] (Nicholas Clark) wrote:
On Mon, Jun 11, 2001 at 03:41:57PM -0500, Jarkko Hietaniemi wrote:
util.c: In function `Perl_cast_ulong':
util.c:2936: warning: decimal constant is so large that it is unsigned
util.c:2936: warning: decimal constant is so large that it is unsigned
util.c: In function `Perl_cast_i32':
util.c:2954: warning: decimal constant is so large that it is unsigned
util.c:2954: warning: decimal constant is so large that it is unsigned
Hmm, I wonder why no other gccs seem to care? What's the version of gcc?
It's I32_MIN and IV_MIN it's complaining about. This would be a bad thing.
Could you compile and run
#include EXTERN.h
#include perl.h
int main (void) {
puts (I32_MIN='STRINGIFY(I32_MIN)');
return 0;
}
in your perl build directory please. I see this on ARM Linux:
../testit
I32_MIN='(-2147483647-1)'
which looks like a sensible way to get -2147483648
I see this on OS X:
[localhost:~/Downloads/perl] ken% ./testprogram
I32_MIN='-2147483648'
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Fwd: perl@10517 (Fail)
On Mon, 11 Jun 2001, Jarkko Hietaniemi wrote: cd t (rm -f perl; /bin/ln -s ../miniperl perl) \ DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./perl TEST base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t pragma/*.t /dev/tty make[1]: *** [minitest] Bus error make: [extra.pods] Error 1 (ignored) DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./miniperl configpm configpm.tmp make: *** [lib/Config.pm] Bus error Ouch. This definitely isn't some irrelevant (test) failure. Another possibility is to try running some of the tests individually. make minitest will make t/perl a symbolic link to miniperl. Then you can do cd t ./perl base/cond.t ./perl base/lex.t etc. to try to get a fairly simple script that gives you the core dump. -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Fwd: perl@10517 (Fail)
[EMAIL PROTECTED] (Nicholas Clark) wrote:
On Mon, Jun 11, 2001 at 05:41:25PM -0500, Ken Williams wrote:
Okay, I get
% cc -o testprogram testprogram.c
testprogram.c: In function `main':
testprogram.c:4: warning: decimal constant is so large that it is unsigned
% ./testprogram
I32_MIN='-2147483648'
I32_MIN=2.14748e+09
so it looks like we're okay?
Erk No.
Darwin's gcc seems to be broken, in that it thinks that -2147483648
is a positive number.
Ack, you'd think I would have noticed that.
I've got to go to be [work in the morning. :-(] but I think that finding
some way to force I32_MIN and IV_Min to be defined as -2147483647-1
should solve this bug, and may well make other things less unhappy.
[although that SEGV might also need to be solved first before the benefits
of IV_MIN being less than zero become apparent]
I did a little more poking around, which (because I don't exactly know
my way around) may or may not be useful. First, to see where I32_MIN
was coming from, I did this (the same test done in 'handy.h'):
#include EXTERN.h
#include perl.h
int main (void) {
#if defined(UINT8_MAX) defined(INT16_MAX) defined(INT32_MAX)
puts (Case 1: I32_MIN == INT32_MIN);
#else
puts (Case 2: I32_MIN == PERL_LONG_MIN);
#endif
return 0;
}
Output:
Case 1: I32_MIN == INT32_MIN
INT32_MIN is set in /usr/include/stdint.h by:
#define INT32_MIN-2147483648
So then I tried the following test programs:
#include stdint.h
int main (void) {
double a = INT32_MIN;
printf (INT32_MIN=%g\n, a);
return 0;
}
Output:
INT32_MIN=2.14748e+09
#define INT32_MIN-2147483648
int main (void) {
double a = INT32_MIN;
printf (INT32_MIN=%g\n, a);
return 0;
}
Output:
INT32_MIN=2.14748e+09
#define INT32_MIN-2147483647-1
int main (void) {
double a = INT32_MIN;
printf (INT32_MIN=%g\n, a);
return 0;
}
Output:
INT32_MIN=-2.14748e+09
In the cases where the output is positive, I get the compiler warning
about decimal constant is so large that it is unsigned. In the final
case there are no warnings.
Hope that's helpful.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Fwd: perl@10517 (Fail)
Hi, Please let me know if I should send reports to a different address. I'm sending to P5P ([EMAIL PROTECTED]) and CC-ing Jarkko and the OSX-perl list. See results below. [EMAIL PROTECTED] (Chris Nandor) wrote: Hi, everybody! Jarkko humbly requests that people test the latest snapshot of perl 5.7 on Mac OS X. -- Chris Date: Mon, 11 Jun 2001 11:20:24 -0500 From: Jarkko Hietaniemi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: perl@10517 Mail-Followup-To: Jarkko Hietaniemi [EMAIL PROTECTED], [EMAIL PROTECTED] X-Spam-Rating: onion.valueclick.com 1.6.2 0/1000/N http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] I configured using sh Configure -de -Dusedevel. I had some warnings and errors during 'make', and was not able to run any tests. Here are some relevant bits of the 'make' output: == `sh cflags libperl.dylib perly.o` perly.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -I/usr/local/include -O3 perly.c: In function `Perl_yyparse': perly.c:1539: warning: suggest parentheses around assignment used as truth value [...snip...] `sh cflags libperl.dylib util.o` util.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -I/usr/local/include -O3 util.c: In function `Perl_cast_ulong': util.c:2936: warning: decimal constant is so large that it is unsigned util.c:2936: warning: decimal constant is so large that it is unsigned util.c: In function `Perl_cast_i32': util.c:2954: warning: decimal constant is so large that it is unsigned util.c:2954: warning: decimal constant is so large that it is unsigned [...snip...] `sh cflags libperl.dylib pp_sys.o` pp_sys.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -I/usr/local/include -O3 pp_sys.c: In function `Perl_pp_system': pp_sys.c:3961: warning: variable `sp' might be clobbered by `longjmp' or `vfork' pp_sys.c:3961: warning: variable `mark' might be clobbered by `longjmp' or `vfork' [...snip...] You may see some irrelevant test failures if you have been unable to build lib/Config.pm. cd t (rm -f perl; /bin/ln -s ../miniperl perl) \ DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./perl TEST base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t pragma/*.t /dev/tty make[1]: *** [minitest] Bus error make: [extra.pods] Error 1 (ignored) DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./miniperl configpm configpm.tmp make: *** [lib/Config.pm] Bus error == When I try to run 'make test', I get this: [localhost:~/Downloads/perl] ken% make test sh writemain lib/auto/DynaLoader/DynaLoader.a writemain.tmp sh mv-if-diff writemain.tmp perlmain.c File perlmain.c not changed. DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl ./miniperl configpm configpm.tmp make: *** [lib/Config.pm] Bus error [localhost:~/Downloads/perl] ken% There is no file 'lib/Config.pm' in the build directory. Hope this is helpful. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Fwd: perl@10517 (Fail)
Looking at the GNUmakefile produced during Configure, I see this: # The following are used to build and install shared libraries for # dynamic loading. LDDLFLAGS = -bundle -undefined suppress -L/usr/local/lib SHRPLDFLAGS = -L/usr/local/lib -dynamiclib -compatibility_version 1-current_version 5.0 -image_base 0x4be0 -install_name $(shrpdir)/$@ CCDLFLAGS = DLSUFFIX = .bundle PLDLFLAGS = LIBPERL = libperl.dylib LLIBPERL= $(LIBPERL) SHRPENV = env LD_RUN_PATH=/System/Library/Perl/darwin/CORE Try commenting that line out with # and then retrying the build. Since PerlIO seems to be part of the problem, do the build like this env LD_RUN_PATH=$PWD PERLIO=stdio make all # The following is used to include the current directory in # the dynamic loader path you are building a shared libperl. LDLIBPTH = DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl Looks like that's where the /System stuff is getting into the mix. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Fwd: perl@10517 (Fail)
[EMAIL PROTECTED] (Jarkko Hietaniemi) wrote: util.c: In function `Perl_cast_ulong': util.c:2936: warning: decimal constant is so large that it is unsigned util.c:2936: warning: decimal constant is so large that it is unsigned util.c: In function `Perl_cast_i32': util.c:2954: warning: decimal constant is so large that it is unsigned util.c:2954: warning: decimal constant is so large that it is unsigned Hmm, I wonder why no other gccs seem to care? What's the version of gcc? It says: [localhost:~/Downloads/perl] ken% cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs Apple Computer, Inc. version gcc-926, based on gcc version 2.95.2 19991024 (release) Ouch. This definitely isn't some irrelevant (test) failure. That's what I figured. =) Could you: rm -f config.sh sh Configure -des -Dusedevel -Doptimize=-g make miniperl gdb ./miniperl (gdb) run (gdb) where I get the same results as Larry Shatzer - doubly defined symbols. Looking at the GNUmakefile produced during Configure, I see this: # The following are used to build and install shared libraries for # dynamic loading. LDDLFLAGS = -bundle -undefined suppress -L/usr/local/lib SHRPLDFLAGS = -L/usr/local/lib -dynamiclib -compatibility_version 1-current_version 5.0 -image_base 0x4be0 -install_name $(shrpdir)/$@ CCDLFLAGS = DLSUFFIX = .bundle PLDLFLAGS = LIBPERL = libperl.dylib LLIBPERL= $(LIBPERL) SHRPENV = env LD_RUN_PATH=/System/Library/Perl/darwin/CORE # The following is used to include the current directory in # the dynamic loader path you are building a shared libperl. LDLIBPTH = DYLD_LIBRARY_PATH=/Users/ken/Downloads/perl Looks like that's where the /System stuff is getting into the mix. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Fwd: perl@10517 (Fail)
On Mon, Jun 11, 2001 at 05:41:25PM -0500, Ken Williams wrote:
[EMAIL PROTECTED] (Nicholas Clark) wrote:
Please could you send the output of this revised test program:
#include EXTERN.h
#include perl.h
int main (void) {
double a = I32_MIN;
char buffer[256];
puts (I32_MIN='STRINGIFY(I32_MIN)');
sprintf (buffer, I32_MIN=%g, a);
puts (buffer);
return 0;
}
I get
./testit
I32_MIN='(-2147483647-1)'
I32_MIN=-2.14748e+09
^ Minus
Okay, I get
% cc -o testprogram testprogram.c
testprogram.c: In function `main':
testprogram.c:4: warning: decimal constant is so large that it is unsigned
% ./testprogram
I32_MIN='-2147483648'
I32_MIN=2.14748e+09
so it looks like we're okay?
Erk No.
Darwin's gcc seems to be broken, in that it thinks that -2147483648
is a positive number.
I've got to go to be [work in the morning. :-(] but I think that finding
some way to force I32_MIN and IV_Min to be defined as -2147483647-1
should solve this bug, and may well make other things less unhappy.
[although that SEGV might also need to be solved first before the benefits
of IV_MIN being less than zero become apparent]
Nicholas Clark
