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
effect.
> 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
this.
> 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
mouse@collatz.mcrcim.mcgill.edu