Re: Problems building devel/subversion-base on MacOS X 10.8

["OBATA Akio" <obache%netbsd.org@localhost>]

On Fri, 26 Jul 2013 18:15:09 +0900, Jens Rehsack <sno%netbsd.org@localhost> 
wrote:

> Am 17.07.2013 um 21:32 schrieb Hauke Fath 
> <hauke%Espresso.Rhein-Neckar.DE@localhost>:
>
> > At 13:07 Uhr +0200 17.7.2013, Jens Rehsack wrote:
> > > ===> Building for subversion-base-1.8.0nb1
> >
> > [...]
> >
> > > libtool: link:
> > > `/tmp/pkgsrc/devel/subversion-base/work/.buildlink/lib/libiconv.la' is not
> > > a valid libtool archive
> > > *** Error code 1
> > >
> > > Well - I did some basic research, pkgsrc always uses the
> > > libiconv from /usr/lib - no way to negotiate ;)  And there is
> > > no /usr/lib/libiconv.la (regardless it would be linked to
> > > /tmp/pkgsrc/devel/subversion-base/work/.buildlink/lib/).
> >
> > FWIW, I see this on two netbsd-6 machines, too. pkgsrc sources of today.
>
> Thanks to joerg@ I tracked it down to textproc/groff's hard requirement of
> converters/libiconv as dependency error (should use builtin, too …).
>
> www/serf creates libserf-1.la and includes $PREFIX/lib/libiconv.la for some
> kind of reason (I think that's probably one way libtool operates). I don't
> know if it would be reasonable to forbid access to $PREFIX/lib for libtool
> itself ...
>
> I suggest first to apply attached patch to textproc/groff to avoid that
> libiconv dependency.

${PREFIX}/lib/charset.alias is always used in groff, independent of whether
builtin libiconv or not, because groff itself is not using libiconv.
So I feel that hard dependency on converters/libiconv is right.

Or if it is true (for builtin libiconv, groff should use builtin charset.alias, too 
…),
groff itself must be fixed.
(but I cannot find biltin charset.alias for NetBSD builtin libiconv)
--
OBATA Akio / obache%NetBSD.org@localhost