Ticket #1504 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

config/auto/arch.pm: Uninitialized value warning on Darwin due to change in order of configuration steps

Reported by: jkeenan Owned by: jkeenan
Priority: normal Milestone:
Component: configure Version: 2.1.0
Severity: medium Keywords: configure byteorder arch
Cc: Coke, Tene, dukeleto Language:
Patch status: applied Platform: darwin

Description

When I configure on my Darwin/PPC, I get this warning:

auto::arch -          Determine CPU architecture and OS...
.... Use of uninitialized value in pattern match (m//) 
       at config/auto/arch.pm line 63.
...............done.

In config/auto/arch.pm we have this code (r44573) inside the runstep method (some lines rebroken for readability in Trac):

    # On OS X if you are using the Perl that shipped 
    # with the system the above split fails because 
    # archname is "darwin-thread-multi-2level".
    if ( $cpuarch =~ /darwin/ ) {
        $osname = 'darwin';
         if ( $conf->data->get('byteorder') =~ /^1234/ ) {  # <--LINE 63
            $cpuarch = 'i386';
        }
        else {
            $cpuarch = 'ppc';
        }
    }

We are getting an uninitialized value for $conf->data->get('byteorder') because config step auto::arch, as part of the merge-in of the rm_cflags branch, was moved to precede config step auto::byteorder rather than following it as was always previously the case.

I don't yet know the full impact of this bug. At the moment, I am trying to build Parrot on Darwin for the first time since that branch merge. But that's on PPC; from the above code, I suspect that $cpuarch will be set to PPC whether that's the case or not.

Suggestions?

Thank you very much.

kid51

Change History

follow-up: ↓ 2   Changed 5 years ago by dukeleto

I can verify that this happens on darwin-x86 at r44753 and causes 'parrot --version' to report the wrong arch:

This is Parrot version 2.1.0-devel built for ppc-darwin.

"make smoke" still passes:  http://smolder.plusthree.com/app/projects/report_details/32546 as well as "make fulltest"

in reply to: ↑ 1 ; follow-up: ↓ 3   Changed 5 years ago by jkeenan

Replying to dukeleto:

I can verify that this happens on darwin-x86 at r44753 and causes 'parrot --version' to report the wrong arch: This is Parrot version 2.1.0-devel built for ppc-darwin.

So here's what I propose:

1. Coke: Can you present the rationale for moving two config steps earlier in the process? (Note: It's probably the right thing, but perhaps we should have moved auto::byteorder as well.)

2. dukeleto: Can you do a test where you move auto::byteorder immediately before auto::arch, then reconfigure, build, test, reporting any anomalies?

3. kid51: Will look at adjacent config steps and see if anything would be harmed by taking the action proposed in (2).

Thank you very much.

kid51

in reply to: ↑ 2 ; follow-up: ↓ 5   Changed 5 years ago by coke

Replying to jkeenan:

Replying to dukeleto:

I can verify that this happens on darwin-x86 at r44753 and causes 'parrot --version' to report the wrong arch: This is Parrot version 2.1.0-devel built for ppc-darwin.

So here's what I propose: 1. Coke: Can you present the rationale for moving two config steps earlier in the process? (Note: It's probably the right thing, but perhaps we should have moved auto::byteorder as well.)

Sure - init::optimize now has a dependency on the config flag 'cpuarch', so the steps that calculate this information need to come before init:optimize; so we moved those 2, but didn't follow the full chain of dependencies. (This is one of the reasons why I want to eventually move all this stuff to a mini makefile, since then we can easily declare our step dependencies and the let the tool figure out what order to run things in.)

2. dukeleto: Can you do a test where you move auto::byteorder immediately before auto::arch, then reconfigure, build, test, reporting any anomalies? 3. kid51: Will look at adjacent config steps and see if anything would be harmed by taking the action proposed in (2). Thank you very much. kid51

follow-up: ↓ 6   Changed 5 years ago by doughera

The simplest fix is probably to see if there is some other way to get the cpu type under darwin. It may be that "uname -p" or "uname -m" works well. I don't think the intended use of $cpuarch is actually defined carefully anywhere, so it's hard to say what's a "right" or "wrong" answer anyway.

More generally:

Metaconfig (the tool used to generate perl 4 and perl 5's Configure scripts) deals with this broader issue by requiring each configure step to explicitly declare what variables it defines and what variables it depends on. These dependencies are then placed into a simple Makefile, and 'make' is called to put things in the correct order. A separate tool, 'metalint', verifies that those lists are correct, and also enforces the rule that every variable must have a definition (which is extracted by another tool into the Glossary, and later incorporated into Config.pm). [Sadly, the tool doesn't ensure that the definitions are meaningful, helpful, clear, or even correct.]

Circular dependencies are typically broken via a mechanism similar to Parrot's Configure.pl callbacks.

A little more background is available in some very old mailing list threads, such as this post from 2001,  http://www.nntp.perl.org/group/perl.perl6.internals/2001/12/msg6895.html and this later one from 2004  http://www.nntp.perl.org/group/perl.perl6.internals/2004/03/msg22180.html.

in reply to: ↑ 3   Changed 5 years ago by jkeenan

Replying to coke: ...

Sure - init::optimize now has a dependency on the config flag 'cpuarch', so the steps that calculate this information need to come before init:optimize; so we moved those 2, but didn't follow the full chain of dependencies. (This is one of the reasons why I want to eventually move all this stuff to a mini makefile, since then we can easily declare our step dependencies and the let the tool figure out what order to run things in.)

Yes, I was bedeviled by those difficult-to-follow dependencies when I was writing tests for the config steps.

Will try to absorb AndyD's suggestion and continue to investigate.

kid51

in reply to: ↑ 4   Changed 5 years ago by jkeenan

Replying to doughera:

The simplest fix is probably to see if there is some other way to get the cpu type under darwin. It may be that "uname -p" or "uname -m" works well. I don't think the intended use of $cpuarch is actually defined carefully anywhere, so it's hard to say what's a "right" or "wrong" answer anyway.

Currently, on Darwin/PPC, the value that gets assigned to cpuname by the time lib/Parrot/Config/Generated.pm is written is: ppc.

Here's what I get for relevant variations on uname:

[jimk] 501 $ uname -m
Power Macintosh
[jimk] 502 $ uname -p
powerpc

So we'd have to provide some mapping to get back to ppc. That wouldn't be very difficult.

dukeleto: What do you get on Darwin/i386 for this?

And what does anybody on a 64-bit Mac get?

Thanks.

kid51

  Changed 5 years ago by dukeleto

This is on darwin-x86:

(kadath)(~)$ uname -m
i386
(kadath)(~)$ uname -p
i386

  Changed 5 years ago by jkeenan

  • cc dukeleto added
  • owner set to jkeenan
  • patch set to applied

Pursuant to AndyD's suggestion, I applied the following patch in r45364:

$ svn diff config/auto/arch.pm 
Index: config/auto/arch.pm
===================================================================
--- config/auto/arch.pm (revision 45363)
+++ config/auto/arch.pm (working copy)
@@ -60,12 +60,11 @@
     # the above split fails because archname is "darwin-thread-multi-2level".
     if ( $cpuarch =~ /darwin/ ) {
         $osname = 'darwin';
-         if ( $conf->data->get('byteorder') =~ /^1234/ ) {
-            $cpuarch = 'i386';
-        }
-        else {
-            $cpuarch = 'ppc';
-        }
+        my $unamep = `uname -p`;
+        chomp $unamep;
+        $cpuarch = ( $unamep eq 'powerpc' )
+            ? 'ppc'
+            : 'i386';
     }
 
     # cpuarch and osname are reversed in archname on windows

dukeleto and other Mac users: Please test this out. I will close ticket in 3-4 days if there are no objections.

Thank you very much.

kid51

  Changed 5 years ago by coke

works for me.

follow-up: ↓ 11   Changed 5 years ago by jkeenan

  • status changed from new to assigned

While the fix looks good, a test in t/steps/auto/arch-01.t is failing because it attempted to simulate Darwin and therefore depended on the old way of determining cpuarch on that OS. So in r45375 I commented those tests out until a workaround can be devised.

kid51

in reply to: ↑ 10   Changed 5 years ago by jkeenan

Replying to jkeenan:

While the fix looks good, a test in t/steps/auto/arch-01.t is failing because it attempted to simulate Darwin and therefore depended on the old way of determining cpuarch on that OS. So in r45375 I commented those tests out until a workaround can be devised.

In r45380 I have fixed and reactivated these tests. Please report any problems you encounter when you run perl Configure.pl --test.

Thank you very much.

kid51

  Changed 4 years ago by jkeenan

No further complaints recorded. Closing ticket.

  Changed 4 years ago by jkeenan

  • status changed from assigned to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.