Created attachment 171867 [details] Error log libarchive building with lzmalib installed If archivers/lzmalib is installed building archivers/libarchive stops with an error.
lzmalib is only need by two ports: /archivers/p5-Compress-Raw-Lzma and databases/tokyocabinet. Both have OPTIONS to change.
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
Created attachment 173647 [details] svn-diff_archivers_libarchive
Got my wires crossed.. was simple - was only the missing LIB_DEPENDS and removing the compiler-flags. This works now with 93 and 103.
Created attachment 173697 [details] svn-diff_archivers_libarchive_corrected
No, still no works with 9.3 ports.
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.
*** Bug 213765 has been marked as a duplicate of this bug. ***
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.
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.
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
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.
9.3 is gone. I think we can use the patch.
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217244
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
It does not effect lang/python* anymore. I think this could be committed.
Sorry, this was wrong. It does not effect qt5-webkit anymore, the problem with python* still exists.
Over to maintainer.
Still able to reproduce this issue
Note that archivers/lzmalib expired yesterday, so this should be OBE.