MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010162CMakeCPackpublic2010-01-19 15:402012-06-01 02:39
ReporterEric NOULARD 
Assigned ToEric NOULARD 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionCMake 2.8.8Fixed in VersionCMake 2.8.8 
Summary0010162: CPack Cannot create binary zip archive containing shared libs
DescriptionUsing current CVS HEAD (on Debian Linux host) I'm not able to build a
zip file containing
installed libraries with symbolic links using
set_target_properties(... VERSION ... SOVERSION).

This used to work before (e.g. CMake 2.8.0 does not trigger the bug).

You'll find attached an example project which should (re)produce the bug.
Configure the project and do "make package".
Then look into the CMakeLists.txt and toggle the "set_target_properties" line
to make the bug appear/disappear.

I did not manage to track down which change(s) in the CMake CVS tree
made this happen, but I'm sure some of you will find faster than me.

I may file a bug in the tracker but since CVS HEAD is a moving target...
Steps To Reproduce
Additional InformationBill said:
You should file a bug. This most likely is because we switched to libarchive for creation of the tar and zip files.
TagsNo tags attached.
Relationships
related to 0005430closed Eric NOULARD cpack does not preserve symbolic links in the source distribution tarball 
related to 0013251closed Brad King cmake -E tar <file> fails to extract some files correctly 
Attached Fileszip CMZipSharedLib-0.1.1-Source.zip (1,548) 2010-01-19 15:40
https://public.kitware.com/Bug/file/2787/CMZipSharedLib-0.1.1-Source.zip
Issue History
Date ModifiedUsernameFieldChange
2010-01-19 15:40Eric NOULARDNew Issue
2010-01-19 15:40Eric NOULARDFile Added: CMZipSharedLib-0.1.1-Source.zip
2010-07-09 19:01Eric NOULARDStatusnew => assigned
2010-07-09 19:01Eric NOULARDAssigned To => Eric NOULARD
2010-07-09 19:02Eric NOULARDNote Added: 0021345
2010-07-26 06:39Eric NOULARDAssigned ToEric NOULARD =>
2010-07-26 07:07Eric NOULARDNote Added: 0021478
2010-07-26 07:18Eric NOULARDNote Added: 0021479
2010-07-26 07:29Eric NOULARDRelationship addedrelated to 0005430
2010-12-15 09:05David ColeAssigned To => Bill Hoffman
2011-12-30 18:22Eric NOULARDNote Added: 0028079
2012-01-10 15:44Brad KingNote Added: 0028243
2012-01-10 15:44Brad KingAssigned ToBill Hoffman => Brad King
2012-01-10 16:04Eric NOULARDNote Added: 0028245
2012-01-10 17:30Eric NOULARDNote Added: 0028247
2012-01-11 08:01Brad KingNote Added: 0028260
2012-01-11 08:01Brad KingAssigned ToBrad King => Eric NOULARD
2012-01-11 08:01Brad KingTarget Version => CMake 2.8.8
2012-01-11 08:58Eric NOULARDNote Added: 0028261
2012-01-11 08:58Eric NOULARDStatusassigned => closed
2012-01-11 08:58Eric NOULARDResolutionopen => fixed
2012-01-11 08:58Eric NOULARDFixed in Version => CMake 2.8.8
2012-01-11 09:24Eric NOULARDNote Added: 0028263
2012-01-11 09:24Eric NOULARDStatusclosed => feedback
2012-01-11 09:24Eric NOULARDResolutionfixed => reopened
2012-01-11 09:24Eric NOULARDNote Added: 0028264
2012-01-11 09:24Eric NOULARDStatusfeedback => assigned
2012-01-11 09:24Eric NOULARDStatusassigned => confirmed
2012-01-11 09:24Eric NOULARDStatusconfirmed => assigned
2012-01-11 09:59Eric NOULARDNote Added: 0028266
2012-01-11 16:47Eric NOULARDNote Added: 0028270
2012-01-12 02:12Eric NOULARDNote Added: 0028273
2012-01-12 02:12Eric NOULARDStatusassigned => closed
2012-01-12 02:12Eric NOULARDResolutionreopened => fixed
2012-06-01 02:39Eric NOULARDRelationship addedrelated to 0013251

Notes
(0021345)
Eric NOULARD   
2010-07-09 19:02   
Assigning this to myself in order to check whether if
it's currently true since 2.8.2 switched to libarchive.
(0021478)
Eric NOULARD   
2010-07-26 07:07   
I can confirm the attached example is producing the same error
with current git master:
cmake version 2.8.2.20100726-gc4572

Unassigning the bug, I would rather let someone else with more knowledge
of libarchive to fix this one.

Theoretically symbolic may be stored in ZIP archive:

On command line (Linux case) one should use "zip -y"
if the "-y" option is not used then zip insert of copy of each
target of each link (you have no more link when you unzip).

It looks (from the libarchive source code) that libarchive
cannot currently handle files which are not "regular file or folder":

see:
http://code.google.com/p/libarchive/source/browse/trunk/libarchive/archive_write_set_format_zip.c [^] line 289.

or same file line 288 in libarchive source embedded with CMake.
(0021479)
Eric NOULARD   
2010-07-26 07:18   
Just file a bug to libarchive project:

http://code.google.com/p/libarchive/issues/detail?id=104&colspec=ID%20Type%20Status%20Priority%20Milestone%20OpSys%20Owner%20Summary [^]
(0028079)
Eric NOULARD   
2011-12-30 18:22   
The symlink handling in libarchive bug
http://code.google.com/p/libarchive/issues/detail?id=104 [^]
has been closed today.

It is in today's trunk and it seems to be in 3.0.2 release as well.
http://libarchive.googlecode.com/files/libarchive-3.0.2.tar.gz [^]

So I guess integrating this upstream version in next CMake release
may fix this bug may bring more features as well.

Current cmlibarchive seems to be
Apr 01, 2009: libarchive 2.6.990a released
Whereas
Dec 24, 2011: libarchive 3.0.2 released
(0028243)
Brad King   
2012-01-10 15:44   
We've merged a topic that updates libarchive to 3.0.2:

  http://cmake.org/gitweb?p=cmake.git;a=commit;h=5a5c32e1 [^]

Does this work as expected now?
(0028245)
Eric NOULARD   
2012-01-10 16:04   
Better but not quite...

cpack -G ZIP
CPack: Create package using ZIP
CPack: Install projects
CPack: - Run preinstall target for: CMZipSharedLib
CPack: - Install project: CMZipSharedLib
CPack: Create package
Erreur de segmentation


--> seems like we wrongly assumed that
   archive_error_string would not return NULL but this happen
in this case so
Source/cmArchiveWrite.cxx
 289 this->Error += archive_error_string(this->Archive);

leads to an error due to NULL passed as a constructor to
std::string().

I look into it in order to see why.
May be there is something to do in order to handle symlink in zip
from within libarchive.
(0028247)
Eric NOULARD   
2012-01-10 17:30   
I did push a proposal fix to
stage/fixSymlinkInZIP.

As you'll see for ZIP archive the size of the entry
is not reported as 0 whereas for TAR-based archive this
seems to be the case (at least in the tests I did).

Would you like to review it before I push to next?
I did not catch any regression for other archive generators.

Concerning the possible NULL value returned by
"archive_error_string" may be it would be safer
to wrap it into an helper method of ArchiveWrite
which would check & prevent the std::string(NULL) call
from happening.

It may be a bug to report upstream I don't really know.
(0028260)
Brad King   
2012-01-11 08:00   
The fix looks good except the indentation does not follow the normal style. Thanks!
(0028261)
Eric NOULARD   
2012-01-11 08:58   
Just merged to next with proper indentation style (I hope).

Merge topic 'fixSymlinkInZIP' into next

c43a18e Fix indentation style
53da978 Do not add the content of a file if it's a symlink.
(0028263)
Eric NOULARD   
2012-01-11 09:24   
Dashboard just goes red on TarTest
http://www.cdash.org/CDash/testSummary.php?project=1&name=TarTest&date=2012-01-11 [^]
(0028264)
Eric NOULARD   
2012-01-11 09:24   
Confirmed on my Linux box
(0028266)
Eric NOULARD   
2012-01-11 09:59   
Just pushed the fix to put TarTest back to normal.
Merge topic 'fixSymlinkInZIP' into next

c5f4bf5 Fix regression on TarTest

I do not understand something about this.
I'll leave the bug open until I fully understand why tar should copy
data content of a symlink whereas we should not do that for zip...

May be the zip file built using this is not valid either
I'll look into it tonight.
(0028270)
Eric NOULARD   
2012-01-11 16:47   
OK now I think I did it in an appropriate way for both zip and tar.

Merge topic 'fixSymlinkInZIP' into next
53fcb0b Fix wrong test for symlink.

Waiting for next dashboard run before setting this bug to resolved/closed again :-]
(0028273)
Eric NOULARD   
2012-01-12 02:12   
I bet this one is OK.

May be squashing the 4 commits:
53fcb0bc665038d947316bbf01fff38f5fd98fb3
c5f4bf565611be0f737e3331ce92f9473aff5585
c43a18e018f15e5cbb8dcddb8726ec76a5c8ace3
53da978b3cdab4eabc358f8fee0b0ee99ae8d3cf

which is basically equivalent to last one would bring a nicer merge