Process output of a simple command

[Dr. David Kirkby]

When autoconf runs on a Solaris machine, config.log shows:
---------------------------------
## --------- ##
## Platform. ##
## --------- ##

hostname = swan
uname -m = sun4u
uname -r = 5.10
uname -s = SunOS
uname -v = Generic_139555-08

/usr/bin/uname -p = sparc
/bin/uname -X     = System = SunOS
Node = swan
Release = 5.10
KernelID = Generic_139555-08
Machine = sun4u
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 2

/bin/arch              = sun4
/usr/bin/arch -k       = sun4u
/usr/convex/getsysinfo = unknown
drkirkby@swan:[~/sage-4.1.2.rc2/spkg/base/prereq-0.5] $ grep sun4u config.log
uname -m = sun4u
Machine = sun4u
---------------------------

How can I get that result of 'Machine' or '/usr/bin/arch -k' and use it in
configure.ac ?

If someone runs on Solaris 9 or earlier, I'd like to tell them to upgrade to
Solaris 10, but if they are using 'sun4m' machines, then that is impossible for
them. Likewise, if they are using sun4v machines, I'd like to bring to their
attention a bug in Solaris, and how to circumvent it.

I tried:

if test x$Machine = 'xsun4m'
then
   AC_MSG_WARN([This is a sun4m computer running Solaris])
   etc etc
fi

but that does not work.


dave


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Alfred M. Szmidt]

Why not print a message if that bug is found instead of depending on
the architecture which surley will backfire, since you could be
running GNU/Linux or anything on such a machine.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Dr. David Kirkby]

Alfred M. Szmidt wrote:
> Why not print a message if that bug is found instead of depending on
> the architecture which surley will backfire, since you could be
> running GNU/Linux or anything on such a machine.
>
It would be somewhat difficult to detect the bug, as it is by its very nature
random. In fact, it is never seen with gcc 4.2.4, despite the fact Sun
acknowledge it is a bug on Solaris - the upper 32-bit of a 64-bit register are
not set to 0 as they should be. So I'd rather warn the user. In any case, if
they build it on sun4v, it could be put on another sun4v machine, where the bug
does exist. (Sun will soon have a patch for it).

So is there a way I can check the architecture? Also, I would like to know if
the machine is sun4m, as that can not be upgraded to Solaris 10. Since Solaris
10 is the only supported version of Solaris, and earlier (sun4m) hardware can
not be upgraded, I would like to be able to test the architecture.

Any, that aside, how could I use the output of any arbitrary command, to return
something I can test on?


dave


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Wed, 21 Oct 2009, Dr. David Kirkby wrote:
>
> So is there a way I can check the architecture? Also, I would like to know if
> the machine is sun4m, as that can not be upgraded to Solaris 10. Since
> Solaris 10 is the only supported version of Solaris, and earlier (sun4m)
> hardware can not be upgraded, I would like to be able to test the
> architecture.

arch=`uname -m`

> Any, that aside, how could I use the output of any arbitrary command, to
> return something I can test on?

arch=`uname -m`

I continue to believe that the approach you are taking is wrong since
the work is entirely disposable.  What you find out this year may be
wong (or insufficient) next year, but maybe next year you will have
moved on to some other project.

It is must better to document all platform specific issues which are
found and the workarounds.  That is what GCC and other large software
usually does.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Dr. David Kirkby]

Bob Friesenhahn wrote:

> On Wed, 21 Oct 2009, Dr. David Kirkby wrote:
>>
>> So is there a way I can check the architecture? Also, I would like to
>> know if the machine is sun4m, as that can not be upgraded to Solaris
>> 10. Since Solaris 10 is the only supported version of Solaris, and
>> earlier (sun4m) hardware can not be upgraded, I would like to be able
>> to test the architecture.
>
> arch=`uname -m`
>
>> Any, that aside, how could I use the output of any arbitrary command,
>> to return something I can test on?
>
> arch=`uname -m`
>
> I continue to believe that the approach you are taking is wrong since
> the work is entirely disposable.  What you find out this year may be
> wong (or insufficient) next year, but maybe next year you will have
> moved on to some other project.

I do not believe some of this is every likely to change.

As such, do you see anything wrong with this?

# Test for very old Sun hardware, based on the sun4m architecture.
if test "x`uname -m`" = 'xsun4m'
then
     AC_MSG_WARN([*********************************************************])
     AC_MSG_WARN([*********************************************************])
     AC_MSG_WARN([You are using a very old computer based on the sun4m     ])
     AC_MSG_WARN([series of processors. Sun computers of this type could])
     AC_MSG_WARN([be last ordered in June 1997. They can not be updated to ])
     AC_MSG_WARN([Solaris 10 or later. As Sage is only supported on Solaris])
     AC_MSG_WARN([10 or later, you might experience problems which the Sage])
     AC_MSG_WARN([developers have not seen, as they do not test on sun4m   ])
     AC_MSG_WARN([hardware.])
     AC_MSG_WARN([*********************************************************])
     AC_MSG_WARN([*********************************************************])
fi

If the syntax of the test can be improved, please state how. Should the quotes
be single or double?

It is most unlikely that

* Sun will ever bring out a new operating system that it supports on pre 1997
hardware.
* Sage will ever bother supporting such old hardware.
* Sage will ever support any operating system earlier than Solaris 10.

> It is must better to document all platform specific issues which are
> found and the workarounds.  That is what GCC and other large software
> usually does.

But how often do you see people report problems, only to be told they are
documented, or to RTFM?

There is also the issue that in the case of Sun hardware, the person building
the software might not know much about the hardware. Such hardware is not like a
PC, where it is likely to be sitting next to you.

I recall hearing about someone who sent for a job and said they had been using a
'bach' computer. Where really 'bach' was the hostname! This was 20+ years ago,
and I guess people are more computer literate now.

IMHO, if you detect a subset of potential problems, and report them, it is
better than doing nothing. It will never be possible to test or document all
issues known or unknown.

VERY often documentation lags code anyway.

Dave



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Wed, 21 Oct 2009, Dr. David Kirkby wrote:

>
> As such, do you see anything wrong with this?
>
> # Test for very old Sun hardware, based on the sun4m architecture.
> if test "x`uname -m`" = 'xsun4m'

Yes.  There is a good chance that the warning will never be emitted
and so this is just "dead code".  The reason is that a sun4m owner is
unlikely to be interested in building your code.

> But how often do you see people report problems, only to be told they are
> documented, or to RTFM?

Hardly ever.  If there will be a problem I take care to make sure that
the problem does not exist.

> There is also the issue that in the case of Sun hardware, the person building
> the software might not know much about the hardware. Such hardware is not
> like a PC, where it is likely to be sitting next to you.

There used to be a sun4m machine sitting next to me, but not any more.
It was traded in to become plastic powder.  It took an hour to build
software that today's computers can compile in 30 seconds (or less).

> VERY often documentation lags code anyway.

It is more worthwhile to work on the documentation.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Alfred M. Szmidt]

   > Why not print a message if that bug is found instead of depending on
   > the architecture which surley will backfire, since you could be
   > running GNU/Linux or anything on such a machine.

   It would be somewhat difficult to detect the bug, as it is by its
   very nature random. In fact, it is never seen with gcc 4.2.4,
   despite the fact Sun acknowledge it is a bug on Solaris - the upper
   32-bit of a 64-bit register are not set to 0 as they should be. So
   I'd rather warn the user. In any case, if they build it on sun4v,
   it could be put on another sun4v machine, where the bug does
   exist. (Sun will soon have a patch for it).

So the test should do that (which is very easy to check), and if the
bits are not set correctly, report a warning or error.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf