On Friday, June 15, 2001, at 12:43 PM, Jarkko Hietaniemi wrote:
On Fri, Jun 15, 2001 at 12:39:20PM -0700, Edward Moy wrote:
I didn't notice that a bug report had been filed, so I filed Radar
#2710821 about the INT32_MIN problem (and as it turns out, INT64_MIN has
the same problem).
The
I didn't notice that a bug report had been filed, so I filed Radar
#2710821 about the INT32_MIN problem (and as it turns out, INT64_MIN has
the same problem).
As for make test, I ran the failing lib/db-btree test in gdb, and got
the following stack trace:
#0 0x70010e48 in memmove ()
#1
Yes, this new snapshot fixes the problem.
It's interesting to note that when I run make test I now get 4 errors,
the same three as before plus:
lib/filefind..Insecure directory in $ENV{PATH} while running with
-T switch at ../lib/Cwd.pm line 96.
FAILED at test 1
If I set my path to a
On Wed, Jun 13, 2001 at 08:26:12AM +, Nick Ing-Simmons wrote:
Edward Moy [EMAIL PROTECTED] writes:
Thread 0:
#0 0x4be055dc in _Perl_get_av ()
#1 0x4be055c4 in _Perl_get_av ()
#2 0x4bf51778 in _PerlIO_default_layers ()
#3 0x4bf5254c in _PerlIO_resolve_layers ()
#4
On Wednesday, June 13, 2001, at 01:26 AM, Nick Ing-Simmons wrote:
Okay, perlio is going to have to get fixed...
Just for fun, I re-enabled perlio with the fix to INT32_MIN, hoping that
was causing the bus error. Unfortunately, it still bus errors. So it
looks like perlio and INT32_MIN are
passed the current roadblock, not as a permanent solution. But I did
recompile with -2147483647-1 and it also finishes building. 3 test
scripts still fail:
Those failures are 'known ones'. Not that it makes it any better or
that they shouldn't be fixed, but now we are back at the point
I made a private copy of stdint.h and changed:
#define INT32_MIN-2147483648
---
#define INT32_MIN-2147483647
After setting cflags to use my stdint.h, I rebuilt, and the build
succeeded! There were no decimal constant is so large that it is
unsigned warnings.
I ran make
On Tue, Jun 12, 2001 at 12:41:27PM -0700, Edward Moy wrote:
I made a private copy of stdint.h and changed:
#define INT32_MIN-2147483648
---
#define INT32_MIN-2147483647
After setting cflags to use my stdint.h, I rebuilt, and the build
succeeded! There were no
On Tuesday, June 12, 2001, at 06:29 AM, Jarkko Hietaniemi wrote:
It would be nice to know why not, though. Hmmm. Maybe your locale
configuration is somehow better (as in, you have some working locales
installed) than the out-of-the-box one? (If my theory about the
combination of PerlIO
On Tue, Jun 12, 2001 at 08:29:51AM -0500, Jarkko Hietaniemi wrote:
The actual problem I'm running into is that $config_pm appears to remain
undefined in configpm, which therefore craps out in line 19, which is
what Edward Moy is seeing. That is, miniperl is not setting $config_pm
OK, I build perl@10517, and indeed if you just run ./miniperl, you will
run into symbol conflicts:
[moof:~/ufs/perl] wsanchez% ./miniperl configpm configpm.tmp
dyld: ./miniperl multiple definitions of symbol _Perl_ck_exec
./miniperl definition of _Perl_ck_exec
On Monday, June 11, 2001, at 01:41 PM, Jarkko Hietaniemi wrote:
Hmm, I wonder why no other gccs seem to care? What's the version of
gcc?
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)
Maybe
On Monday, June 11, 2001, at 01:41 PM, Jarkko Hietaniemi wrote:
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
GNU
On Monday, June 11, 2001, at 01:41 PM, Jarkko Hietaniemi wrote:
[...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/
(gdb) run
Oops, I meant to say
run configpm configpm.tmp
to get the same segfault, and after that 'where'.
Starting program: /Users/lshatzer/perl/bleadperl/./miniperl
[Switching to thread 1 (process 12049 thread 0x1903)]
dyld: /Users/lshatzer/perl/bleadperl/./miniperl multiple
On Monday, June 11, 2001, at 02:24 PM, Jarkko Hietaniemi wrote:
Ho-hum. On closer inspection the dynaloader error messages look much
like
there's a big confusion going on: both the symbols of the newly built
(mini)perl *AND* the operating system's already installed shared
Perl library
On Mon, Jun 11, 2001 at 06:43:43PM -0700, Wilfredo Sanchez wrote:
On Monday, June 11, 2001, at 02:24 PM, Jarkko Hietaniemi wrote:
Ho-hum. On closer inspection the dynaloader error messages look
much like
there's a big confusion going on: both the symbols of the newly
built
I had the same thing happen, and asked in the MacOSX mailing list a
while back (under Subject: bleadperl), about the same thing, so it has
been happening a while. I guess I should have posted to p5p, but it was
early in the morning :o)
On Monday, June 11, 2001, at 12:09 PM, Ken Williams
On Monday, June 11, 2001, at 02:11 PM, Jarkko Hietaniemi wrote:
(gdb) run
Oops, I meant to say
run configpm configpm.tmp
to get the same segfault, and after that 'where'.
I hope I am doing everything right ;o)
(gdb) run configpm configpm.tmp
Starting program:
On Monday, June 11, 2001, at 02:06 PM, Jarkko Hietaniemi wrote:
On Mon, Jun 11, 2001 at 01:56:32PM -0700, Larry Shatzer wrote:
[snip]
Maybe Apple mucked with something?
Another possibility is that that said constants are somehow brokenly
defined in Mac OS X. Running the util.c through
On Monday, June 11, 2001, at 02:24 PM, Jarkko Hietaniemi wrote:
Ho-hum. On closer inspection the dynaloader error messages look much
like
there's a big confusion going on: both the symbols of the newly built
(mini)perl *AND* the operating system's already installed shared
Perl library
Ouch. This definitely isn't some irrelevant (test) failure.
I got this, too. From CrashCatcher:
**
Date/Time: 2001-06-11 13:30:00 -0700
PID: 13766
Command: miniperl
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x
On Monday, June 11, 2001, at 06:53 PM, Jarkko Hietaniemi wrote:
Isn't this correct only if you want to replace the system Perl?
This is set by the -install_name flag on the link line, which
Configure sets to wherever you plan to install it, which I think
defaults to the system perl, but
23 matches
Mail list logo
