Re: checking that non-UNIX platforms don't lag in their Configure variables
> And indeed it detects quite a few missing symbols, for epoc, > Netware, symbian (!), plan9 and windows CE. The (!) was why I wrote this :-) > Also, uconfig.sh probably needs to be updated, although I'm not > 100% sure how to do this properly.
Re: checking that non-UNIX platforms don't lag in their Configure variables
Jarkko Hietaniemi wrote: > The attached script, suitable for Porting/, suitable for both blead > and maint, helps in the battle of keeping the non-UNIX platforms up And in time I will learn to double check the address suggestions the autocompletion feature gives me.
checking that non-UNIX platforms don't lag in their Configure variables
The attached script, suitable for Porting/, suitable for both blead and maint, helps in the battle of keeping the non-UNIX platforms up to date in their knowledge of Configure variables. Run it at the top level directory and it will tell its best guess as to which of those variables are missing in various places. The task of adding d_foo='undef' and the like all over the place is left as a manual exercise. checkcfgvar.pl.gz Description: GNU Zip compressed data
Re: [OT?] Shebang question
> Which is not really portable with command line options, due to how > env(1) works on OS X: > > $ #!/usr/bin/env perl -wl > print "hello world" > > $ ./test > env: perl -wl: No such file or directory That is both against the documentation (env(1)) and the UNIX spec, so I think a bug report to Apple is in order. (Actually, env as such seems to be working okay, so it is more likely a bug in the #! processing.) > A different trick that I have not tested on other unix systems (as I > just use '#!/usr/bin/perl') is to do the following: > > $ exec perl -wl < print "hello world" > > $ ./test > hello world
Re: Sort by Mod Date
Joseph Alotta wrote:
> On May 13, 2004, at 11:12 PM, Matt Doughty wrote:
>
>
>>here is my little bit for making a really short solution.
>>
>>--Matt
>>
>>#!perl
>>my $dir = shift() || ".";
>>opendir(DIR, $dir);
>>print for(map { $_ . "\n" } sort { (stat($b))[9] <=> (stat($a))[9] }
>>grep { !/^.{1,2}$/ } readdir DIR );
\. needed here instead of .
>
>
> All these solutions are still too verbose and self-documenting. Can
> someone write something a little shorter, maybe a one-liner?
"Does it have to fit in 80 columns?" :-)
opendir(DIR, shift || ".") && print map { "$_->[1]\n" } sort { $a->[0]
<=> $b->[0] || $a->[1] cmp $b->[1] } map { [ (stat($_))[9], $_ ] } grep
{ !/^\.{1,2}$/ } readdir(DIR)
Note the added cmp test in case timestamps compare equal.
Pity that opendir() doesn't return a dirhandle.
> Joe.
>
>
Re: "out of memory" error in Panther, not in Jaguar?
> *** malloc: vm_allocate(size=8421376) failed (error
> code=3)
> *** malloc[5576]: error: Can't allocate region
> Out of memory!
>
> The strange thing is that I'm not slurping up the
> whole file,
Oh but you are...
> I'm reading it line by line. But Perl
> seems to be slurping the whole thing into memory
> before even processing the first line. But even so,
> foreach my $line () {
This reads in the whole file first because the (...) of
for each enforces list context, and the in list context
does read in the whole handle. You meant
while (my $line = ) {
my $line = $_;
or something similar.
Re: Suggested version for Mac OS X.2?
David Wheeler wrote: > On Apr 17, 2004, at 4:39 PM, Jarkko Hietaniemi wrote: > > >>Wrong. Ponie is off the chart, or maybe more like 5.11, > > > That's one louda, innit? I just wonder who's the drummer. -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: Suggested version for Mac OS X.2?
Andrew M. Langmead wrote: > On Apr 17, 2004, at 8:57 AM, Chris Devers wrote: > > >>I thought even numbered point releases were unstable, test releases. >> > > > The other way around. The odd numbered releases are the development > track. (When you try to run some script against them, something goes > wrong and you say "oh, that seems odd!") Right. > The 5.7 development track lead to the 5.8 stable release. Right. > The 5.9 (Ponie) development will lead to a stable release of 5.10. Wrong. Ponie is off the chart, or maybe more like 5.11, or maybe more like 5.9+i (as in a complex number). Ponie is more or less taking the bones of Parrot (the Perl 6 virtual machine) and hanging on the flesh of Perl 5.9 (runtime). Or putting in a Porsche motor on a Mercedes body, if that sounds less gory. Or in other words, Ponie = Parrot + Perl 5.9.
Re: Perl for Panther
On Tue, Jul 01, 2003 at 03:24:34PM -0700, David Wheeler wrote: > On Tuesday, July 1, 2003, at 03:19 PM, Jarkko Hietaniemi wrote: > > >>This is great news, Edward, thank you! I just hope that 5.8.1 is > >>finalized and makes it in before 10.3 is finalized. I'd rather see an > > > >You think I don't? :-) > > Heh, 'course not! I don't suppose you know yet just when 5.8.1 will be > ready? No. Have you ever juggled seven balls, an oiled sumo wrestler, a turned-on chainsaw, and an electric eel? -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: Perl for Panther
> This is great news, Edward, thank you! I just hope that 5.8.1 is > finalized and makes it in before 10.3 is finalized. I'd rather see an You think I don't? :-) > official stable Perl release than a pre-release included with Panther. -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: [MacOS X] consider useshrplib='false' by default
Sounds reasonable to make the useshrplib to default to false (because of the significant startup slowness otherwise) and at the very least make it conditional (and I got a nod from Ed Moy of Apple, too). So I did (change #19681). How about the -prebind flags et alia? Should they be made default, too? -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: Time::HiRes and perl-5.8.0 on Jaguar
> >>ext/Time/HiRes/HiRes... > > > >I've seen that, and I think David Wheeler has too. When I first ran > >into it, I thought my multi-tasking had screwed it up, and started the > >make anew. Didn't happen the second time around. Not sure what the > >root cause is. > > Yes, same experience for me. I killed the testing and ran it again, and > this time it worked fine. > > Jarkko, have you noticed this? Nope. It would be nice to get a system call trace on such a hangup. I.e. what is it doing? -- Jarkko Hietaniemi <[EMAIL PROTECTED]> http://www.iki.fi/jhi/ "There is this special biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Re: rhapsody? (Re: [jhi@iki.fi: perl@13687])
On Sun, Dec 16, 2001 at 02:11:04AM -0600, Ken Williams wrote: > Hey Jarkko, > > I recall a previous message[1] from Wilfredo Sanchez in which he said > that using the -flat-namespaces linker flag was "the easy way" to get > perl working on OS X, but that leaving it out was "the right way". I > see that perl@13687 is still using -flat-namespaces, though. Yup, because no one has told us of any "right way". > Using -flat-namespaces prevents things like Apache::Cookie from working > properly (or working at all, actually)[2]. Is anyone on p5p aware of > this problem and/or working on a fix? Unfortunately I haven't half a C No, we weren't. (I think.) > clue and I can't be of much help personally. > > -Ken -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
rhapsody? (Re: [jhi@iki.fi: perl@13687])
Anyone reading this list and running Rhapsody/Mac OS X Server? (not Mac OS X 10.1, because I can test Perl on that myself) If so, I would be grateful if you downloaded and tried the below developer snapshot of Perl. http:[EMAIL PROTECTED] http:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] ftp:[EMAIL PROTECTED] ftp.funet.fi::perlsnap (rsync) Unpacks/rsyncs into directory called Perl. cd perl sh Configure -des -Dusedevel make all test Probably doesn't say "All tests successful." in the end. Continue with: cd t ./perl harness and I would be interested in the final summary of failures. -- $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 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? > 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 ?? () Hmmm, doesn't ring a bell. > -- > 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 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)
> 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 ; > print ; > open(FOO, ">&STDOUT") and print ; > 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'm not getting the bus error others are seeing, just the above error. 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.) > (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 Okay, it seems that I'm guilty of peddling red herrings. > 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'; 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. -- $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 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: Fwd: perl@10517 (Fail)
On Mon, Jun 11, 2001 at 05:43:17PM -0500, Ken Williams wrote: > [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. Hmmm. The PERLIO=stdio should work...but the other way would to be completely eradicate perlio by rm config.sh sh Configure -des -Dusedevel -Uuseperlio make > ------ > Ken Williams Last Bastion of Euclidity > [EMAIL PROTECTED]The Math Forum -- $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)
> 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: 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 Mon, Jun 11, 2001 at 02:19:23PM -0700, Larry Shatzer wrote: > > 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 Basically it would be: cc -I. -E util.c > util.i > (apple made cc their version of gcc) > When I run that, I get a TON of output, anything I should look for, or I think Nick Clark's test program already solved my request so I won't be needing the ton. > make it into a file, and attach for you? -- $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 Mon, Jun 11, 2001 at 02:16:51PM -0700, Larry Shatzer wrote: > > 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) I would say so. > (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 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? > Program exited with code 0102. > (gdb) where > No stack. -- $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)
> (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 Mon, Jun 11, 2001 at 01:56:32PM -0700, Larry Shatzer wrote: > > 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? 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. -- $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)
> 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 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
perl 5.7.1+ fine(ish) on mac os x
Public service announcement: the development branch of Perl [1] now builds out of the box in Mac OS X, with just Configure -de. I integrated the various needed changes and Paul Schinder tested them for me, kudos to Paul who never sleeps (he simply can't, given how much he tests stuff). Note that I said "fine(ish)" and "builds", the three test failures (pragma/warnings, lib/sigaction, lib/posix) are still there. P.S. Anyone on rhapsody wanting to test the developer snapshot? ftp:[EMAIL PROTECTED] -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
