> i just installed netbsd-1.3 on my alpha here and tried to compile
> the following simple program:
> 
> #include <iostream.h>
> void main() {
>   int x=0;
>   cout << x++ << x++ << x++ << endl;
> }
> 
> g++ doh.C yeilds:
> /usr/lib/libcurses.so.2: undefined reference to `tgetnum'
> /usr/lib/libcurses.so.2: undefined reference to `tgoto'
> /usr/lib/libcurses.so.2: undefined reference to `tgetflag'
> /usr/lib/libcurses.so.2: undefined reference to `tputs'
> /usr/lib/libcurses.so.2: undefined reference to `tgetent'
> /usr/lib/libcurses.so.2: undefined reference to `tgetstr'

Sounds like you need to link with -ltermcap.

Because -lcurses always requires -ltermcap (right), either the libg++
library (which links with libcurses), or libcurses itself should link
with libtermcap.  Really, the latter should, but because of the way
the NetBSD build process is (broken 8-), that's not as easy as having
the former do so.


> and i noticed that ldconfig is not installed on the system :(

Uh, what makes you think ldconfig would or could help you with this
problem?  ("It can't, and won't.")

In general, ELF systems don't need ldconfig or similar functionality,
because programs are supposed to include the paths to their libraries.
ldconfig is not present on NetBSD/alpha because it is not needed.

Some say that ldconfig and its notion of library path configuration
are better than the way such things are normally done in ELF systems,
and i wouldn't argue that one way or another.  However, in my opinion,
using ldconfig or similar mechanisms to specify library paths _in
addition_ to the "native" ELF notion of building paths into binaries
is nonsensical.  Also, the traditional "a.out ldconfig" behaviour
(namely, caching library locations) is not significantly (and perhaps
not even measurably) better than normal ELF library lookups, and has
some very annoying side effects.



cgd