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.
17 matches
Mail list logo
