libarchive >= 3.3 no longer links to liblzo2 automatically, and falls back on
the lzop executable instead. This means we need to check at runtime whether
libarchive has been built against liblzo. If not, we look for the lzop
executable.
Details
Details
- Reviewers
rthomsen - Commits
- R36:01c4b21050cf: Check whether tar.lzo format is available
extracttest and loadtest no longer fail with libarchive 3.3 + lzop not
installed. Also, tar.lzo mimetype is now listed in CreateDialog in such cases.
Diff Detail
Diff Detail
- Repository
- R36 Ark
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
| kerfuffle/pluginmanager.cpp | ||
|---|---|---|
| 261–264 | Do we need to check in /usr/local/lib{,64} as well? | |
| kerfuffle/pluginmanager.cpp | ||
|---|---|---|
| 261–264 | And /usr/lib/<arch-triplet>/ too | |
| kerfuffle/pluginmanager.cpp | ||
|---|---|---|
| 261–264 | This could be a can of worms (think about possible local installation path, or other OSs...) | |
| kerfuffle/pluginmanager.cpp | ||
|---|---|---|
| 261–264 | Right, hardcoding the path is not going to scale, I need to find a way to automatically get the path that will be used... | |
Comment Actions
- Don't hardcode absolute path, use ldd to figure out the actual libarchive path instead.
Comment Actions
- Don't just look in the first library path, iterate over all of them until a plugin is found.