[cmake-developers] Welcome to June, time for the next release candidate

[Eric Noulard]

2012/6/5 Kornel Benko <kornel at lyx.org>:
> Am Dienstag, 5. Juni 2012 um 10:11:40, schrieb Eric Noulard
> <eric.noulard at gmail.com>
>
>> Hi Kornel,
>
>> Like I said in the previous thread, we simply cannot switch to gnutar, it
>> will potentially break many other systems.
>
> OK, I understood the hesitation.
>
>> Moreover when you compiled the very same CMake using the shipped-in
>> cmlibarchive you didn't get the error.
>
>> So the issue is an interaction between system provided libarchive and
>> CMake,
>
>> did try to contact Ubuntu packager about that?
>>

> You mean, I should press the ubuntu packager to use built-in libarchive,
> instead of using
> the the "approved" brand new libarchive version already there? What should I
> expect as an answer from them?

Nope.
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.

I'm not saying that should be you or the Ubuntu packager but I have no time
(now) to do that and since the packager knows his package better than me
I would kindly ask for his help.

> My opinion is: this libarchive will (sooner or later) find it's way to other
> platforms as well, and also in cmake's own sources.

The libarchive from Ubuntu may well be patched and/or compiled with conflicting
options which makes it incompatible with the CMake usage.

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.

Since it works with cmlibarchive my question was simple, could
the ubuntu package check why it's breaking in Ubuntu.


> We already reacted once (changing archive_write_set_format_ustar() to
> archive_write_set_format_pax_restricted()).

Yes but this action was widening the compatibility.
pax_restricted --> gnutar may be narrowing it.

> Never mind, I did not want to be importunate ...

You don't.
Personnally I like discussion, so no problem.
I do not pretend I'm right in this case either, but I'm clearly
lacking time to investigate the issue
and I'm glad you already seek & tests for understanding the issue.

However from my point of view is that we now know the symptom, but we
do not know the reason.
Why is it working with cmlibarchive and not with system libarchive.

I'm using Debian wheezy 64 bits, and  I do not have any problem when
using system libarchive:
ldd /home/erk/CMake/cmake-Verk-HEAD/bin/cmake
	linux-vdso.so.1 =>  (0x00007fff387ff000)
	libarchive.so.12 => /usr/lib/x86_64-linux-gnu/libarchive.so.12
(0x00007f7424a8d000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7424889000)
...
ldd /home/erk/CMake/cmake-Verk-HEAD/bin/cpack
	linux-vdso.so.1 =>  (0x00007fff79dff000)
	libarchive.so.12 => /usr/lib/x86_64-linux-gnu/libarchive.so.12
(0x00007fb676d4f000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb676b4b000)
...

So my question is, why is it happening on Ubuntu 12.04, and may be why is it NOT
happening on 11.10 or 11.04 ??

-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org