Re: Shared library versioning
Hi, I'm not having elements to reply immediatly and therefore won't be able to respond right away. I'm going to take a look at the code and recontact the upstream author in order to have a more precise idea of the exact problem, since I missed some things apparently... Thanks for your patience Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Shared library versioning
Hello, I'm actually making some .deb packages out of a single source archive. One of them should contain a shared library. The upstream author's package's version is 5.13 and the soname of his library has been set to 513. After having contacted him, he told me that was done because apparently each time the new version of the library became uncompatible with the previous ones, the major version should be incremented, something that was disturbing because the library is often subject to modifications leading to incompatibilities. After having searched around on the internet I didn't find any information on this, but I read once again the SONAME chapter of the debian library packaging manual and didn't see this method of versioning mentioned. What I understood so far is that when upgrading a shared library the old version is left around and only the link libname.so is updated. What happens now if I update this shared library without recompiling the software that was linked agains the old version ? Thanks in advance for your comments Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
Thanks for that one, the thing is that the upstream author is using libtool which has a somehow special versioning method. Apparently when the library's interface changes in a way backwards-compatibility is broken, the major (what they call current) version must be incremented. I will have to discuss this with him because it means that some changes have to made. But isn't this versioning issue a headache ? I mean, if your sources compile a library and some binaries linked against it, you have to maintain 2 version informations : the sources' version and the library's one. Up until now the upstream author simply used a VERSION file that was incremented automagically before CVS commit. Now he must to keep a second version info for the library that he must supervise manually in case of backwards-incompatibility... Anyway, I will have to see with him in order to find a solution because I think that having a (in libtool's vocabulary) current version of 513 isn't really acceptable... Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
It's a single headache for the one library developer/packager, as opposed to headaches for _every user_ of the library. Yes indeed, but it's still a headache for one person ;). You might want to have a look at the debian-mentors archives, too. I believe this sort of thing gets discussed there on occasion, in more detail that I've done. I will take a look into debian-mentors, but I've just talked to the upstream author and can now explain the reason of his choice. The thing is that the library is written in C++ and makes heavily use of templates which means that even a small change in the code, that doesn't change the ABI, might lead to incompatibility. We therefore checked the existant libraries coded in C++, using templates and present in the debian distribution. We only used two examples, libginac and libboost-python. We looked both of the shared libraries present : libginac-1.3.so.0.0.0 with SONAME libginac-1.3.so.0 : the version is contained in the SONAME which means that if a program is linked against libginac-1.3 and only libginac-1.4 is present on the system, it will fail. Same goes for libboost-python : libboost_python-gcc-mt-1_32.so.1.32.0 with SONAME libboost_python-gcc-mt-1_32.so.1.32.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
If that one person isn't willing to deal with it then that person shouldn't be writing libraries. :) Never said that... I will take a look into debian-mentors, but I've just talked to the upstream author and can now explain the reason of his choice. Unfortunately that doesn't make his reasoning right. :) Nor that. I merely meant that I understood why he chose this kind of SONAME. The thing is that the library is written in C++ and makes heavily use of templates which means that even a small change in the code, that doesn't change the ABI, might lead to incompatibility. There's no 'might' about it... Either it changes the ABI or it doesn't. ABI does mean more than just symbols though and so, yes, you do have to be careful and realize when you make an ABI change. The thing is that every change in a template class or function in the shared library will lead to an ABI change (except some rare cases). Since the majority of the modifications are made in this section of the library I don't find absurd to modify the SONAME on each new compilation of the library (only of course if modification has been made since last compilation). This goal of all this is to make the update of SONAME as far as I can automatically. The idea now is to keep two records, one with the sources version and one with the current soname. On each modification (and CVS commit) of the sources, if changes have been made to the library's source files, SONAME is increased, sources version is always incremented. The SONAME will be (as inspired from libginac) in the following form : lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage) or maybe lib*.so.XY (format that is used today by the upstream author) Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
Is this shared library actually used by other programs? Or only within the internal use of this particular project? If the latter then I would avoid packaging it as a shared library at all. If the shared library is not used by other programs then I would covert the build to link the project library code as an archive library for Debian. That should avoid most of the problems. Well the goal is to make it available to other programs, so a shared library is preferable. A -dev package will be available too to allow users to compile binaries and link them against the .so library... - envoyé via Webmail/IMAG ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
That's almost certainly a terrible idea.
I somehow expected that might come up. I didn't fell to comfortable with this
idea, but I think there must be another solution than simply doing it by hand,
a more elegant way.
The SONAME needs to match across distributions so it really needs to be
managed (and managed correctly) by upstream.
I have access to upstream's CVS so if any modification is to be made, it will
concern the whole project not only the debianization of it.
If every change to the
library requires an SONAME change then it almost certainly should not
*be* a library. It would be rather disappointing if what you're saying
about C++ template classes is really accurate. Personally, I suspect
it's not.
That's what the upstream author explained me, and that's what I want to find
out. Two possibilities, either the upstream author has missed something, or
there is a proper way of dealing with this kind of situation.
One example that might fail :
let's say we have a shared library with 2 source files : g.cc and g.h
g.h :
template class T
void g (T x);
g.cc :
template class T
void g (T x) {
cout x;
}
The .h file has to include the .cc one in order for the compilation to work.
That leads to a shared library that we'll call libg.so.1.0.0
Let's say now that I compile a program `prgm` and link it against the above
library.
Now if I decide to change one line of g.cc :
cout x;
becomes
cout x endl;
and if I don't change the SONAME (the ABI hasn't changed, there doesn't seem to
be a reason to increment the SONAME), and call `prgm`, I want the the newline on
the output, because the code of g isn't in the .so library but in prgm itself.
According to the upstream author, since the template (class T) isn't known, we
cannot insert the code of g into the library (which seems normal).
My programming skills are limited, therefore I'm doing my best to explain
myself, hope it was clear enough...
Alexis Papadopoulos
-
envoyé via Webmail/IMAG !
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shared library versioning
That is just plain wrong. :-) With templates, you are supposed to provide the template implementation either in the header or in a file included by the header (convention is to name them .tcc and place them next to the header). The usual rule applies: Everything that does not generate code by itself should be in a header file. Well I did say that : The .h file has to include the .cc one in order for the compilation to work. Now if you decide to leave the code that I put into g.cc only the .h file, it works too... Yes, so the ABI doesn't change in this case. It doesn't, and the modification isn't very important so it isn't a problem. But that was only an example, but the body of g can be modified in a way where it could lead to a failure (because of the use of templates), therefore the SONAME muste be changed so as to force usage of the new library. Alexis Papadopoulos - envoyé via Webmail/IMAG ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hello,
I unfortunately deleted all my control files in an attempt to make a
fresh start, but created a very simple debian/rules so as to test if
the --enable-fast-install solved my problem, here it is :
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of
dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
CFLAGS = -Wall -g
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
CFLAGS += -O2
endif
configure: configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.
./configure --enable-fast-install --prefix=/usr
--mandir=/usr/share/man
touch configure-stamp
build: build-stamp
build-stamp: configure-stamp
dh_testdir
# Add here commands to compile the package.
$(MAKE)
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
-$(MAKE) clean
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/rheolef.
$(MAKE) install DESTDIR=$(CURDIR)/debian/rheolef
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
dh_installman
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
DESTDIR is set correctly for the make install, and so is prefix during
configuration. What makes me think it isn't related to that is the fact
that after compilation, the binaries in .libs directories are already
linked to my shared library, but not to /usr/lib/librheolef.so.513 as
they should be (I checked with flac package, after compilation the flac
binary is linked to a shared library that should be located under /usr/lib).
What I'll try now to convince myself (I hope I'm right) that it was only
a matter of --enable-fast-install, I'll try to disable it and compile
flac (because for this package it is enabled by default, not for
rheolef). If it fails, I'm done with this, if it works I'll have to dig
a little bit further maybe.
Now, the problem I want to resolve is the following one. The upstream
author has included in his sources the config.{guess,sub} files, which I
remove and replace by links to the /usr/share/libtool/config.{guess,sub}
ones). This works fine. But he also gives a ltmain.sh file, and the
libltdl directory which are also to be found into /usr/share/libtool/.
Do I have to replace them too ? If I try (by hand or by using
libtoolize), after configuration I'm getting a non-working libtool, as I
explained in my previous message. Not touching ltmain.sh seems to work,
but I don't want this to be a temporary solution, I want to be sure that
I can let it as it is, or if I have to fix something.
could I have a look at your debian/rules file?
perhaps you are changing prefix instead of DESTDIR when running
the install target?
Are you using CDBS? It should handle autotool packages quite well
out of the box.
No, actually I only use debhelper, but apparently (having read the docs)
it should handle autotools correctly too. I'll give a try to CDBS also
to see.
Thanks for helping Martin :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hello again, I changed the debian/rules of the flac source package, adding a --disable-fast-install at the parameters passed to the configure script and it fails! Well, fails, it doesn't link the libraries as expected. So that's good news, I found the solution to my first problem. The weird thing though is that I found no info whatsoever on the internet, nobody seems to mention that this is something that we should check. Anyway, I'm now going to try to get rid of the other problem, the ltmain.sh issue that is. If someone has some info on this, do respond... Thanks in advance -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
Hi there, I'm finally on the working computer. After having tried to build the .dev package again, here is the missing info. The command used for compiling 'geo' (one of the binaries that must be linked to librheolef.so (the shared library)) is the following one : /bin/sh ../../libtool --mode=link i386-linux-g++ -O2 -ansi -Wall -Wno-unused -o geo xgeo.o ../lib/librheolef.la i386-linux-g++ -O2 -ansi -Wall -Wno-unused -o .libs/geo xgeo.o ../lib/.libs/librheolef.so -L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/gcc-lib/i486-linux/3.3.5/../../.. -ldl -lstdc++ -lm -lc -lgcc_s -Wl,--rpath -Wl,/here/is/the/top/build/dir/nfem/lib/.libs creating geo When the binary is to be installed, here's the error message I receive : /bin/sh ../../libtool --mode=install /bin/sh ../../config/install-sh -c 'geo' '/here/is/the/top/build/dir/debian/rheolef/usr/bin/geo' /bin/sh ../../config/install-sh -c geo /here/is/the/top/build/dir/debian/rheolef/usr/bin/geo libtool: install: warning: cannot relink `geo' libtool: install: warning: `../lib/librheolef.la' has not been installed in `/usr/lib' Now the funny thing is that if I copy the command above (used to install the binary) and execute it by myself, it works (well almost, I at least get a binary file in debian/rheolef/usr/bin/, but it's still linked to /here/is/the/top/build/dir/nfem/libs/.libs/librheolef.so.513). I downloaded flac source package since it was quite similar to what I'm trying to do, that is an executable depending on a shared library not yet installed, and all of that from the same sources. The main difference I found was the --rpath missing option in the compilation of flac executable. I tried to find a way to remove it but with no luck, I could only append a second --rpath to the end of the command, which was of course ignored. I'm not quite sure what to do now, I'll try to use flac sources to find a way out... Thanks for helping... Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
While looking for a solution I realized that it had something to do with the libtool that was generated in the top_builddir. If I used /usr/bin/libtool the -rpath was correct. So with some help from `diff` I found out what seemed to be a cause, enable-fast-install must be enabled. I'm trying now to recompile the whole thing with taking care to pass --enable-fast-install to ./configure. The funny thing is that now the generated libtool script simply fails. If I change the first line though, which defines the variable Xsed=`sed -e ` to Xsed=`/bin/sed -e ` it seems to work. I have no clue why I get this error, I thought it was because of my PATH variable (even though the error isn't `sed command or file not found`, but wno knows), but /bin is there. I really don't understand what is going on. Anyway, I'll spend another couple of days looking for that (unless someone helps ;) ), but at least it will be done... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libtool and packaging
this should all just work. Well it almost does. The problem is that in tmp/installation/dir/usr/bin (actually it's top_builddir/debian/rheolef/usr/bin) I only get the wrapper scripts created by libtool, and not the executables linked to the library. I don't have now access to the computer on which I'm working therefore I cannot copy the exact error message I'm receiving (because there is one, something goes wrong with libtool when the binaries are installed into debian/rheolef/usr/bin) but the thing is that when I go and check in the source directories, and look into the .libs, the binaries there are linked to my shared library at debian/usr/lib/lib*.so and not /usr/lib/lib*.so). So something goes wrong before... if you provide a pointer to the source package in question we can have a look at the problem. The upstream's author sources are available at : https://gna.org/projects/rheolef I will give you a link with the control files I'm using by tomorrow. Thanks for helping me out. Alexis Papadopoulos - envoyé via Webmail/IMAG ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Libtool and packaging
Hello, I'm actually trying to create a .deb package from sources using automake, autoconf and libtool. The resulting files consist of some shell scripts, a shared library and some binaries that must be linked to it. I'm having the following problem : the binaries are temporarily linked with lib*.la and put into the .libs directories. When 'make install' is called from debian/rules though, the final linking with the lib*.so shared library fails because it cannot be found. The upstream author first installed it in /usr/lib, and then made the libtool calls. I know that I can inform libtool of the location of the lib*.so library, but the problem is that given the fact that I'm installing in a temporary location (debian/mypackage/), the linking will be made against debian/mypackage/usr/lib/lib*.so. What I want to do, is to link against /usr/lib/lib*.so even though it is not there yet. How can that be accomplished ? I downloaded the flac source, since it used the autotools and libtool, while building binaries and shared libraries. They seem to use libtool's relink mode with -rpath. Problem is that I'm not familiar with libtool, and would like to know if it's possible to avoid this method, by using 'libtool install' and just forcing it to link against /usr/lib/lib*.so Hope I was clear enough, thanks in advance Alexis Papadopoulos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
