NetBSD-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
using LIBISPRIVATE
From the descriptions in bsd.README:
LIBISPRIVATE If not "no", act as "MKDEBUGLIB=no MKLINT=no MKPIC=no
MKPROFILE=no", and don't install the (.a) library.
This is useful for "build only" helper libraries.
Default: no
LIBDPLIBS A list of the tuples:
libname path-to-srcdir-of-libname
For each tuple;
* LIBDO.libname contains the .OBJDIR of the library
`libname', and if it is not set it is determined
from the srcdir and added to MAKEOVERRIDES (the
latter is to allow for build time optimization).
* LDADD gets -L${LIBDO.libname} -llibname added.
* DPADD gets ${LIBDO.libname}/liblibname.so or
${LIBDO.libname}/liblibname.a added.
The special value "_external" for LIBDO.lib makes the
build system to assume the library comes from outside
of the NetBSD source tree and only causes -llibname
to be added to LDADD.
This variable may be used for individual libraries, as
well as in parent directories to cache common libraries
as a build-time optimization.
I thought I could build a helper library in a subdirectory, e.g.,
subdir/Makefile would contain
LIB= helper
LIBISPRIVATE= yes
and then in the top directory I could
LIBDPLIBS+= helper ${.CURDIR}/helper
This doesn't seem to be working for me, as libhelper.a is built, but
the library in the root directory is looking for libhelper.so.
The description of LIBDPLIBS suggests
* DPADD gets ${LIBDO.libname}/liblibname.so or
${LIBDO.libname}/liblibname.a added.
but /usr/share/mk/bsd.lib.mk
seems to contain
DPADD+= ${LIBDO.${_lib}}/lib${_lib}.so # Don't use _LIB_PREFIX
How is liblibname.a meant to get added? (How is this supposed to work?)
Cheers,
Patrick
Home |
Main Index |
Thread Index |
Old Index