Subject: Re: Trouble building the libraries
To: None <current-users@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: current-users
Date: 08/02/1995 06:47:43
> First, nowhere in the tar's did there seem to be the corresponding
> current /include files.

These normally live in /usr/src/include.  If your source tree doesn't
have .../include, it's rather seriously broken.  Perhaps you picked up
a source tree broken by the sup that deleted lots of stuff?

> In libl, there aren't any files other than Makefile.  It's looking for
>     SRCS=	libmain.c libyywrap.c
> which don't exist.

No clue.

> In libtputs (?), I get the following compile error:
>     cc -O -DCM_N -DCM_GT -DCM_B -DCM_D  -c tputs.c 
>     tputs.c:69: conflicting types for `tputs'
>     /usr/include/curses.h:338: previous declaration of `tputs'
>     *** Error code 1

libterm, I think.  The problem is that your <curses.h> is out-of-date;
go to lib/libcurses, do "make && make install", or even just do
"make -n install" and retype the curses.h install command by hand.
Then go back and redo the build in libterm.

> I also have more or less of a question about the libraries.  They
> don't include libfl, libg++, libgcc, or libgnumalloc, which I got
> from the binary release last year.  Have these been eliminated or
> integrated into other libraries?

libg++ and libgnumalloc are built from gnu/lib, not lib.  libgcc is
built as part of gcc, in gnu/usr.bin/gcc2.  libfl I don't recognize.

> Finally, a couple of problems with mount.  I have accidentally
> mounted two drives/filesystems to the same directory a couple of
> times, and the system didn't complain about it.  I didn't dare test
> what it would do at the mounting point.

I think you'll find that the last-made mount is the one that takes

> There ought to be a way to prevent multiple mounts to the same
> directory.

You don't really want to in general; imagine

/sources/src on /usr/src type null
<above>:/var/src on /usr/src type union

> As a side note to that, I had a union mount duplicated a couple of
> times and doing any kind of operation in that directory resulted in
> the program going into an infinite loop.

More likely the unionfs code in the kernel deadlocking with itself;
there's no reason why user-land code would infinite loop because of

> Secondly, I can perform a union mount as a regular user, but I can't
> unmount the same directory:

No ideas from me.

					der Mouse