Subject: Linux-Development Digest #863
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Mon, 27 Jun 94 14:13:12 EDT

Linux-Development Digest #863, Volume #1         Mon, 27 Jun 94 14:13:12 EDT

Contents:
  Patches for Linux port of db.1.73 (Berkeley db library) (Al Longyear)
  memory used in 1.1.x kernels? (Craig Sanders)
  Re: svgalib and s3 (Brandon S. Allbery)
  Re: Major device number clash (iCS) (Patrick Schaaf)
  Mach 64 (Michael A. Pagels)
  Wanted info on color printing in Linux (Eduard Marghidan)
  Re: Need help with gcc/ncurses under 99pl15 (Zeyd M. Ben-Halim)

----------------------------------------------------------------------------

From: longyear@netcom.com (Al Longyear)
Subject: Patches for Linux port of db.1.73 (Berkeley db library)
Date: Sun, 26 Jun 1994 01:53:48 GMT

This is a patch which I received from Stef Van Dessel <stefke@igwe1.vub.ac.be>
concerning the changes needed to make the db.1.73 library work with Linux.
The patch will construct a Linux PORT (in the PORT subdirectory along with all
of the others).

Installation instructions:

1. Obtain the db.1.73.tar.Z source from the Berkeley archive site near you.
2. Extract it using the command:        tar -xzvf db.1.73.tar.Z
2. Apply the patch with the command:    patch -p0 <patch_file
                                              ^^^ (don't forget this part!)
3. Follow the instructions in the README file which states that you should
   go to the PORT/linux directory and issue the command "make install".

The library is a very good substitute for the gdb used with Linux. It is not
covered under the GNU Public License as is the gdb library. If you are going
to develop commercial software for Linux (and I hope that you do), then you
should not use the gdb library for its restrictive license. Use the Berkeley
library with these changes.

In addition, the sendmail V8 software recommends that the db library be
used in lieu of the gdb library. I don't know the differences between the two
and I was successful in implementing sendmail with the gdb library, however,
this is only one more recommendation.

In the case of sendmail, you may wish to insert a link
/usr/lib/libndbm.a -> /usr/lib/libdb.a

This will allow sendmail to use the directive "-lndbm" in its Makefile.

                        --------------------------

diff -urN orig/db.1.73/PORT/linux/Makefile db.1.73/PORT/linux/Makefile
--- orig/db.1.73/PORT/linux/Makefile    Thu Jan  1 01:00:00 1970
+++ db.1.73/PORT/linux/Makefile Sun May 29 16:27:53 1994
@@ -0,0 +1,123 @@
+#      @(#)Makefile    8.3 (Berkeley) 9/6/93
+
+LIBDB= libdb.a
+ROOTDIR=/usr/local
+LIBDIR=        ${ROOTDIR}/lib
+INCDIR=        ${ROOTDIR}/include
+INSTALL=       /usr/bin/install
+OBJ1=  hash.o hash_bigkey.o hash_buf.o hash_func.o hash_log2.o hash_page.o \
+       hsearch.o ndbm.o
+OBJ2=  bt_close.o bt_conv.o bt_debug.o bt_delete.o bt_get.o bt_open.o \
+       bt_overflow.o bt_page.o bt_put.o bt_search.o bt_seq.o bt_split.o \
+       bt_stack.o bt_utils.o
+OBJ3=  db.o
+OBJ4=  mpool.o
+OBJ5=  rec_close.o rec_delete.o rec_get.o rec_open.o rec_put.o rec_search.o \
+       rec_seq.o rec_utils.o
+
+MISC=  snprintf.o
+INCLUDES=include/db.h include/mpool.h include/ndbm.h
+
+${LIBDB}: ${INCLUDES} ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC}
+       ar cq $@ \
+           ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC} 
+       ranlib $@
+
+CL=    ${CC} -c -O2 -m486 -I. -Iinclude
+
+install:       ${LIBDB}
+       ${INSTALL} -m 644 -o root ${LIBDB} ${LIBDIR}
+       for i in include/*.h ; do ${INSTALL} -m 644 -o root $$i ${INCDIR} ; done
+
+hash.o: ../../hash/hash.c
+       ${CL} -I../../hash ../../hash/hash.c
+hash_bigkey.o: ../../hash/hash_bigkey.c
+       ${CL} -I../../hash ../../hash/hash_bigkey.c
+hash_buf.o: ../../hash/hash_buf.c
+       ${CL} -I../../hash ../../hash/hash_buf.c
+hash_func.o: ../../hash/hash_func.c
+       ${CL} -I../../hash ../../hash/hash_func.c
+hash_log2.o: ../../hash/hash_log2.c
+       ${CL} -I../../hash ../../hash/hash_log2.c
+hash_page.o: ../../hash/hash_page.c
+       ${CL} -I../../hash ../../hash/hash_page.c
+hsearch.o: ../../hash/hsearch.c
+       ${CL} -I../../hash ../../hash/hsearch.c
+ndbm.o: ../../hash/ndbm.c
+       ${CL} -I../../hash ../../hash/ndbm.c
+
+bt_close.o: ../../btree/bt_close.c
+       ${CL} -I../../btree ../../btree/bt_close.c
+bt_conv.o: ../../btree/bt_conv.c
+       ${CL} -I../../btree ../../btree/bt_conv.c
+bt_debug.o: ../../btree/bt_debug.c
+       ${CL} -I../../btree ../../btree/bt_debug.c
+bt_delete.o: ../../btree/bt_delete.c
+       ${CL} -I../../btree ../../btree/bt_delete.c
+bt_get.o: ../../btree/bt_get.c
+       ${CL} -I../../btree ../../btree/bt_get.c
+bt_open.o: ../../btree/bt_open.c
+       ${CL} -I../../btree ../../btree/bt_open.c
+bt_overflow.o: ../../btree/bt_overflow.c
+       ${CL} -I../../btree ../../btree/bt_overflow.c
+bt_page.o: ../../btree/bt_page.c
+       ${CL} -I../../btree ../../btree/bt_page.c
+bt_put.o: ../../btree/bt_put.c
+       ${CL} -I../../btree ../../btree/bt_put.c
+bt_search.o: ../../btree/bt_search.c
+       ${CL} -I../../btree ../../btree/bt_search.c
+bt_seq.o: ../../btree/bt_seq.c
+       ${CL} -I../../btree ../../btree/bt_seq.c
+bt_split.o: ../../btree/bt_split.c
+       ${CL} -I../../btree ../../btree/bt_split.c
+bt_stack.o: ../../btree/bt_stack.c
+       ${CL} -I../../btree ../../btree/bt_stack.c
+bt_utils.o: ../../btree/bt_utils.c
+       ${CL} -I../../btree ../../btree/bt_utils.c
+
+db.o: ../../db/db.c
+       ${CL} ../../db/db.c
+
+mpool.o: ../../mpool/mpool.c
+       ${CL} -I../../mpool ../../mpool/mpool.c
+
+rec_close.o: ../../recno/rec_close.c
+       ${CL} -I../../recno ../../recno/rec_close.c
+rec_delete.o: ../../recno/rec_delete.c
+       ${CL} -I../../recno ../../recno/rec_delete.c
+rec_get.o: ../../recno/rec_get.c
+       ${CL} -I../../recno ../../recno/rec_get.c
+rec_open.o: ../../recno/rec_open.c
+       ${CL} -I../../recno ../../recno/rec_open.c
+rec_put.o: ../../recno/rec_put.c
+       ${CL} -I../../recno ../../recno/rec_put.c
+rec_search.o: ../../recno/rec_search.c
+       ${CL} -I../../recno ../../recno/rec_search.c
+rec_seq.o: ../../recno/rec_seq.c
+       ${CL} -I../../recno ../../recno/rec_seq.c
+rec_utils.o: ../../recno/rec_utils.c
+       ${CL} -I../../recno ../../recno/rec_utils.c
+
+memmove.o:
+       ${CC} -DMEMMOVE -c -O -I. -Iinclude clib/memmove.c
+mktemp.o:
+       ${CC} -c -O -I. -Iinclude clib/mktemp.c
+realloc.o:
+       ${CC} -c -O -I. -Iinclude clib/realloc.c
+snprintf.o: clib
+       ${CC} -c -O -I. -Iinclude clib/snprintf.c
+
+clib:  
+       if [ ! -L clib ] ; then ln -s ../clib . ; fi
+
+include/db.h:  
+       if [ ! -L include/db.h ] ; then ( cd include; ln -s ../../include/db.h db.h ) ; fi
+
+include/mpool.h:       
+       if [ ! -L include/mpool.h ] ; then ( cd include; ln -s ../../include/mpool.h mpool.h ) ; fi
+
+include/ndbm.h:        
+       if [ ! -L include/ndbm.h ] ; then ( cd include; ln -s ../../include/ndbm.h ndbm.h ) ; fi
+
+clean:
+       rm -f ${LIBDB} ${OBJ1} ${OBJ2} ${OBJ3} ${OBJ4} ${OBJ5} ${MISC} clib ${INCLUDES}
diff -urN orig/db.1.73/PORT/linux/include/compat.h db.1.73/PORT/linux/include/compat.h
--- orig/db.1.73/PORT/linux/include/compat.h    Thu Jan  1 01:00:00 1970
+++ db.1.73/PORT/linux/include/compat.h Tue Mar 15 09:48:06 1994
@@ -0,0 +1,223 @@
+/*-
+ * Copyright (c) 1991, 1993
+ *     The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. All advertising materials mentioning features or use of this software
+ *    must display the following acknowledgement:
+ *     This product includes software developed by the University of
+ *     California, Berkeley and its contributors.
+ * 4. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ *     @(#)compat.h    8.6 (Berkeley) 8/25/93
+ */
+
+#ifndef        _COMPAT_H_
+#define        _COMPAT_H_
+
+#include <sys/types.h>
+
+/*
+ * If your system doesn't typedef u_long, u_short, or u_char, change
+ * the 0 to a 1.
+ */
+#if 0
+typedef unsigned long  u_long;
+typedef unsigned short u_short;
+typedef unsigned char  u_char;
+#endif
+
+/* If your system doesn't typedef size_t, change the 0 to a 1. */
+#if 0
+typedef unsigned int   size_t;
+#endif
+
+/*
+ * If your system doesn't have the POSIX type for a signal mask,
+ * change the 0 to a 1.
+ */
+#if 0
+typedef unsigned int   sigset_t;
+#endif
+
+/*
+ * If your system's vsprintf returns a char *, not an int,
+ * change the 0 to a 1.
+ */
+#if 0
+#define        VSPRINTF_CHARSTAR
+#endif
+
+/*
+ * If you don't have POSIX 1003.1 signals, the signal code surrounding the 
+ * temporary file creation is intended to block all of the possible signals
+ * long enough to create the file and unlink it.  All of this stuff is
+ * intended to use old-style BSD calls to fake POSIX 1003.1 calls.
+ */
+#ifdef NO_POSIX_SIGNALS
+#define sigemptyset(set)       (*(set) = 0)
+#define sigfillset(set)                (*(set) = ~(sigset_t)0, 0)
+#define sigaddset(set,signo)   (*(set) |= sigmask(signo), 0)
+#define sigdelset(set,signo)   (*(set) &= ~sigmask(signo), 0)
+#define sigismember(set,signo) ((*(set) & sigmask(signo)) != 0)
+
+#define SIG_BLOCK      1
+#define SIG_UNBLOCK    2
+#define SIG_SETMASK    3
+
+static int __sigtemp;          /* For the use of sigprocmask */
+
+/* Repeated test of oset != NULL is to avoid "*0". */
+#define sigprocmask(how, set, oset)                                    \
+       ((__sigtemp =                                                   \
+       (((how) == SIG_BLOCK) ?                                         \
+               sigblock(0) | *(set) :                                  \
+       (((how) == SIG_UNBLOCK) ?                                       \
+               sigblock(0) & ~(*(set)) :                               \
+       ((how) == SIG_SETMASK ?                                         \
+               *(set) : sigblock(0))))),                               \
+       ((oset) ? (*(oset ? oset : set) = sigsetmask(__sigtemp)) :      \
+               sigsetmask(__sigtemp)), 0)
+#endif
+
+/*
+ * If realloc(3) of a NULL pointer on your system isn't the same as
+ * a malloc(3) call, change the 0 to a 1, and add realloc.o to the
+ * MISC line in your Makefile.
+ */
+#if 0
+#define        realloc __fix_realloc
+#endif
+
+/*
+ * If your system doesn't have an include file with the appropriate
+ * byte order set, make sure you specify the correct one.
+ */
+#ifndef BYTE_ORDER
+#define LITTLE_ENDIAN  1234            /* LSB first: i386, vax */
+#define BIG_ENDIAN     4321            /* MSB first: 68000, ibm, net */
+#define BYTE_ORDER     BIG_ENDIAN      /* Set for your system. */
+#endif
+
+#if defined(SYSV) || defined(SYSTEM5)
+#define        index(a, b)             strchr(a, b)
+#define        rindex(a, b)            strrchr(a, b)
+#define        bzero(a, b)             memset(a, 0, b)
+#define        bcmp(a, b, n)           memcmp(a, b, n)
+#define        bcopy(a, b, n)          memmove(b, a, n)
+#endif
+
+#if defined(BSD) || defined(BSD4_3)
+#define        strchr(a, b)            index(a, b)
+#define        strrchr(a, b)           rindex(a, b)
+#define        memcmp(a, b, n)         bcmp(a, b, n)
+#define        memmove(a, b, n)        bcopy(b, a, n)
+#endif
+
+/*
+ * 32-bit machine.  The db routines are theoretically independent of
+ * the size of u_shorts and u_longs, but I don't know that anyone has
+ * ever actually tried it.  At a minimum, change the following #define's
+ * if you are trying to compile on a different type of system.
+ */
+#ifndef USHRT_MAX
+#define        USHRT_MAX               0xFFFF
+#define        ULONG_MAX               0xFFFFFFFF
+#endif
+
+/* POSIX 1003.1 access mode mask. */
+#ifndef O_ACCMODE
+#define        O_ACCMODE       (O_RDONLY|O_WRONLY|O_RDWR)
+#endif
+
+/* POSIX 1003.2 RE limit. */
+#ifndef        _POSIX2_RE_DUP_MAX
+#define        _POSIX2_RE_DUP_MAX      255
+#endif
+
+/*
+ * If you can't provide lock values in the open(2) call.  Note, this
+ * allows races to happen.
+ */
+#ifndef O_EXLOCK
+#define        O_EXLOCK        0
+#endif
+
+#ifndef O_SHLOCK
+#define        O_SHLOCK        0
+#endif
+
+#ifndef EFTYPE
+#define        EFTYPE          EINVAL          /* POSIX 1003.1 format errno. */
+#endif
+
+#ifndef        WCOREDUMP                       /* 4.4BSD extension */
+#define        WCOREDUMP(a)    0
+#endif
+
+#ifndef        STDERR_FILENO
+#define        STDIN_FILENO    0               /* ANSI C #defines */
+#define        STDOUT_FILENO   1
+#define        STDERR_FILENO   2
+#endif
+
+#ifndef SEEK_END
+#define        SEEK_SET        0               /* POSIX 1003.1 seek values */
+#define        SEEK_CUR        1
+#define        SEEK_END        2
+#endif
+
+#ifndef S_ISLNK                                /* BSD POSIX 1003.1 extensions */
+#define S_ISLNK(m)      ((m & 0170000) == 0120000)
+#define S_ISSOCK(m)     ((m & 0170000) == 0140000)
+#endif
+
+#ifndef        TCSASOFT
+#define        TCSASOFT        0
+#endif
+
+#ifndef _POSIX2_RE_DUP_MAX
+#define        _POSIX2_RE_DUP_MAX      255
+#endif
+
+#ifndef NULL                           /* ANSI C #defines NULL everywhere. */
+#define        NULL            0
+#endif
+
+#ifndef        MAX
+#define        MAX(_a,_b)      ((_a)<(_b)?(_b):(_a))
+#endif
+#ifndef        MIN
+#define        MIN(_a,_b)      ((_a)<(_b)?(_a):(_b))
+#endif
+
+#ifndef DEFFILEMODE                    /* Default file permissions. */
+#define        DEFFILEMODE     (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
+#endif
+
+#ifndef _BSD_VA_LIST_
+#define        _BSD_VA_LIST_   char *
+#endif
+
+#endif /* !_COMPAT_H_ */
diff -urN orig/db.1.73/test/Makefile db.1.73/test/Makefile
--- orig/db.1.73/test/Makefile  Sun Dec 19 19:14:47 1993
+++ db.1.73/test/Makefile       Tue Mar 15 10:28:02 1994
@@ -7,7 +7,7 @@
 #VPATH=        ../recno
 OBJS=  ${OBJS1} ${OBJS2} ${OBJS3}
 
-PDIR=  ../PORT/bsd.44
+PDIR=  ../PORT/linux
 
 # Add -DSTATISTICS to CFLAGS to get btree statistical use info.
 # Note, the db library has to be compiled for statistics as well.


                        --------------------------

-- 
Al Longyear           longyear@netcom.com

------------------------------

From: cas@muffin.apana.org.au (Craig Sanders)
Subject: memory used in 1.1.x kernels?
Date: Sun, 26 Jun 1994 08:05:09 GMT


Quick question:

Can anyone tell me why the latest kernels (since around version 1.1.13
or so) use a lot more data memory than earlier versions.

For example, this extract from dmesg (v 1.1.20 at present - muffin is
compiling 1.1.22 as I type this) :

Memory: 6168k/8192k available (604k kernel code, 384k reserved, 1036k data)
                                                                ^^^^^

Up until around 1.1.13 or so, the 'data' portion was around 300K.  After
that, it jumped up to around 600-700K and has been creeping up ever
since.


FYI, my machine is:

486-sx-33 with 8MB RAM
1 x WD-1007 ESDI controller with Priam 638 ESDI disk
1 x VL-300 VLB adaptec 1522-clone SCSI controller with
        archive viper 150MB tape
        maxtor XT-4380S hard disk
        panasonic 501B CD-ROM
2 serial, 1 parallel, Trident 8900C VGA card.

I have compiled the kernel for 1522 support (with all SCSI support
except for extra kernel debugging code) ; CSLIP; PPP; minix,
ext2, msdos, iso9660 and /proc file systems; and I have edited
linux/include/linux/tty.h for 12 virtual consoles.

-- 
cas@muffin.apana.org.au


------------------------------

From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: svgalib and s3
Date: Mon, 27 Jun 1994 00:18:14 GMT

In article <2uksov$dl8@vixen.cso.uiuc.edu>, choltje@ux1.cso.uiuc.edu (Christian Holtje) says:
+---------------
| leitner@cs.tu-berlin.de (Felix v.Leitner) writes:
| >choltje@ux1.cso.uiuc.edu (Christian Holtje) writes:
| >>Just as a two center. I'd really LOVE to either have svgalib support
| >>VESA (bleech) or S3....just so I can write some stuff for it...(anyone
| 
| >BTW: Are you seriously about that VESA thingy ?  I hope you know that this
| >is impossible and really makes you look like either a clueless beginner or
| >a comedian ;)
| >Well, OK, not impossible. But nearly.
| 
| I'm new to graphics programing, but even if VESA is bleechy and slow and ugly,
| it is more portable. Why would it be impossible? And yes, I'd prefer being
+------------->8

Because VESA (and other BIOS-based APIs) only works in real mode, but Linux
runs in 386 mode.  So you can only access VESA modes from dosemu or similar.
An svgalib variant could be written to kick the machine into v86 mode and back
out whenever a video operation is performed, but it would be *very* slow and
rather risky.  (Consider that MS-Windows doesn't have a "VESA" video driver
that would work with virtually all cards... if such were viable, it would have
been done already.)

VESA has been obsoleted by protected and 386 mode OSes.  Whether a replacement
capable of being used in 386 mode will be created is up to the video card
manufacturers.

++Brandon
-- 
Brandon S. Allbery         kf8nh@kf8nh.ampr.org          bsa@kf8nh.wariat.org
Friends don't let friends load Windows NT.              Linux iBCS2 emulation

------------------------------

From: bof@wg.saar.de (Patrick Schaaf)
Subject: Re: Major device number clash (iCS)
Date: Mon, 27 Jun 1994 00:32:07 GMT

urlichs@smurf.noris.de (Matthias Urlichs) writes:
>  gareth@metl.chi.il.us (Gareth Newfield) writes:
>> 
>> example just read:
>>  /proc/devices/character/thatSortofThing/someAttribute/something/this
>> instead of parsing
>>  /proc/deviceStuffIsAllJammedInHereTogetherWithWhoKnowsWhatDelimiters
>> 
>Unfortunately, if you want all the info in /proc/devices then one big file
>is simpler (and much faster) to deal with than lots of little files.

>That's one reason why procps is rather slow.

Imagine the following:

$ cat /proc/version
$ cat /proc/devices
mem c 1
tty c 4
tty c 5
lp c 6
st c 9
fd b 2
sd b 8
$ cat /proc/devices/block
fd b 2
sd b 8
$ cat /proc/devices/char/mem
mem c 1

For a hint on implementation, stare at fs/proc/net.c:proc_readnet.
The default in the switch statement there is reached when /proc/net/
(the directory itself) is read(2).

Patrick


------------------------------

From: pagels@cs.arizona.edu (Michael A. Pagels)
Crossposted-To: comp.os.linux.help
Subject: Mach 64
Date: 27 Jun 1994 15:18:53 GMT

1) Anyone using the new PCI ATI Turbo Mach 64 based card an XFree?

2) Will XFree_mach32 drive this card?

3) Any development underway to support its extensions over Mach 32?

Guess you can tell I'm thinking about getting a Mach 64 based
system.  My main work is image analysis and Mach 64 seems to
be the way to go.....

Thanks in advance for your comments!

Michael

------------------------------

From: eduard@qdeck.com (Eduard Marghidan)
Subject: Wanted info on color printing in Linux
Date: Mon, 27 Jun 1994 15:58:06 GMT

        Since I do most of my printing in black and white, I don't really know
much about color printing, especially on printers capable of photo-realistic output.
I would like to know which color drivers are available for Ghostscript to print out
high-quality color images, as well as any other drivers that can handle large number of
colors. 
        Thanks
Eduard
eduard@qdeck.com

------------------------------

From: zmbenhal@netcom.com (Zeyd M. Ben-Halim)
Subject: Re: Need help with gcc/ncurses under 99pl15
Date: Fri, 24 Jun 1994 20:12:03 GMT

In article <2uaami$qkp@hebron.connected.com>,
Scott Wegener <wegster@connected.com> wrote:
>
>       I have had some problems running gcc 2.5.8 and the ncurses library
>with the following setup:
>OS: Linux v99pl15
>System: Intel 486sx/25
>
>#include<stdio.h>

You should not mix stdio and ncurses.

>#include<curses.h>
>#include<termio.h>

This is not needed, besides it should be termios.h

>main()
>{
>  initscr();
>  clear();
>  move(1,1);
>  puts("This is a test....");getchar();

Use:
        addstr("This is a test...");refresh();getch();
        endwin();

Nothing will display until you call refresh(). You should ALWAYS end
with endwin() otherwise the terminal will be screwed.

>  return;
>}
> 
>According to the ncurses man pages, need to include the -lncurses
>switch, but this made no difference in results at all..
>ok, so command line is: cc -lncurses test.c

Not quite: cc test.c -lncurses
the order is important. See the GCC FAQ for more details.

>If you have any ideas or suggestions I would greatly appreciate them.

While you are at it try upgrading to 1.8.5 from
ftp.netcom.com:pub/zmbenhal/ncurses/1.8.5.tgz

Zeyd


-- 
---
Zeyd M. Ben-Halim       zmbenhal@netcom.com
10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU

Linux may be obtained via one of these FTP sites:
    nic.funet.fi				pub/OS/Linux
    tsx-11.mit.edu				pub/linux
    sunsite.unc.edu				pub/Linux

End of Linux-Development Digest
******************************
