Re: perl@10517 (Fail)
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 long term solution would be of course to fix the header in the compiler, for short term I can do hacks like #ifdef something to match darwin... #undef INT32_MIN #undef INT64_MIN #define INT64_MIN ... #define INT64_MIN ... #endif What would that something be? #define INT32_MIN (-2147483647 - 1) #define INT64_MIN (-9223372036854775807LL - 1) seems to work. -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED]
Re: perl@10517 (Fail)
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 0x700452d8 in __bt_dleaf () #2 0x7004737c in __bt_crsrdel () #3 0x70046eb8 in bt_seqset () #4 0x70046de0 in __bt_seq () #5 0x0017c324 in XS_DB_File_FIRSTKEY (cv=0xfdbf0) at DB_File.xs:1759 #6 0x4beadd94 in Perl_pp_entersub () at pp_hot.c:2715 #7 0x4be9e76c in Perl_runops_debug () at run.c:53 #8 0x4be06ce0 in S_call_body (myop=0xbfffee1c, is_eval=0) at perl.c:1851 #9 0x4be0607c in Perl_call_sv (sv=0x1bd50c, flags=64) at perl.c:1730 #10 0x4be05c0c in Perl_call_method (methname=0x4bf621c4 FIRSTKEY, flags= 0) at perl.c:1663 #11 0x4be8f22c in Perl_magic_nextpack (sv=0x1aaec0, mg=0x23cc50, key=0x1bce38) at mg.c:1290 #12 0x4be9853c in Perl_hv_iternext (hv=0x1aaec0) at hv.c:1403 #13 0x4bedeab8 in Perl_pp_each () at pp.c:3437 #14 0x4be9e76c in Perl_runops_debug () at run.c:53 #15 0x4be055fc in S_run_body (oldscope=1) at perl.c:1493 #16 0x4be04e8c in perl_run (my_perl=0x5e520) at perl.c:1420 #17 0x1a48 in main (argc=2, argv=0xb848, env=0xb854) at perlmain.c:61 #18 0x189c in _start () #19 0x16dc in start () #20 0xb8fc in ?? () -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.)
Re: perl@10517 (Fail)
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 safe path, this succeeds, but it's strange that it
didn't complain when I ran it yesterday with the previous snapshot.
--
Edward Moy
Apple Computer, Inc.
[EMAIL PROTECTED]
(This message is from me as a reader of this list, and not a statement
from Apple.)
On Wednesday, June 13, 2001, at 12:42 PM, Jarkko Hietaniemi wrote:
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 0x4bf529a0 in _PerlIO_openn ()
#5 0x4bf52b78 in _PerlIO_fdopen ()
#6 0x4bf51a48 in _PerlIO_stdstreams ()
#7 0x4bf58964 in _PerlIO_stderr ()
#8 0x4be7e530 in _Perl_init_i18nl10n ()
#9 0x4be0145c in _perl_construct ()
#10 0x19f8 in _main ()
#11 0x18b4 in __start ()
#12 0x16f4 in start ()
Okay, perlio is going to have to get fixed...
A new snapshot where Nick's fix for this is in (and so are Fred's tweaks)
is available at:
http:[EMAIL PROTECTED]
http:[EMAIL PROTECTED]
ftp:[EMAIL PROTECTED]
http:[EMAIL PROTECTED]
http:[EMAIL PROTECTED]
ftp:[EMAIL PROTECTED]
The INT32_MIN issue still needs a resolution.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 0x4bf529a0 in _PerlIO_openn () #5 0x4bf52b78 in _PerlIO_fdopen () #6 0x4bf51a48 in _PerlIO_stdstreams () #7 0x4bf58964 in _PerlIO_stderr () #8 0x4be7e530 in _Perl_init_i18nl10n () #9 0x4be0145c in _perl_construct () #10 0x19f8 in _main () #11 0x18b4 in __start () #12 0x16f4 in start () Okay, perlio is going to have to get fixed... A new snapshot where Nick's fix for this is in (and so are Fred's tweaks) is available at: http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] The INT32_MIN issue still needs a resolution. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 two separate problems. For those familiar with the internal workings, I've generated the following stack trace (use gdb to get the line numbers): Command: miniperl Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x Thread 0: #0 0x4be055cc in _Perl_get_av ()[perl.c:1548] #1 0x4be055b4 in _Perl_get_av ()[perl.c:1546] #2 0x4bf51768 in _PerlIO_default_layers () [perlio.c:675] #3 0x4bf5253c in _PerlIO_resolve_layers () [perlio.c:987] #4 0x4bf52990 in _PerlIO_openn () [perlio.c:1075] #5 0x4bf52b68 in _PerlIO_fdopen () [perlio.c:1115] #6 0x4bf51a38 in _PerlIO_stdstreams () [perlio.c:732] #7 0x4bf58954 in _PerlIO_stderr () [perlio.c:3687] #8 0x4be7e520 in _Perl_init_i18nl10n () [util.c:771] #9 0x4be0144c in _perl_construct () [perl.c:247] #10 0x19f8 in _main () [miniperlmain.c:52] #11 0x18b4 in __start () #12 0x16f4 in start () In #1, Perl_get_av() [perl.c:1546] calls gv_fetchpv(), which is a #define. It isn't obvious to me how this resolves to a recursive call back to Perl_get_av(), but a subsequent call to gv_fetchpv() returns a value that in #0 [perl.c:1548], cause a bus error, in GvAVn(gv). Hope this help those who understand this. -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.)
Re: perl@10517 (Fail)
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 Fred Sanchez and I recognize. The pragma/warnings one should go away as soon as we figure out how to make Mac OS X and PerlIO play together. The db-tree is probably a core dump since it fails right before the first test (failing at test 0). The posix #10 is a failure related to signals-- any known oddities with signal handling? pragma/warnings...PROG: # pp_hot.c [pp_print] use warnings 'io' ; print STDIN anc; print STDOUT; print STDERR; open(FOO, STDOUT) and print FOO; print getc(STDERR); print getc(FOO); # The next test is known to fail on some systems (Linux+old glibc, # # some *BSDs (including Mac OS X and NeXT), among others. # # We skip it for now (on the grounds that it is just a warning). # #read(FOO,$_,1); no warnings 'io' ; print STDIN anc; EXPECTED: Filehandle STDIN opened only for input at - line 3. Filehandle STDOUT opened only for output at - line 4. Filehandle STDERR opened only for output at - line 5. Filehandle FOO opened only for output at - line 6. Filehandle STDERR opened only for output at - line 7. Filehandle FOO opened only for output at - line 8. GOT: Filehandle STDIN opened only for input at - line 3. Filehandle STDOUT opened only for output at - line 4. Filehandle STDERR opened only for output at - line 5. Filehandle STDERR opened only for output at - line 7. FAILED at test 308 lib/db-btree..FAILED at test 0 lib/posix.FAILED at test 10 -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 test, and (after remembering to unsetenv LANG, which without it, causes bogus test failures), I get: Failed 3 test scripts out of 371, 99.19% okay. More later -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.)
Re: perl@10517 (Fail)
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 decimal constant is so large that it is unsigned warnings. I ran make test, and (after remembering to unsetenv LANG, which without it, causes bogus test failures), I get: Failed 3 test scripts out of 371, 99.19% okay. try #define INT32_MIN -2147483647-1 It stands a reasonable chance of fixing some problems you may have found. [In that I know some bits of perl's implementation are assuming that IV_MIN is a negative power of 2, and that -IV_MIN [the value] can be got with the expression (UV)-IV_MIN And some are assuming that (UV)-IV_MIN is bigger than IV_MAX. Not equal/ And these assumptions may break. They may well be wrong assumptions, but they are there. And how many systems with 1s complement integers or sign and magnitude integers are there out there wanting to run perl? [these things will work on a 2s complement system, but is undefined behaviour by the gospel according to ANSI.] Nicholas Clark
Re: perl@10517 (Fail)
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 and locales being the cause of the core dump is correct, the core dump should be avoidable by setting LC_ALL to C before starting to build Perl.) I built this on a machine Apple set aside for apache.org use; it's a stock system 10.0.3... I haven't installed anything extra. I used that machine so I could build on UFS and avoid possible case problem distractions, though it looks like that's fixed now. my $config_pm = $ARGV[0] || 'lib/Config.pm'; Now, I can't see how that could fail. Either $ARGV[0] is set in which case $config_pm should be set to it, or it is not, in which case $config_pm should be set to 'lib/Config.pm'. Or, a distant and improbably third, somehow the gcc has compiled a completely broken Perl (so broken than even basic syntax is broken). That would suck. Yeah, this one has me pretty dumbfounded. I'd expect a gcc bug to cause greater damage than that, though. Plus the same compiler builds perl 5.6 OK... I dunno. -Fred
Re: perl@10517 (Fail)
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 after this line: my $config_pm = $ARGV[0] || 'lib/Config.pm'; Now, I can't see how that could fail. Either $ARGV[0] is set in which case $config_pm should be set to it, or it is not, in which case $config_pm should be set to 'lib/Config.pm'. Or, a distant and improbably third, somehow the gcc has compiled a completely broken Perl (so broken than even basic syntax is broken). That would suck. And is quite likely if basic things like the number conversion is bust. And in turn that is quite probable if (NV)INT_MIN is currently +2147483648.0 as far as Darwin's gcc is concerned. I'll be a coffee that the problem will go away once INT_MIN is less than 0. [I may be paying out on this one. I already owe Andy Dougherty a coffee, IIRC. I'm on a safer bet, I feel, in saying that there won't be 100% test success until the INT_MIN is solved] Nicholas Clark
Re: perl@10517 (Fail)
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 /System/Library/Perl/darwin/CORE/libperl.dylib(op.o) definition of _Perl_ck_exec and yes, this is because you are picking up the installed perl library instead of ./libperl.dylib. This is correct behavior, and Configure does set things up correctly. When make runs, it invokes it by setting DYLD_LIBRARY_PATH. I use tcsh, so it's like so: [moof:~/ufs/perl] wsanchez% env DYLD_LIBRARY_PATH=/Users/wsanchez/ufs/perl ./miniperl configpm configpm.tmp Use of uninitialized value in concatenation (.) or string at configpm line 19. Use of uninitialized value in concatenation (.) or string at configpm line 19. Can't open : No such file or directory I'm not getting the bus error others are seeing, just the above error. (Final stretch of make output is below.) But I think the symbol problem is a red herring; just remember to set DYLD_LIBRARY_PATH before trying to debug, or you'll get that problem. 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 after this line: my $config_pm = $ARGV[0] || 'lib/Config.pm'; -Fred `sh cflags libperl.dylib perlapi.o` perlapi.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -O3 cc -o libperl.dylib -dynamiclib -compatibility_version 1 -current_version 5.0 -image_base 0x4be0 -install_name /System/Library/Perl/darwin/CORE/libperl.dylib perl.o gv.o toke.o perly.o op.o regcomp.o dump.o util.o mg.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o rm -f opmini.c cp op.c opmini.c `sh cflags libperl.dylib opmini.o` -DPERL_EXTERNAL_GLOB opmini.c CCCMD = cc -DPERL_CORE -c -pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -Wall -fno-strict-aliasing -O3 rm -f opmini.c DYLD_LIBRARY_PATH=/Users/wsanchez/ufs/perl cc -o miniperl \ miniperlmain.o opmini.o libperl.dylib -lm -lc DYLD_LIBRARY_PATH=/Users/wsanchez/ufs/perl ./miniperl -w -Ilib -MExporter -e '?' || make minitest Use of uninitialized value in concatenation (.) or string at lib/Exporter.pm line 38. Use of uninitialized value in concatenation (.) or string at lib/Exporter.pm line 38. Use of uninitialized value in concatenation (.) or string at lib/Exporter.pm line 40. Use of uninitialized value in array dereference at lib/Exporter.pm line 41. Use of uninitialized value in numeric gt () at lib/Exporter.pm line 41. Use of uninitialized value in array dereference at lib/Exporter.pm line 43. make: [extra.pods] Error 1 (ignored) cat ext/re/re.pm lib/re.pm DYLD_LIBRARY_PATH=/Users/wsanchez/ufs/perl ./miniperl configpm configpm.tmp Use of uninitialized value in concatenation (.) or string at configpm line 19. Use of uninitialized value in concatenation (.) or string at configpm line 19. Can't open : No such file or directory make: *** [lib/Config.pm] Error 2
Re: perl@10517 (Fail)
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 Apple mucked with something?
Re: perl@10517 (Fail)
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 gdb 5.0-20001113 (Apple version gdb-186.1) (Sun Feb 18 01:18:32 GMT 2001) (UI_OUT) Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-apple-macos10. Reading symbols for shared libraries ... done (gdb) run Starting program: /Users/lshatzer/perl/bleadperl/./miniperl [Switching to thread 1 (process 12049 thread 0x1903)] dyld: /Users/lshatzer/perl/bleadperl/./miniperl multiple definitions of symbol _Perl_ck_exec /Users/lshatzer/perl/bleadperl/./miniperl definition of _Perl_ck_exec /System/Library/Perl/darwin/CORE/libperl.dylib(op.o) definition of _Perl_ck_exec Program exited with code 0102. (gdb) where No stack. (gdb)
Re: perl@10517 (Fail)
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/ *.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. 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 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 0x4bf529a0 in _PerlIO_openn () #5 0x4bf52b78 in _PerlIO_fdopen () #6 0x4bf51a48 in _PerlIO_stdstreams () #7 0x4bf58964 in _PerlIO_stderr () #8 0x4be7e530 in _Perl_init_i18nl10n () #9 0x4be0145c in _perl_construct () #10 0x19f8 in _main () #11 0x18b4 in __start () #12 0x16f4 in start () PPC Thread State: srr0: 0x4be055dc srr1: 0xf030vrsave: 0x xer: 0x0020 lr: 0x4be055c4 ctr: 0x4be0f458 mq: 0x r0: 0x0003 r1: 0xb4d0 r2: 0x r3: 0x r4: 0x0003 r5: 0x000a r6: 0x r7: 0x r8: 0x r9: 0x r10: 0x0050 r11: 0x003a r12: 0x4be0f458 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xb8f0 r27: 0x001c r28: 0x0006 r29: 0x0001 r30: 0xb4d0 r31: 0x4bf5170c ** So I tried turning off perlio, and now, it no longer crashes, though it now fails in: DYLD_LIBRARY_PATH=/Volumes/XDisk/Perl/build ./miniperl configpm configpm.tmp Can't open : No such file or directory In configpm, $ARGV[0] is being set to configpm.tmp, but $config_pm isn't being set to anything. -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.)
Re: perl@10517 (Fail)
(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 definitions of symbol _Perl_ck_exec Hmmm, this doesn't seem promising. Any MacOSX (or NeXT) dynamic loading experts around? /Users/lshatzer/perl/bleadperl/./miniperl definition of _Perl_ck_exec /System/Library/Perl/darwin/CORE/libperl.dylib(op.o) definition of _Perl_ck_exec Program exited with code 0102. (gdb) where No stack. (gdb) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 are visible. This definitely smells like a dangerous recipe, we are mixing symbols from a 5.7.1+ executable and 5.6.0 library together. Now, why is the /System shared lib being pulled in? libperl.dylib has an install_name of /System/Library/Perl/CORE/darwin/libperl.dylib. When a program links against it, that path is recorded in the binary. dyld will look there first for the library when the program is loaded. You can override that with DYLD_LIBRARY_PATH. -Fred
Re: perl@10517 (Fail)
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 (mini)perl *AND* the operating system's already installed shared Perl library are visible. This definitely smells like a dangerous recipe, we are mixing symbols from a 5.7.1+ executable and 5.6.0 library together. Now, why is the /System shared lib being pulled in? libperl.dylib has an install_name of /System/Library/Perl/CORE/darwin/libperl.dylib. When a program links Isn't this correct only if you want to replace the system Perl? Anyway, now we are in a funny situation where symbols of two Perls are competing, surely this can't be good? against it, that path is recorded in the binary. dyld will look there first for the library when the program is loaded. You can override that with DYLD_LIBRARY_PATH. -Fred -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 wrote: 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: perl@10517 (Fail)
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: /Users/lshatzer/perl/bleadperl/./miniperl configpm configpm.tmp [Switching to thread 1 (process 12126 thread 0x1a07)] dyld: /Users/lshatzer/perl/bleadperl/./miniperl multiple definitions of symbol _Perl_ck_exec /Users/lshatzer/perl/bleadperl/./miniperl definition of _Perl_ck_exec /System/Library/Perl/darwin/CORE/libperl.dylib(op.o) definition of _Perl_ck_exec Program exited with code 0102. (gdb) where No stack.
Re: perl@10517 (Fail)
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 gcc -E -I. would tell us more. Like this? cc util.c -E -Iutil.c (apple made cc their version of gcc) When I run that, I get a TON of output, anything I should look for, or make it into a file, and attach for you?
Re: perl@10517 (Fail)
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 are visible. This definitely smells like a dangerous recipe, we are mixing symbols from a 5.7.1+ executable and 5.6.0 library together. Now, why is the /System shared lib being pulled in? I know all over the Configure I saw /System fly by for the defaults, but I doubt that would have bearing on this. Am I correct? Larry
Re: perl@10517 (Fail)
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 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 0x4bf529a0 in _PerlIO_openn () #5 0x4bf52b78 in _PerlIO_fdopen () #6 0x4bf51a48 in _PerlIO_stdstreams () #7 0x4bf58964 in _PerlIO_stderr () If you re-Configured with -Doptimize=-g and recompiled and retired would CrashCatcher show also the functional call arguments? But even without that I think I have a hunch of what's going on. As you mention turning off PerlIO[1] helps. PerlIO is otherwise good and wonderful[2] but we have had in many platforms problems of Perl crashing if IO is being used before PerlIO is really available. Now that I see init_i18nl10n in the stack strace I think we may be seeing the usual locale griping message (Setting locale failed. Yada Yada ...) trying to make itself heard but getting gagged by the PerlIO not being ready yet. [1] a new feature of perl, not present in perl 5.6 which Mac OS ships with [2] it's a stdio replacement but it also has features stdio doesn't and it gives us independence of any particular stdio implementation #8 0x4be7e530 in _Perl_init_i18nl10n () #9 0x4be0145c in _perl_construct () #10 0x19f8 in _main () #11 0x18b4 in __start () #12 0x16f4 in start () PPC Thread State: srr0: 0x4be055dc srr1: 0xf030vrsave: 0x xer: 0x0020 lr: 0x4be055c4 ctr: 0x4be0f458 mq: 0x r0: 0x0003 r1: 0xb4d0 r2: 0x r3: 0x r4: 0x0003 r5: 0x000a r6: 0x r7: 0x r8: 0x r9: 0x r10: 0x0050 r11: 0x003a r12: 0x4be0f458 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xb8f0 r27: 0x001c r28: 0x0006 r29: 0x0001 r30: 0xb4d0 r31: 0x4bf5170c ** So I tried turning off perlio, and now, it no longer crashes, though it The easiest way to do this is to set the environment variable PERLIO to stdio. now fails in: DYLD_LIBRARY_PATH=/Volumes/XDisk/Perl/build ./miniperl configpm configpm.tmp Can't open : No such file or directory In configpm, $ARGV[0] is being set to configpm.tmp, but $config_pm isn't being set to anything. Weird. Almost as if something were broken :-) -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.) -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: perl@10517 (Fail)
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 does not have to be the system perl. Anyway, now we are in a funny situation where symbols of two Perls are competing, surely this can't be good? Well, this is like when you are building any standard system tool; you have to watch out for paths. If you build a new cp, for example, and you want to use it, then make sure you say ./cp, not cp, lest you run /bin/cp instead. Except this is wonkier and more complicated. :) But Configure knows what do to, or it did, anyway. Can you point me at a current source tarball? I'll try to look at it when I get home this evening. -Fred
