According to Jan Harkes:
>
>Ok, do you think my current solution would be ok? I'm basing the include
>on the availability of the ncurses.h header file. AFAIK only cmon seems
>to be using curses.
>
Yes, that sounds ok and, yes, I believe that you are correct that only
cmon requires curses.
>
>I believe it is actually a compiler/configuration problem in NetBSD.
>
Agreed.
>The libraries built from /usr/pkgsrc end up in /usr/pkg/lib, but this
>path is not searched by default by the compiler/linker and the dynamic
>loader.
>
No, it is worse than that - the binaries get installed with dynamic
library dependencies pointing to a ".libs" directory - I think, it has
been a while since I looked at this - anyway, they binaries still are
in the "run from the local compile directory mode" not the installed
mode where they should be looking in /usr/pkg/lib as you noted. The
linker flags look right to me, I suspect that it stems from some
lossage with libtool. At the moment libtool is a mystery to me, I
need to get my head around what it does and how it does it - at first
look it seems an insanely complex hack for not much benefit.
>
>Maybe adding the following line to ld.so.conf will help at least the
>run-time loader.
>
No, NetBSD no longer has a ld.so.conf file on architectures that are
ELF based. Most NetBSD architectures are ELF or are moving to ELF.
>. Essentially
>/usr/pkg/include and /usr/pkg/lib need to be added to the default
>include and library searchpaths.
>
Yes, that bit is correct AFAICT, the -L and -R paths are set on the
linking command and look right to me.
I can get things linked correctly if I munge the link command not to
use the .ra file but put the -l<lib> entries on the command line, I
need to have the libraries installed first but the resultant binaries
do run correctly.
--
===============================================================================
Brett Lymn, Computer Systems Administrator, BAE SYSTEMS
===============================================================================
