Hi David,
On Wed, Jan 30, 2008 at 01:14:13PM +0100, David Paleino wrote:
> This is due to the fact that in Makefile.am upstream (CCed) has set:
>
> libvista_la_LDFLAGS = -version-info 2:2:0
>
> As already discussed in the thread at [1], the numbers get reversed in the
> file name, so that 2:2:0
On 30/01/2008, David Paleino wrote:
> I'm packaging a software for the Debian-Med group (CCed), and found
> that, even if the library is at version 2.2.1, the compilation makes a
> libfoo.so.2.0.2 [1].
> Is there any solution to this? If not, is it that important that the
> filename has the same v
Il giorno Wed, 30 Jan 2008 13:38:42 +0100
Sebastian Harl <[EMAIL PROTECTED]> ha scritto:
> Hi David,
Hi Sebastian,
> On Wed, Jan 30, 2008 at 01:14:13PM +0100, David Paleino wrote:
>
> > Is there any solution to this? If not, is it that important that the
> > filename has the same version number
Hi *,
I'm packaging a software for the Debian-Med group (CCed), and found that, even
if the library is at version 2.2.1, the compilation makes a libfoo.so.2.0.2 [1].
This is due to the fact that in Makefile.am upstream (CCed) has set:
libvista_la_LDFLAGS = -version-info 2:2:0
As already discusse
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 patien
[I think you meant to sent this to -devel as well as just me
privately... I hope you don't mind me sending my response back to -devel]
[EMAIL PROTECTED] wrote:
> But is this possible ? If for instance I know that T will be double, int and a
> "custom" class, can I force the code for g, g and g to
On Thu, Jul 07, 2005 at 06:45:13PM +0200, [EMAIL PROTECTED] wrote:
> > 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 t
[EMAIL PROTECTED] wrote:
> g.h :
> template
> void g (T x);
>
> g.cc :
> template
> 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
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> 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...
The template class has to actually be included, and
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > 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.
You can't rea
> 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 cod
> 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
> 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 pr
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
> >>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... Eith
Alexis Papadopoulos wrote:
> 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 wa
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
* Alexis Papadopoulos ([EMAIL PROTECTED]) wrote:
> >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 ;).
If that one person isn't willing to deal with it then that
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 th
On Thu, Jul 07, 2005 at 10:54:15AM +0200, Alexis Papadopoulos wrote:
> 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
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
On Thu, Jul 07, 2005 at 10:13:20AM +0200, Alexis Papadopoulos wrote:
> 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.
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
22 matches
Mail list logo
