Bug 14040

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.

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

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.

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

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.

Comment 6 Jim Pirzyk 2001-07-20 01:36:59 UTC

Responsible Changed
From-To: freebsd-bugs->pirzyk

The last of my PR's

Comment 7 David E. O'Brien 2001-09-02 18:03:39 UTC

Responsible Changed
From-To: pirzyk->obrien

Amd is more my child for now (and I'm working on an update). 
I agree it is a bug.

Comment 8 David E. O'Brien 2001-09-02 22:26:56 UTC

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 */

Comment 9 David E. O'Brien 2001-09-05 17:54:28 UTC

State Changed
From-To: open->closed

committed a fix to usr.sbin/amd/{Makefile.inc,include/newvers.sh}