On 2016/12/08 17:04, Marc Espie wrote:
> On Thu, Dec 08, 2016 at 12:54:05PM +0000, Stuart Henderson wrote:
> > On 2016/12/07 16:09, Bryan Vyhmeister wrote:
> > > Adding libnspsl manually solved the problem. A quick look at the
> > > Makefile for www/netsurf/browser seems to indicate that libnspsl should
> > > have been pulled in but perhaps I was looking at the wrong thing. Any
> > > idea what the issue might be that is causing libnspsl to be left out
> > > when installing netsurf and its dependencies?
> >
> > Anthony fixed it, but here's some more info. At the end of build you see
> > this:
> >
> > ===> Building package for netsurf-3.6p0
> > Create /usr/ports/packages/amd64/all/netsurf-3.6p0.tgz
> > LIB_DEPENDS STEM->=0.1.0:www/netsurf/libnspsl not needed for
> > www/netsurf/browser ?
> > Link to /usr/ports/packages/amd64/ftp/netsurf-3.6p0.tgz
> > Link to /usr/ports/packages/amd64/cdrom/netsurf-3.6p0.tgz
> >
> > This indicates that libnspsl is in LIB_DEPENDS but no library from that
> > package is listed in WANTLIB. I wonder if we should turn this into a hard
> > error.
> > bsd.port.mk(5) says:
> >
> > : LIB_DEPENDS <spec> not needed for <FULLPKGPATH> There doesn't seem to be
> > : any WANTLIB to match the given LIB_DEPENDS. Thus, the LIB_DEPENDS won't
> > : turn into a @depends line in the created package. This is often because
> > of
> > : confusion between LIB_DEPENDS and RUN_DEPENDS: RUN_DEPENDS is needed for
> > : dlopen'd libraries.
> > :
> > : Might be intentional sometimes, if some compile flavors create static
> > : binaries, for instance.
> >
> > People can cope with flavours by setting LIB_DEPENDS conditionally.
> >
> > : Also, will happen for multi-packages, where one
> > : sets LIB_DEPENDS to have a given build dependency (and corresponding
> > WANTLIB
> > : for a given SUBPACKAGE).
> >
> > I don't understand this case, if something is in LIB_DEPENDS then there
> > should be a WANTLIB, if there isn't a need for a WANTLIB entry then there
> > isn't a need for a LIB_DEPENDS entry either.
>
> You are forgetting about static libraries.
> Even though we no longer have static-only architectures, keeping the
> possibility to work with static libraries (for instance in flavors) is
> still desireable.
If it's for a static FLAVOR, is there a reason why we can't just have it
like this?
.if ${FLAVOR:Mstatic}
BUILD_DEPENDS+= foo
.else
LIB_DEPENDS+= foo
WANTLIB+= foo
.endif
(Although I sometimes specifically add an "Extra" LIB_DEPENDS/WANTLIB
for a static FLAVOR - if e.g. libc has a major bump because a kernel
interface changed, it's nice to get the static package updated without
having to manually bump REVISION)
When somebody sees that message, it usually means there was a mistake.
