From Jim.Pirzyk@disney.com Wed Sep 29 13:55:18 1999
Return-Path: <Jim.Pirzyk@disney.com>
Received: from mail.disney.com (mail.disney.com [204.128.192.15])
	by hub.freebsd.org (Postfix) with ESMTP id 6CA8514D8E
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Sep 1999 13:55:07 -0700 (PDT)
	(envelope-from Jim.Pirzyk@disney.com)
Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100])
	by mail.disney.com (8.9.1/8.9.1) with SMTP id NAA15767
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Sep 1999 13:55:01 -0700 (PDT)
Received: from louie.fa.disney.com by pain.corp.disney.com with ESMTP for FreeBSD-gnats-submit@freebsd.org; Wed, 29 Sep 1999 13:54:59 -0700
Received: from snowhite.faf.fa.disney.com (snowhite.faf.fa.disney.com [153.7.115.1])
	by louie.fa.disney.com (8.9.2/8.9.2) with ESMTP id NAA06205
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Sep 1999 13:54:44 -0700 (PDT)
	(envelope-from pirzyk@fa.disney.com)
Received: from amigo.faf.fa.disney.com (amigo.faf.fa.disney.com [153.7.115.94])
	by snowhite.faf.fa.disney.com (8.9.2/8.9.2) with ESMTP id QAA17438
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 29 Sep 1999 16:54:44 -0400 (EDT)
	(envelope-from pirzyk@fa.disney.com)
Received: (from pirzyk@localhost)
	by amigo.faf.fa.disney.com (8.9.3/8.9.2) id QAA83350;
	Wed, 29 Sep 1999 16:54:44 -0400 (EDT)
	(envelope-from pirzyk@fa.disney.com)
Message-Id: <199909292054.QAA83350@amigo.faf.fa.disney.com>
Date: Wed, 29 Sep 1999 16:54:44 -0400 (EDT)
From: Jim.Pirzyk@disney.com
Reply-To: Jim.Pirzyk@disney.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: amd has wrong uname data compile in it
X-Send-Pr-Version: 3.2

>Number:         14040
>Category:       bin
>Synopsis:       amd has wrong uname data compile in it
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 29 14:10:01 PDT 1999
>Closed-Date:    Wed Sep 5 09:54:28 PDT 2001
>Last-Modified:  Wed Sep 05 09:55:12 PDT 2001
>Originator:     Jim Pirzyk
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
>Environment:

	When upgrading to FreeBSD 3.3, I did a make world in /usr/src.  When
	amd got compiled, it saw that I was currently running 3.2-RELEASE.  It
	put that into the amd binary.  When I rebooted, I was running 3.3-RELEASE.
	This means that amd had the wrong info.

>Description:

	Amd had the OS version of the system it was compiled on, not the system
	that it is running on.

>How-To-Repeat:

	Compile amd on one version of the OS and put it on another.

>Fix:
	
	Have amd call the uname C library function at run time to set the
	$os and $osver variables.

>Release-Note:
>Audit-Trail:

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Jim.Pirzyk@disney.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/14040: amd has wrong uname data compile in it 
Date: Thu, 30 Sep 1999 12:54:48 +0200

 On Wed, 29 Sep 1999 16:54:44 -0400, Jim.Pirzyk@disney.com wrote:
 
 > 	Have amd call the uname C library function at run time to set the
 > 	$os and $osver variables.
 
 Could you try to explain how this behaviour actually causes a problem
 for you, particularly in the light of the -o option.
 
 Ciao,
 Sheldon.
 

From: Jim Pirzyk <Jim.Pirzyk@disney.com>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/14040: amd has wrong uname data compile in it
Date: Thu, 30 Sep 1999 08:41:34 -0400

 On Thu, 30 Sep 1999, Sheldon Hearn wrote:
 >On Wed, 29 Sep 1999 16:54:44 -0400, Jim.Pirzyk@disney.com wrote:
 >
 >> 	Have amd call the uname C library function at run time to set the
 >> 	$os and $osver variables.
 >
 >Could you try to explain how this behaviour actually causes a problem
 >for you, particularly in the light of the -o option.
 >
 >Ciao,
 >Sheldon.
 
 If you use the -o option and upgrade your system, then the -o option
 could have the wrong value (if you forget to change it).  Since there is
 an easy way to have the system figure it out for you, it is one less thing
 that needs to be maintained.
 
 I understand that it is a semantic issue, hence the low priority and
 severity.
 
 Does this make sense?
 
 - JimP
 
 -- 
 --- @(#) $Id: dot.signature,v 1.6 1999/09/24 12:53:00 pirzyk Exp $
     __o   Jim.Pirzyk@disney.com -------------------------------------
  _'\<,_   System Intergrator, Walt Disney Feature Animation Florida
 (*)/ (*)  at Disney MGM Studios
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Jim Pirzyk <Jim.Pirzyk@disney.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/14040: amd has wrong uname data compile in it 
Date: Thu, 30 Sep 1999 14:45:42 +0200

 On Thu, 30 Sep 1999 08:41:34 -0400, Jim Pirzyk wrote:
 
 > I understand that it is a semantic issue, hence the low priority and
 > severity.
 > 
 > Does this make sense?
 
 Yes, I just want to know what problems you think would be caused in such
 a case. I ask because this is something that'll "go wrong" very seldom,
 and I'm pretty sure that osversion is supposed to store the os under
 which amd was compiled, not what it's running under right now.
 
 Ciao,
 Sheldon.
 

From: Jim Pirzyk <Jim.Pirzyk@disney.com>
To: Sheldon Hearn <sheldonh@uunet.co.za>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/14040: amd has wrong uname data compile in it
Date: Thu, 30 Sep 1999 10:02:59 -0400

 On Thu, 30 Sep 1999, Sheldon Hearn wrote:
 >On Thu, 30 Sep 1999 08:41:34 -0400, Jim Pirzyk wrote:
 >
 >> I understand that it is a semantic issue, hence the low priority and
 >> severity.
 >> 
 >> Does this make sense?
 >
 >Yes, I just want to know what problems you think would be caused in such
 >a case. I ask because this is something that'll "go wrong" very seldom,
 >and I'm pretty sure that osversion is supposed to store the os under
 >which amd was compiled, not what it's running under right now.
 
 But hard coding values that should be determined at run time limits the
 flexability of the software....
 
 - JimP
 
 -- 
 --- @(#) $Id: dot.signature,v 1.6 1999/09/24 12:53:00 pirzyk Exp $
     __o   Jim.Pirzyk@disney.com -------------------------------------
  _'\<,_   System Intergrator, Walt Disney Feature Animation Florida
 (*)/ (*)  at Disney MGM Studios
 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: Jim Pirzyk <Jim.Pirzyk@disney.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/14040: amd has wrong uname data compile in it 
Date: Thu, 30 Sep 1999 18:28:28 +0200

 On Thu, 30 Sep 1999 12:05:43 -0400, Jim Pirzyk wrote:
 
 > I see, said the blind man.  I cannot answer the question if it is
 > storing the osver at compile time because it may not be able to get it
 > at run time.  Maybe it was before most systems had the uname C library
 > routine, so it had to be compiled in?
 
 Could be. I'll have a closer look at where (if at all) amd users
 osversion internally.
 
 :-)
 
 Later,
 Sheldon.
 
Responsible-Changed-From-To: freebsd-bugs->pirzyk 
Responsible-Changed-By: pirzyk 
Responsible-Changed-When: Thu Jul 19 17:36:59 PDT 2001 
Responsible-Changed-Why:  
The last of my PR's 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14040 
Responsible-Changed-From-To: pirzyk->obrien 
Responsible-Changed-By: obrien 
Responsible-Changed-When: Sun Sep 2 10:03:39 PDT 2001 
Responsible-Changed-Why:  
Amd is more my child for now (and I'm working on an update). 
I agree it is a bug. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14040 

From: "David O'Brien" <obrien@FreeBSD.org>
To: pirzyk@FreeBSD.org
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/14040: amd has wrong uname data compile in it
Date: Sun, 2 Sep 2001 14:26:56 -0700

 What do you think about as a fix?
 
 Index: Makefile.inc
 ===================================================================
 RCS file: /home/ncvs/src/usr.sbin/amd/Makefile.inc,v
 retrieving revision 1.7
 diff -u -u -2 -r1.7 Makefile.inc
 --- Makefile.inc	2001/07/20 06:19:36	1.7
 +++ Makefile.inc	2001/09/02 20:48:18
 @@ -19,4 +19,7 @@
  CFLAGS+= -DHAVE_CONFIG_H
  
 +TARGET_ARCH?=	${MACHINE_ARCH}
 +CFLAGS+= -DHOST_CPU=\"${TARGET_ARCH}\" -DHOST_ARCH=\"${TARGET_ARCH}\"
 +
  .if exists(${.OBJDIR}/../libamu)
  LIBAMUDIR=	${.OBJDIR}/../libamu
 
 Index: include/newvers.sh
 ===================================================================
 RCS file: /home/ncvs/src/usr.sbin/amd/include/newvers.sh,v
 retrieving revision 1.3
 diff -u -u -2 -r1.3 newvers.sh
 --- include/newvers.sh	1999/08/28 01:15:16	1.3
 +++ include/newvers.sh	2001/09/02 21:24:06
 @@ -4,12 +4,17 @@
  # Generate local configuration parameters for amd
  #
 -cat << __EOF
 -
 -/* Define name of host machine's cpu (eg. sparc) */
 -/* #define HOST_CPU "`uname -p`" */
 -#define HOST_CPU "`uname -m`"
  
 -/* Define name of host machine's architecture (eg. sun4) */
 -#define HOST_ARCH "`uname -m`"
 +if [ -e ../../../sys/conf/newvers.sh ]; then
 +	eval `egrep '^[A-Z]+=' ../../../sys/conf/newvers.sh | grep -v COPYRIGHT`
 +	OS=`echo ${TYPE} | tr '[A-Z]' '[a-z]'`
 +	echo '/* Define name and version of host machine (eg. solaris2.5.1) */'
 +	echo "#define HOST_OS \"${OS}${REVISION}\""
 +	echo '/* Define only name of host machine OS (eg. solaris2) */'
 +	echo "#define HOST_OS_NAME \"${OS}${REVISION}\"" \
 +		| sed -e 's/\.[-._0-9]*//'
 +	echo '/* Define only version of host machine (eg. 2.5.1) */'
 +	echo "#define HOST_OS_VERSION \"${REVISION}\""
 +else
 +cat << __NO_newvers_sh
  
  /* Define name and version of host machine (eg. solaris2.5.1) */
 @@ -19,6 +24,8 @@
  #define HOST_OS_NAME "`uname -s | tr '[A-Z]' '[a-z]'``uname -r | sed -e 's/\..*$//'`"
  
 -/* Define only version of host machine (eg. 2.5.1) */
 -#define HOST_OS_VERSION "`uname -r`"
 +__NO_newvers_sh
 +fi
 +
 +cat << __EOF
  
  /* Define name of host */
State-Changed-From-To: open->closed 
State-Changed-By: obrien 
State-Changed-When: Wed Sep 5 09:54:28 PDT 2001 
State-Changed-Why:  
committed a fix to usr.sbin/amd/{Makefile.inc,include/newvers.sh} 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14040 
>Unformatted:
