It's probably possible to convince libtool to generate libraries with an
incrementing minor version number, indicating a bug fix/maintenance
release that doesn't add significant new features or otherwise change
the ABI.

For instance, the next release could be 4.0.1 or 4.1.0. Which we get
depends on how libtool does things -- this is not fully under our
control. This is also the Linux-centric view; it can be different on
other platforms.

This will add some overhead to the effort of making each new release.
The question is, will it be valuable? One would have to have programs
that link against the full library version, not against libmysqlpp.so or
libmysqlpp.so.4, for this to be helpful. The idea would be that you can
install a new version of the library without making all your existing
binaries use the new version. Personally, I always want my binaries to
use the newest version, so this feature would be of no value to me.

Comments, questions, complaints?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

In another thread, Warren wrote:
I don't think this is the case. Class member functions just take a
this pointer, just like C functions would take a pointer to a struct.

Now, there is the case of going from a class with only non-virtual member
functoins to a class with virtual members. This increases the instance
size since a vtable is needed.

Changing the number of virtual functions may affect the vtable, but I'm
not familiar with the low level implementation of that. I wouldn't be
surprised if that affected the ABI as well.

But for plain old classes, I don't think C++ is much different from C
in regards to the ABI, as long as member functions are only added, not
removed or changed, and as long as the data members stayed the same.

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Fri, Mar 11, 2005 at 04:34:11PM -0700, Warren Young wrote:
I find it confusing that the major version of the library is 4, but
that's not really anything but a mental argument. It technically works
but doesn't tell the administrator anything useful.

I like how I can look at most libraries and tell what version it is just
by the filename.

Multiple versions at once is an administration feature, and would make
a lot of sense when 1.8, 1.9, etc are released so that stable and dev
versions could be run at the same time.

Two different stable installs would also be useful, from a release
point of view (i.e. from Debian/RedHat/Gentoo/etc's point of view):
1.7 and 1.9 could support different legacy apps that require different
stable versions.

So I would recommend that the major part of the version would be
taken from the official version number, using both initial digits.
i.e. "1.7" is the major version, from the library file's perspective.
It's all just symlinks anyway:

libmysqlpp.so -> libmysqlpp.so.1.7
libmysqlpp.so.1.7 -> libmysqlpp.so.1.7.23
libmysqlpp.so.1.7.23

Stable releases would have no ABI breakage, and dev versions would
break the ABI at will. We might have more version churn at this rate,
but with a double digit "major" I don't think this would be a problem.

1.7 - stable, major version, no more ABI breakage
- additional versions would be bugfixes
1.7.21, 1.7.23, etc
1.8 - another major version, perhaps a dev tree
1.9 - the next stable

Perhaps a jump in version to an even number for the next stable release
would make things look more like the kernel. :-)

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:

There's precedent. The MySQL C API library I use is version 12, for
instance.

Under RPM, you can say 'rpm -qf /usr/lib/libmysqlpp.so.4' and get
'mysql++-1.7.31' back. Other package systems I've used have a way to
ask what package owns a particular file, too.

I'm uncomfortable going backwards in version numbers at this point. If
versions 4 and 1.8 are installed, g++ will try to link against version 4
when building the binary.

In any case, I'm not really asking about having both 1.8 vs. 1.9
libraries installed. Presumably there's an ABI change between those
two, so under the current scheme they'd get different library names, so
you could still install the new one without needing to relink old binaries.

Ignoring the v4 vs. v1.x issue, what I'm really asking is, is there any
point in having both libmysqlpp.so.1.7.31 and libmysqlpp.so.1.7.32
installed? That's the situation that causes overhead for each release,
and which has no value unless you make the effort to link against a
specific point release. I can make libtool use these version numbers,
but unless a program is linked specifically to one point release,
there's little point in making the effort.

Yes, but those symlinks are maintained by ldconfig on a Linux system. I
have no control over them. I could make my own symlinks, but then I'm
fighting the system.

....except that they just abandoned the whole even/odd thing.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:

You're right, of course. I had conflated this issue with member
_variables_, because this topic came up when I wanted to add exception
disabling to Connection. So while true, it doesn't actually help with
the matter at hand.

The other proposal for fixing this, which would involve deriving
Connection from another class, should also break the ABI. So we're back
to discussing a new library version in which we can batch these sort of
changes.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Tue, Mar 15, 2005 at 02:40:25PM -0700, Warren Young wrote:
Ok, that explains why this scheme was chosen.


I knew that, but I still like the libraries themselves to have that info.
An entire package management system shouldn't be required for such
basic info. :-)


g++ has no logic in it for version numbers. It doesn't know the
difference between 4 and 1.8. It looks at the libmysqlpp.so link,
and uses whatever that points to.

So the administrator or package system chooses which lib is used for
development (and the package management system (RPM, etc) should "know"
which version number is newer and set it appropriately).

As a test, to make sure I still understood this correctly :-) I deleted
my /usr/lib/libmysqlpp.so link, and reran ldconfig. The link was not
recreated, which indicates that it is governed by the installation,
and/or the administrator. And really, only the admin/package system knows
where this link should point.

ldconfig did know how to rebuild libmysqlpp.so.4 to make it point to
libmysqlpp.4.0.0, so perhaps my "1.8" idea needs some more thought,
but g++ is not a reason in itself to avoid moving from 4 to 1.8.


After reading part of the shared library howto, I withdraw my
"1.8" suggestion, since it seems it would break conventions. ldconfig
doesn't know how to deal with it automatically, so we'd have to do it
manually.


Different name, as in "libmysqlpp-dev"? Or did you mean a new number, like 5?


I don't think there's any need for it in the current stable release, but
I think now (the next dev cycle) is the time to do it before lib numbers
rise any higher and pollute possible namespace.

The '4' looks hideous to me, since it conveys no meaning, but the
practicalities of shared library management are conspiring against me,
and it does make sense from the ABI viewpoint.

Conventions indicate that the version numbers stand for:
<ABI version>.<minor version>.<release count>

That gives:
libmysqlpp.so -> libmysqlpp.so.1
libmysqlpp.so.1 -> libmysqlpp.so.1.7.32
libmysqlpp.so.1.7.32

Or:
libmysqlpp1.so -> libmysqlpp1.so.7
libmysqlpp1.so.7 -> libmysqlpp1.so.7.32
libmysqlpp1.so.7.32

Or:
libmysqlpp.so -> libmysqlpp.so.4
libmysqlpp.so.4 -> libmysqlpp.4.0.0
libmysqlpp.so.4.0.0

Note #1:
If the '1' in 1.7.32 represented the stable ABI, this would make
a lot of sense for library versioning. It would put a significant
freeze on what changes are allowed in stable releases though.


I like option #1 or #2.

This gives developers and admins full flexibility in the number and variety
of mysql++ versions on a system, and would hopefully reduce the number of
segfaults and library problems people have. (doubtful, but I hope)

Plus, it provides a clear upgrade versioning path. With '4', I don't know
what comes next for the dev cycle. 5? 6? Are ABI changes allowed in
the stable release? If so, does it become 5 if dev is already using it?


As shown above, ldconfig only updates the soname (*.so.#). The dev
links (*.so) are controlled by the install process (which in mysql++'s case,
it's controlled by the Makefiles). There could be special logic in the
RPM to handle arbitration if needed.


As you can tell, I like logical version numbers! :-) It's a sad situation
in kernel land.

Thanks for the patience in reading all this,
- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

I and trying to use the structure creation macros and get many(10 or so)
multiple definition errors when linking all reference the EOSUserData I'm
tryin to create.

This is the file it's created in, I'm use I don't use the name EOSUserData
name anywhere else.


#ifndef EOS_PLAYER_H
#define EOS_PLAYER_H 1

#include <string>
#include <mysql++.h>
#include <custom.h>

using namespace std;
using namespace mysqlpp;

sql_create_9(EOSUserData,
1, 9,
longlong, user_id,
string, user_name,
string, user_family_name,
string, user_firstname,
string, user_lastname,
string, password,
string, email,
string, ipaddress,
DateTime, signupdate)


class EOSPlayer{
public:

EOSPlayer(char *un, char *pass);
~EOSPlayer();

. . .
private:

EOSUserData databaseData;
EOSUserData currentData;

. . .

};

#endif


Any help would be great... Thanks

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Ignore this I'll resend with a new title, was replying just to get the email
address and didn't change the subject.
-Chris

-----Original Message-----
From: Chris Gagnon [mailto:chris-gagnon (AT) rogers (DOT) com]
Sent: Saturday, March 19, 2005 6:08 PM
To: 'plusplus (AT) lists (DOT) mysql.com'
Subject: RE: libmysqlpp.so minor version numbers?

I and trying to use the structure creation macros and get many(10 or so)
multiple definition errors when linking all reference the EOSUserData I'm
tryin to create.

This is the file it's created in, I'm use I don't use the name EOSUserData
name anywhere else.


#ifndef EOS_PLAYER_H
#define EOS_PLAYER_H 1

#include <string>
#include <mysql++.h>
#include <custom.h>

using namespace std;
using namespace mysqlpp;

sql_create_9(EOSUserData,
1, 9,
longlong, user_id,
string, user_name,
string, user_family_name,
string, user_firstname,
string, user_lastname,
string, password,
string, email,
string, ipaddress,
DateTime, signupdate)


class EOSPlayer{
public:

EOSPlayer(char *un, char *pass);
~EOSPlayer();

. . .
private:

EOSUserData databaseData;
EOSUserData currentData;

. . .

};

#endif


Any help would be great... Thanks


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.4 - Release Date: 3/18/2005



--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw