Bug 210626 - archivers/libarchive: Fails to build when archivers/lzmalib is installed
Summary: archivers/libarchive: Fails to build when archivers/lzmalib is installed
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: needs-patch, needs-qa, patch
: 213765 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-27 13:56 UTC by ob
Modified: 2018-05-30 18:04 UTC (History)
5 users (show)

See Also:
koobs: maintainer-feedback? (glewis)
koobs: merge-quarterly?


Attachments
Error log libarchive building with lzmalib installed (7.78 KB, text/plain)
2016-06-27 13:56 UTC, ob
no flags Details
svn-diff_archivers_libarchive (795 bytes, patch)
2016-08-14 03:32 UTC, w.schwarzenfeld
no flags Details | Diff
svn-diff_archivers_libarchive_corrected (730 bytes, patch)
2016-08-15 09:58 UTC, w.schwarzenfeld
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ob 2016-06-27 13:56:24 UTC
Created attachment 171867 [details]
Error log libarchive building with lzmalib installed

If archivers/lzmalib is installed building archivers/libarchive stops with an error.
Comment 1 w.schwarzenfeld freebsd_triage 2016-06-28 19:00:21 UTC
lzmalib is only need by two ports: /archivers/p5-Compress-Raw-Lzma and databases/tokyocabinet. Both have OPTIONS to change.
Comment 2 w.schwarzenfeld freebsd_triage 2016-08-12 18:50:07 UTC
temporary solution for 10.3 (i386,amd64) and 11.0
.if ${OSVERSION} < 1000000 
CFLAGS+=        "-I${LOCALBASE}/include"
CPPFLAGS+=      "-I${LOCALBASE}/include"
LDFLAGS+=       "-L${LOCALBASE}/lib"
.endif

On 9.3 works with poudriere but not in the port
Comment 3 w.schwarzenfeld freebsd_triage 2016-08-14 03:32:03 UTC
Created attachment 173647 [details]
svn-diff_archivers_libarchive
Comment 4 w.schwarzenfeld freebsd_triage 2016-08-14 03:33:36 UTC
Got my wires crossed.. was simple - was only the missing LIB_DEPENDS and removing the compiler-flags.
This works now with 93 and 103.
Comment 5 w.schwarzenfeld freebsd_triage 2016-08-15 09:58:00 UTC
Created attachment 173697 [details]
svn-diff_archivers_libarchive_corrected
Comment 6 w.schwarzenfeld freebsd_triage 2016-08-15 12:17:45 UTC
No, still no works with 9.3 ports.
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2016-10-25 09:43:25 UTC
Maintainer timeout (4+ months), open to take.

@Walter If the current version of the patch does not fix the issue on certain version(s) of FreeBSD, the patch should also include a BROKEN message for OSVERSION(s) that match.

Having said that, adding lzma as an unconditional dependency (as attachment 173697 [details] does is only a workaround)

I also note that there are no explicit --without flags being provided to configure for lzma by the port, but the ./configure script provides at least these options:

  --without-lzmadec       Don't build support for lzma through lzmadec
  --without-lzma          Don't build support for xz through lzma

Further, the CMake build (which the port does not use) configuration provides:

CMakeLists.txt:IF(ENABLE_LZMA)
CMakeLists.txt:  FIND_PACKAGE(LZMA)

Allowing lzma to be explicitly disabled unless otherwise enabled (in the port, or by an option). Note also there are lzma *specific* variables to provide include/library locations.

All of the above is orthogonal to the removal of unconditional and global *FLAGS is, which should be only be used as a last resort in most port cases, *particularly* those ports that have multiple optional dependencies that all live at the same location, making accidental autodetection and linking more than common. Unfortunately global use of *FLAGS has been made way too easy with USES=localbase.

Finally, this port overall requires a refactor and improvements to bring it into line with correct and robust ways to do things, including optional dependencies.
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2016-10-25 09:44:16 UTC
*** Bug 213765 has been marked as a duplicate of this bug. ***
Comment 9 w.schwarzenfeld freebsd_triage 2016-10-25 10:29:33 UTC
In not at home the next few days. Next week I will look to find the correct way to solve this (if not someone other does it). Thank you.
Comment 10 w.schwarzenfeld freebsd_triage 2016-12-16 13:47:47 UTC
I don't know if it makes really sense to do here something. Cause it is the pathproblem 
lzma and lzmalib, appeared in other ports like archivers/rpm4 (I had to deinstall lzmalib, update 
this port and reinstall lzmalib) or textproc/silversearcher and some port I don't know by
hard. I think it is a problem for eight or ten ports on my system.
Comment 11 w.schwarzenfeld freebsd_triage 2016-12-16 18:56:42 UTC
another problem I found few minutes ago with math/R:
checking for lzma_version_number in -llzma... no
configure: error: "liblzma library and headers are required"
===>  Script "configure" failed unexpectedly.
Please report the problem to jrm@FreeBSD.org [maintainer] and attach the
"/ram/usr/ports/math/R/work/R-3.3.2/config.log" including the output of the
failure of your make command. Also, it might be a good idea to provide an
overview of all packages installed on your system (e.g. a
/usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1
Comment 12 w.schwarzenfeld freebsd_triage 2017-01-20 20:36:52 UTC
I know the solution for me, that i found would nobody accept.
But I write my own "archivers.mk". Linking /usr/lib/liblzma.so to another directory and set LDFLAGS+=
to this directory. and solved my problems of all ports with liblzma in this way.
Comment 13 w.schwarzenfeld freebsd_triage 2017-02-13 10:25:29 UTC
9.3 is gone. I think we can use the patch.
Comment 14 eserte12 2017-02-20 07:03:01 UTC
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217244
Comment 15 Kubilay Kocak freebsd_committer freebsd_triage 2017-07-05 12:10:36 UTC
I'll need to re-review this to bring myself back up to speed, in the meantime re-assign to the pool (apologies).

I'm -1 on landing patches only on the basis of a specific FreeBSD versions being EoL'd. The root cause should be identified (if it hasn't already) and resolved.

If there are multiple symptoms of the same underlying cause (See Also: Bug 209355 affecting lang/python*), and it appears there are, a single blocking parent issue to resolve the root cause should be created
Comment 16 w.schwarzenfeld freebsd_triage 2018-02-01 10:43:47 UTC
It does not effect lang/python* anymore. I think this could be committed.
Comment 17 w.schwarzenfeld freebsd_triage 2018-02-01 10:45:19 UTC
Sorry, this was wrong. It does not effect qt5-webkit anymore, the problem with python* still exists.