yamato link-collisions # nm -D /usr/bin/cmake | grep libtar 08242580 T libtar_hash_add 08242750 T libtar_hash_del 08242700 T libtar_hash_empty 082426a0 T libtar_hash_free 08242600 T libtar_hash_getkey 08242570 T libtar_hash_nents 082428b0 T libtar_hash_new 082427b0 T libtar_hash_next 08242860 T libtar_hash_search 08242690 T libtar_hashptr_data 08242920 T libtar_hashptr_reset 08242be0 T libtar_list_add 08242d10 T libtar_list_add_str 08242b00 T libtar_list_del 08242b60 T libtar_list_empty 08242bb0 T libtar_list_free 08242970 T libtar_list_iterate 082429d0 T libtar_list_nents 08242d90 T libtar_list_new 082429e0 T libtar_list_next 08242a20 T libtar_list_prev 08242a60 T libtar_list_search 08242960 T libtar_listptr_data 08242950 T libtar_listptr_reset 08242550 T libtar_str_hashfunc 08242ad0 T libtar_str_match 08298e3c R libtar_version
It appears that libtar is in Portage, as dev-libs/libtar. Unfortunately, upstream libtar seems dead and it is marked as maintainer-needed in Portage. The last released version <ftp://ftp.feep.net/pub/software/libtar/libtar-1.2.11.tar.gz> is timestamped 03/02/03 00:00:00. There are various messages on its mailing lists about how the maintainer no longer has time to work on it. A cursory diff between the libtar.c in CMake and the source from dev-libs/libtar reveals non-trivial differences. I have not checked how much of this is a consequence of CMake fixes versus version deviation. The upstream CMake changelog records the addition of libtar files, but does not indicate what version of libtar was imported. CMake still uses CVS for their version control, and as best I can tell, the version of libtar was not recorded in a CVS log message either. Given that CMake imported libtar in 2005, I would hope that they grabbed libtar-1.2.11, the last released version.
I'm not convinced it makes sense to use the semi-abandoned libtar... perhaps something will come out of libtar-ng project and cmake upstream will adopt to it. :-/ See, http://lists.freedesktop.org/archives/distributions/2009-December/000385.html https://bugzilla.redhat.com/show_bug.cgi?id=546169 https://fedorahosted.org/libtar-ng/browser
In any case, I've synced our libtar with Debian and polished it up to build shared library too (and optionalize static-libs) in case you want to try it anyway. It might be good while before this libtar-ng projects gets any ground under it's feets....
(In reply to comment #3) > In any case, I've synced our libtar with Debian and polished it up to build > shared library too (and optionalize static-libs) in case you want to try it > anyway. Thanks for the effort, but it may be a while before you get a tester. Diego posted the bug as part of a general effort against bundled libraries. Based on the machine where he ran it, this was from his tinderbox-related work, rather than a personal system. I posted an analysis in the hope that it would be useful in advancing the anti-bundling work that Diego started, but I have no personal stake in either cmake or libtar. I have no direct experience with either and do not even have a standalone libtar installed.
2.8.3 no longer bundles it. It uses system libarchive. Please reopen this bug if you still think it is issue in 2.8.3.
