[blfs-dev] Odd failure in heirloom-mailx

Richard Melville 6tricky9 at gmail.com
Tue Apr 11 10:37:40 PDT 2017

On 10 April 2017 at 16:27, Ken Moffat <zarniwhoop at ntlworld.com> wrote:

> On Mon, Apr 10, 2017 at 03:44:12PM +0100, Richard Melville wrote:
> > On 9 April 2017 at 22:45, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> >
> > Ken, I'm tagging on to the end of this post, not because I have an answer
> > to your issue, but because, coincidently, I'm looking at mailx at the
> > moment and I can see that you are the owner of the patch.
> >
> For the moment, I don't have a problem (it built in the end) so I'm
> not actively looking for an answer.
> And I'm not sure that I own the patch - I took the fixes from debian
> and redhat.
> > I've found another issue which, maybe, could be added to your patch.
> Mailx
> > is supposed to look for NSS first before falling back to OpenSSL.  I have
> > NSS installed and it didn't find it.  On examining the config.log I can
> see
> > that it's looking in /usr/include/ssl.h when the NSS header is actually
> at
> > /usr/include/nss/ssl.h.  In the book we create the /usr/include/nss
> > directory but this clearly breaks the mailx build.
> >
> > Richard
> It sounds like you are in a position the fix the patch and test it!

I appreciate your faith in me Ken, but I think it might be misplaced.
Anyway, the wierdness continues.  Despite the mailx documentation claiming
that it can be built with nss support by adding both nspr and nss header
directories to the make file it steadfastly refuses to accept both; it only
reads the second one in my script.  I've tried reversing them but it's
always only the second entry that gets read.

I finally got it to build with a horrible hack: changing the paths of six
nss header files in four different mailx files.  Whether it runs or not
remains to be seen; I'm still in chroot.  If you, or anybody else, have any
better ideas they would be very welcome.

I've contacted the mailx developer to see if I can get an answer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/blfs-dev/attachments/20170411/53f0baf9/attachment.html>

More information about the blfs-dev mailing list