Ticket #423 (closed bug: fixed)

Opened 13 years ago

Last modified 12 years ago

config/auto/arch.pm can get wrong architecture on solaris/x86

Reported by: doughera Owned by: jkeenan
Priority: minor Milestone:
Component: configure Version:
Severity: low Keywords:
Cc: rg@… Language:
Patch status: applied Platform: solaris

Description

As of r36852, config/auto/arch.pm assumes that, on Solaris/x86, if perl 5's $Config{archname} contains the string -64int, then the user must be running on an amd64-type processor.

However, perl 5's archname will contain that string on i386 if perl5's ivtype='long long'. OpenSolaris ships with a perl configured in exactly that way. Consequently, arch.pm incorrectly identifies an i386 machine as amd64.

One reliable way to get the current processor on Solaris is to use the uname -p command. However, that can lead to a different problem: On an i386 machine, uname -p outputs 'i386'. Parrot's configure then ends up setting jitcapable=1, though that configuration (OpenSolaris/i386/JIT) doesn't really work well.

Attachments

tt423-solaris-archname.patch Download (1.3 KB) - added by doughera 13 years ago.

Change History

  Changed 13 years ago by rg

  • cc rg@… added

Changed 13 years ago by doughera

follow-up: ↓ 3   Changed 12 years ago by doughera

I don't have an amd64 system to test this on, but one user told me that uname -p outputs i386 on that platform as well. Perhaps parrot's Configure.pl should use the isainfo command instead.

Part of the problem is that it's not at all clear why Configure.pl even cares about this information anyway. Solaris actually supports a rich array of possibilities for running 32-bit and/or 64-bit applications on the amd64 processor. I don't know what uname -p or isainfo -k output under all those circumstances, or how the various possible outputs map onto the possible ways Configure.pl could use or abuse the information.

Meanwhile, the current code is definitely wrong. Using either uname -p or isainfo -k would be an improvement. Absent any understanding of what the information is going to be used for, the patch above (which uses uname -p) is probably a good step forward.

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

  • status changed from new to assigned
  • owner set to jkeenan
  • patch set to applied

Replying to doughera:

Andy,

Since you originally submitted your patch config/auto/jit.pm has been substantially gutted as part of the replacement of our dysfunctional JIT system. So, when I went to apply your patch to trunk, I got this result:

$ patch -p1 < ~/learn/parrot/patches/tt423-solaris-archname.patch 
patching file config/auto/arch.pm
patching file config/auto/jit.pm
Hunk #1 FAILED at 173.
1 out of 1 hunk FAILED -- saving rejects to file config/auto/jit.pm.rej

The .rej file had this content:

$ cat config/auto/jit.pm.rej 
***************
*** 173,178 ****
          if ( $cpuarch eq 'i386' && $osname eq 'darwin' ) {
              $jitcapable = 0;
          }
      }
      return $jitcapable;
  }
--- 173,182 ----
          if ( $cpuarch eq 'i386' && $osname eq 'darwin' ) {
              $jitcapable = 0;
          }
+         # And another exception (TT #423)
+         if ( $cpuarch eq 'i386' && $osname eq 'solaris' ) {
+             $jitcapable = 0;
+         }
      }
      return $jitcapable;
  }

So, I'm applying only the config/auto/arch.pm part of the patch. Since I don't have a Solaris box to test on, we'll have to rely on you and other Solaris testers to report any problems once the patch is applied.

It would be good if we could have some Solaris testers report on make fulltest.

Did no harm to make test on Linux/i386, as per  this Smolder report. Applied to trunk in r42159.

For recordkeeping purposes, I'm taking ownership of the ticket. But since I don't have Solaris, any dev with Solaris is encouraged to steal the ticket from me. Thank you very much.

kid51

  Changed 12 years ago by doughera

What you did looks fine. I can't really test it because parrot no longer builds for me on Solaris. It fails with TT #1130 and TT #985 with gcc, and with those two plus TT #652 on Sun's cc. But it's probably ok.

in reply to: ↑ 3 ; follow-up: ↓ 6   Changed 12 years ago by rg

Replying to jkeenan:

It would be good if we could have some Solaris testers report on make fulltest.

I've run a fulltest on solaris/sparc64 for you. It passes regular tests but fails t/op/exceptions.t for testr. I doubt this has anything to do with the patch, though. Unfortunately I don't have any time to look into this, especially not on the slow hardware that I have access to.

RG.

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

Replying to rg:

Replying to jkeenan:

I've run a fulltest on solaris/sparc64 for you. It passes regular tests but fails t/op/exceptions.t for testr. I doubt this has anything to do with the patch, though.

No, I agree that it probably doesn't pertain to the configuration issue discussed in this ticket.

But it would be good if you could open a separate Trac ticket that discusses this issue and provides test output. We need all the help we can get on solaris.

Thank you very much.

kid51

  Changed 12 years ago by whiteknight

As a basic note, we don't have a JIT system right now so it should be perfectly safe to use uname -p to get the information we want.

  Changed 12 years ago by doughera

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