On Tue, Jun 5, 2012 at 8:17 AM, Eric Noulard <eric.noul...@gmail.com> wrote: > 2012/6/5 Kornel Benko <kor...@lyx.org>: > Somebody shall dive into the build process of the libarchive Ubuntu package > and > see **why** it breaks the CMake build while using cmlibarchive does not.
This is the proper action. What version of libarchive is used from the system? The builtin cmlibarchive in CMake 2.8.8 is libarchive 3.0.2, from svn rev 4051, now Git commit 28267d8f: https://github.com/libarchive/libarchive/tree/28267d8f/ plus some portability fixes. > This "may-be" a usage error on CMake side (and I'll try to help to fix it) > but this may well be a mistake on libarchive/Ubuntu side as well. [snip] > Yes but this action was widening the compatibility. > pax_restricted --> gnutar may be narrowing it. This was discussed here: http://www.cmake.org/Bug/view.php?id=11958 but many archive portability concerns were lifted by updating to a libarchive that included this: https://github.com/libarchive/libarchive/commit/de60ddd0 The issue was resolved without changing formats by a fix suggested by a libarchive maintainer: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e8558efa If there are extended headers that dpkg doesn't support then we need to know why they appear in the first place and which ones can be cleared. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
