Bug 224156 - www/hiawatha: Build fails with XSLT support disabled
Summary: www/hiawatha: Build fails with XSLT support disabled
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Tobias Kortkamp
Depends on:
Reported: 2017-12-07 03:18 UTC by Ross McKelvie
Modified: 2018-11-30 09:40 UTC (History)
3 users (show)

See Also:
portmaster: maintainer-feedback+

Poudriere testport logs for working and failing builds of www/hiawatha (70.96 KB, text/x-log)
2017-12-07 03:18 UTC, Ross McKelvie
no flags Details
svn diff for www/hiawatha (1.45 KB, patch)
2018-01-04 07:00 UTC, Chris Hutchinson
portmaster: maintainer-approval+
Details | Diff
hiawatha.diff (1.21 KB, patch)
2018-11-16 19:22 UTC, Tobias Kortkamp
tobik: maintainer-approval? (portmaster)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ross McKelvie 2017-12-07 03:18:04 UTC
Created attachment 188605 [details]
Poudriere testport logs for working and failing builds of www/hiawatha

www/hiawatha builds with default options but fails to build if XSLT support is disabled whilst TLS support is enabled.

The build error relates to a missing header for the mbed TLS library (previously known as PolarSSL).  I believe that this is because disabling XSLT support means that the include "-I/usr/local/include", where the mbed TLS headers reside, is not present in the compiler arguments.

I've attached poudriere testport logs for both builds.  In the successful build the compiler includes are "-I. -I/usr/local/include/libxml2 -I/usr/local/include".  In the failed build they are "-I .".

I'm not especially familiar with cmake or Ninja, used in the port build.  However, looking at CMakeLists.txt, I see on line 120 that there is a call to "include_directories()" for the XML and XSLT libraries.  There is no such call for the mbed TLS library when USE_SYSTEM_MBEDTLS is set, though as per line 117, there is a call to include_directories() if the bundled mbed TLS library is being used.  I suspect that the build may only be successful since the mbedtls directory happens to be in the same place as the libxslt library. Perhaps someone more familiar with cmake may be able to comment?
Comment 1 Chris Hutchinson 2018-01-04 03:21:01 UTC
OK just for the record. I've now got a (mostly)
working dev box again. So I'm now taking a look
at this. Should have something within the next
couple days.

Thanks for the report, Ross!

Comment 2 Chris Hutchinson 2018-01-04 07:00:41 UTC
Created attachment 189386 [details]
svn diff for www/hiawatha

OK the attached svn diff fixes the problem reported.
Works/tested on 12-CURRENT

While this patch fixes the problem reported by Ross,
and still supports the MBEDTLS option. I was forced to
remove the USE_SYSTEM_MBEDTLS option. It looks to me that
Chris Petrik has reversed the logic in one of the cmake(1)
files. So I'll work with him to solve that. But didn't want
that to postpone a fix. So here it is! :-)

Thanks again, Ross, for reporting this!

Comment 3 Tobias Kortkamp freebsd_committer 2018-11-16 19:22:58 UTC
Created attachment 199280 [details]

Here's a different patch, which doesn't require disabling use of the system
mbedtls, based on the suggestion by Ross in comment #1 about /usr/local/include.
Comment 4 commit-hook freebsd_committer 2018-11-30 09:40:10 UTC
A commit references this bug:

Author: tobik
Date: Fri Nov 30 09:39:51 UTC 2018
New revision: 486241
URL: https://svnweb.freebsd.org/changeset/ports/486241

  www/hiawatha: Unbreak build with XSLT=off

  ${LOCALBASE}/include is implicitly added to the search path when
  Hiawatha is built with XSLT=on.  Without it the system mbed TLS
  headers cannot be found anymore.  Add USES=localbase:ldflags to the
  MBDEDTLS option to work around this.

  src/filehashes.c:27:10: fatal error: 'mbedtls/sha256.h' file not found
  #include "mbedtls/sha256.h"

  - While here reset maintainer and take maintainership after the
    third consecutive timeout

  PR:		224156
  Reported by:	Ross McKelvie <ross@exitzero.uk>
  Approved by:	portmaster@BSDforge.com (maintainer timeout, 2 weeks)