Bindings to use 7-zip as a library from golang.
sevenzip-go needs two dynamic libraries to operate, and it expects them to be in the executable's folder.
For example
foobar.exe
, c7zip.dll
, and 7z.dll
in the same directoryfoobar
, libc7zip.so
, and 7z.so
in the same directoryfoobar
, libc7zip.dylib
, and 7z.so
in the same directoryNote: the 7-zip library is called 7z.so
on macOS, that's not a typo.
If it can't find it, it'll print messages to stderr (and return an error).
sevenzip-go was made primarily to serve as a decompression engine for https://github.com/itchio/butler
most of butler's functionality does not require 7-zip, and:
7z.dll
from the official 7-zip builds (it is a notorious pain to build, as it requires MSVC 2010)While the whole setup sounds crazy (especially considering the whole Go->cgo->C->C++->COM/C++ pipeline), it fits all those goals.
Pay attention to the dynamic library requirement above:
Neither sevenzip-go nor lib7zip look for DLLs in the
PATH
orLD_LIBRARY_PATH
orDYLD_LIBRARY_PATH
, they only look in the executable's directory. This is on purpose, so we don't accidentally load an older version of 7-zip.
The library allocates memory via C functions, so you should make sure to call .Free()
on the
various objects you get from sevenzip-go.
Error handling is best-effort, but there's many moving pieces involved here. Some items of an archive
may fail to extract, the errors can be retrieved with extractCallback.Errors()
(which returns a slice of
errors).
The ./cmd/go7z
package
sevenzip-go is released under the MIT license, see the LICENSE
file.
Other required components are distributed under the MPL 2.0, the LGPL 2.1, and
other terms - see their own LICENSE
or COPYING
files.