Andreas Tille wrote:
On Mon, 12 Sep 2005, bear wrote:
dh_shlibdeps -a
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkzlib.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg8.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg12.so not recognized
dpkg-shlibdeps: warning: format of libitkjpeg16.so not recognized
...
Do you have any idea what's the problem with these libraries?
Sorry. I do now know the cause of this problem.
My guess is that something in the build process just went not the way it
should. Moreover I suspect that cmake just does a bad job compared to
the autoconf / automake / libtool combination. I have no idea about
cmake
and do not know the reasons why it is prefered but I would like you to
ask on debian-devel for help in this case.
This toolkit chooses cmake mainly because it is portable to M$ Windows.
Currently the
building process can be controlled by cmake. I will ask this problem of
these warnings on debian-devel.
This should be no final reason not to upload the package but it just
should be solved for the future.
I move the examples to /usr/share/doc/insighttoolkit2-examples/examples
OK.
I wonder why a dev package is architecture all. Normally it
contains
headers *and* static libraries but obviousely there are no
static libraries
builded at all.
Yes. There is no static libraries when choosing to build shared
library in cmake.
Hmmm, you probably should have to separate build processes when building
the package: one which builds dynamic .so libraries for the runtime
package
and another one for building the static *.a libraries. Also in this case
libtool comes into mind which does this perfectly fine.
I think .a libraries are not necessary. Because .so libraries can be
used in the development
of applications based on this toolkit. Besides, a similar package vtk in
debian do the same thing.
libinsighttoolkit2:
I have no idea about cmake but it is really necessary to move
/usr/lib/InsightToolkit/*.cmake
files into the binary package?
All .cmake files now is packaged in libinsighttoolkit2-dev
I guess they are used if you want to build something against the
toolkit, right?
Yes. They helps the cmake to do further configuration to ITK.
Kind regards
Andreas.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
