src-test/lib/liblzma/Makefile, branch main FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-06-20T21:32:07Z liblzma: Make liblzma use libmd implementation of SHA256. 2020-06-20T21:32:07Z Xin LI delphij@FreeBSD.org 2020-06-20T21:32:07Z urn:sha1:65422c964ace1c1d0b7858e7f6f655ddeedb4db4 MFC after: 2 weeks PR: 200142 Use SRCTOP-relative paths and .CURDIR with :H instead of ".." specified paths 2017-01-20T04:46:20Z Enji Cooper ngie@FreeBSD.org 2017-01-20T04:46:20Z urn:sha1:61d324734a7238af3cdad1c6284274ea91519f8a This simplifies pathing in make/displayed output MFC after: 3 weeks Sponsored by: Dell EMC Isilon First pass through library packaging. 2016-02-04T21:16:35Z Glen Barber gjb@FreeBSD.org 2016-02-04T21:16:35Z urn:sha1:a70cba95822f662d3f9da5119b6a0c433e8f70af Sponsored by: The FreeBSD Foundation Replace beforeinstall: handling with FILES. 2015-09-18T23:49:32Z Bryan Drewery bdrewery@FreeBSD.org 2015-09-18T23:49:32Z urn:sha1:de0e3997d9f8f1d857da7e9c179548dbf294ebcf This actually fixes some cases to respect LIBRARIES_ONLY. Sponsored by: EMC / Isilon Storage Division Revert r282775 for now. The added dependency would cause problems for 2015-05-12T05:42:13Z Xin LI delphij@FreeBSD.org 2015-05-12T05:42:13Z urn:sha1:0a23444a57b962959c35d5f9035105f0dc4e1bcd e.g. ports-mgmt/pkg and we would like to do an exp-build. Requested by: bdrewery Revert r281372, it's no longer needed after r282726 (fix for PR 199119) as the 2015-05-11T17:49:07Z Xin LI delphij@FreeBSD.org 2015-05-11T17:49:07Z urn:sha1:f2626e0e62c4afc09734b65a22eefa800f77a2f5 symbol conflict between libmd and libcrypto have been solved. For reasons that I am not understand yet, using the libmd version of 2015-04-10T17:21:47Z Xin LI delphij@FreeBSD.org 2015-04-10T17:21:47Z urn:sha1:36d99b08a5d196236821a4fd869d1c7d615ffa5d SHA256 would make libarchive based application to give: archive_read_extract(): Lzma library error: Corrupted input data (Internally this is LZMA_DATA_ERR) However, the libmd version of SHA256 is supposed to give same result as the bundled version do, and xz(1) is not affected. As a precaution, revert the SHA256 portion of r281316 for now until we figure out why it breaks libarchive interoperability as we can't yet rule out this change have introduced an ABI breakage. MFV r281278: 2015-04-09T18:03:27Z Xin LI delphij@FreeBSD.org 2015-04-09T18:03:27Z urn:sha1:342bcb12328e23c22789253504c5664cfece4a9b - Update xz to 5.2.1, where the most visible change is that it fixed a compression-ratio regression in fast mode LZMA1 and LZMA2 and used cpuset_getaffinity() for CPU cores detection. - Make liblzma use the base system SHA256 implementation instead of the bundled one. - Additional annotation in config.h for FreeBSD specific tweaks. - Refresh symbols in XZprivate_1.0 to reflect reality. Relnotes: yes MFC after: 1 month (TBD) Merge xz 5.2.0. 2015-02-09T06:20:34Z Rui Paulo rpaulo@FreeBSD.org 2015-02-09T06:20:34Z urn:sha1:532000256b898d5d3b0067ffa328715d18f4776d This brings support for multi-threaded compression. This brings close N times faster compression where N is the number of CPU cores. Because of this, liblzma now depends on libthr. Soon libarchive will be modified to use the new lzma API. Thanks to antoine@ for the exp-run. Differential Revision: https://reviews.freebsd.org/D1786 Reviewed by: bapt Do not regenerate and install liblzma.pc when only build libraries 2015-01-11T09:25:01Z Baptiste Daroussin bapt@FreeBSD.org 2015-01-11T09:25:01Z urn:sha1:910824cea4e3b2c81346ba49bedf74a117bc203f aka do not regenerate while generating 32bits libs Reported by: antoine