Menu
▾
▴
libdbi-devel — Discussion about development of the core library and DBD interface
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
(10) |
Sep
|
Oct
(5) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(28) |
Feb
(3) |
Mar
(3) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
| 2005 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
(13) |
Jun
(2) |
Jul
(23) |
Aug
(10) |
Sep
(31) |
Oct
(1) |
Nov
(6) |
Dec
(11) |
| 2006 |
Jan
(6) |
Feb
(5) |
Mar
(19) |
Apr
(29) |
May
(63) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(3) |
Dec
|
| 2007 |
Jan
|
Feb
(16) |
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
|
Jul
(6) |
Aug
(18) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(4) |
Feb
(8) |
Mar
|
Apr
(3) |
May
|
Jun
(9) |
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(11) |
Nov
(30) |
Dec
(2) |
| 2009 |
Jan
(1) |
Feb
|
Mar
(25) |
Apr
|
May
(9) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(24) |
Nov
(9) |
Dec
(2) |
| 2010 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
(22) |
Oct
|
Nov
|
Dec
(1) |
| 2011 |
Jan
(10) |
Feb
(17) |
Mar
(4) |
Apr
(9) |
May
(1) |
Jun
|
Jul
(7) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(13) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(17) |
Dec
|
| 2014 |
Jan
(16) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Markus H. <mar...@mh...> - 2009-10-13 21:55:38
|
Markus Hoenicka writes: > mimo writes: > I've tried to reproduce this problem on my FreeBSD box, to no avail > yet. First of all, being a C programmer I failed to compile your test > successfully. Could you please post the magic gcc incantation which > will compile the program? Second, FreeBSD 7.2 seems to have problems > unloading the drivers while runing under gdb. I needed to check the > program in gdb as valgrind would cause the program to dump core. In > any case, even switching off the code which would unload the driver > when shutting down the library wouldn't make valgrind happy. A quick > search on the web confirmed that valgrind is not fully operational on > FreeBSD currently. I'll try again tomorrow on a Debian box. > FreeBSD now has an updated valgrind which seems to work ok. I've managed to reproduce the problem reported by mimo. I'm using the current cvs revisions of both libdbi and libdbi-drivers, so there may be some (unintentional) improvements regarding this issue. The mysql driver causes some memory to be lost: ==3850== LEAK SUMMARY: ==3850== definitely lost: 16 bytes in 1 blocks ==3850== indirectly lost: 0 bytes in 0 blocks ==3850== possibly lost: 32,704 bytes in 8 blocks ==3850== still reachable: 3,942 bytes in 12 blocks ==3850== suppressed: 0 bytes in 0 blocks The same does not happen with sqlite3: ==3842== LEAK SUMMARY: ==3842== definitely lost: 0 bytes in 0 blocks ==3842== indirectly lost: 0 bytes in 0 blocks ==3842== possibly lost: 0 bytes in 0 blocks ==3842== still reachable: 652 bytes in 7 blocks ==3842== suppressed: 0 bytes in 0 blocks so I assumed this is a driver problem. I went back to the driver sources and to the MySQL manual. Actually the driver did not call a cleanup function after terminating the connection. Calling mysql_server_end() is recommended to free any remaining memory. After adding this call to an appropriate function of the mysql driver, I wind up losing no memory: ==4240== LEAK SUMMARY: ==4240== definitely lost: 0 bytes in 0 blocks ==4240== indirectly lost: 0 bytes in 0 blocks ==4240== possibly lost: 0 bytes in 0 blocks ==4240== still reachable: 3,942 bytes in 12 blocks ==4240== suppressed: 0 bytes in 0 blocks If you have a chance to test the current sources on your platform, please let me know if your leaks are cured as well. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Markus H. <mar...@mh...> - 2009-10-12 22:28:21
|
mimo writes:
> closes a mysql connection - see below. Running this through valgrind's memory
> checker gives a leak report for dbi_conn_connect (output attached further
> down).
I've tried to reproduce this problem on my FreeBSD box, to no avail
yet. First of all, being a C programmer I failed to compile your test
successfully. Could you please post the magic gcc incantation which
will compile the program? Second, FreeBSD 7.2 seems to have problems
unloading the drivers while runing under gdb. I needed to check the
program in gdb as valgrind would cause the program to dump core. In
any case, even switching off the code which would unload the driver
when shutting down the library wouldn't make valgrind happy. A quick
search on the web confirmed that valgrind is not fully operational on
FreeBSD currently. I'll try again tomorrow on a Debian box.
> Any help would be greatly appreciated - btw my server (using 0.8.2) is multi-
> threaded - I've seen previous posts here about libdbi and thread safety - and
> I can confirm it's working fine if you take a couple of precautions. Let me know
> if you want more detailed instructions..
>
Yes, please.
regards,
Markus
> Thanks,
>
> mimo
>
> <code>
> #include <stdio.h>
> #include <stdlib.h>
> #include <mysql/mysql.h>
> #include <string>
> #include <iostream>
> #include <dbi/dbi.h>
>
> using namespace std;
>
> int main() {
> dbi_initialize(0);
> dbi_conn con = dbi_conn_new("mysql");
> dbi_conn_set_option(con, "username", "root");
> dbi_conn_set_option(con, "dbname", "greylist");
> if (dbi_conn_connect(con) != 0) {
> cerr << "dbi_conn_connect() failed" << endl;
> }
>
> dbi_conn_close(con);
> dbi_shutdown();
> return 0;
> }
> </code>
>
> valgrind --leak-check=full --show-reachable=yes --track-origins=yes
> ./dbi_mysql
>
> ==6633== Memcheck, a memory error detector.
> ==6633== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
> ==6633== Using LibVEX rev 1884, a library for dynamic binary translation.
> ==6633== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> ==6633== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
> framework.
> ==6633== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
> ==6633== For more details, rerun with: -v
> ==6633==
> ==6633==
> ==6633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2)
> ==6633== malloc/free: in use at exit: 61,376 bytes in 17 blocks.
> ==6633== malloc/free: 110 allocs, 93 frees, 122,903 bytes allocated.
> ==6633== For counts of detected errors, rerun with: -v
> ==6633== searching for pointers to 17 not-freed blocks.
> ==6633== checked 204,304 bytes.
> ==6633==
> ==6633== 24 bytes in 1 blocks are definitely lost in loss record 1 of 4
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> ==6633== by 0x65F2B51: ???
> ==6633== by 0x65F387A: ???
> ==6633== by 0x65F1049: ???
> ==6633== by 0x661810E: ???
> ==6633== by 0x639B3B9: ???
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
> ==6633==
> ==6633==
> ==6633== 32 bytes in 1 blocks are still reachable in loss record 2 of 4
> ==6633== at 0x4C25684: calloc (vg_replace_malloc.c:397)
> ==6633== by 0x5D9433F: _dlerror_run (dlerror.c:142)
> ==6633== by 0x5D93EC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
> ==6633== by 0x4E31C08: dbi_initialize (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400D9F: main (dbi_mysql.cpp:13)
> ==6633==
> ==6633==
> ==6633== 61,320 (4,088 direct, 57,232 indirect) bytes in 1 blocks are
> definitely lost in loss record 3 of 4
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> ==6633== by 0x65F9B85: ???
> ==6633== by 0x65FA26F: ???
> ==6633== by 0x65FAC64: ???
> ==6633== by 0x65FAE56: ???
> ==6633== by 0x6617ED9: ???
> ==6633== by 0x6619E57: ???
> ==6633== by 0x639B3EE: ???
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
> ==6633==
> ==6633==
> ==6633== 57,232 bytes in 14 blocks are indirectly lost in loss record 4 of 4
> ==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
> ==6633== by 0x65F9B85: ???
> ==6633== by 0x65FA28B: ???
> ==6633== by 0x65FAC64: ???
> ==6633== by 0x65FAE56: ???
> ==6633== by 0x6617ED9: ???
> ==6633== by 0x6619E57: ???
> ==6633== by 0x639B3EE: ???
> ==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
> ==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
> ==6633==
> ==6633== LEAK SUMMARY:
> ==6633== definitely lost: 4,112 bytes in 2 blocks.
> ==6633== indirectly lost: 57,232 bytes in 14 blocks.
> ==6633== possibly lost: 0 bytes in 0 blocks.
> ==6633== still reachable: 32 bytes in 1 blocks.
> ==6633== suppressed: 0 bytes in 0 blocks.
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> libdbi-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-devel
--
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38
|
|
From: mimo <mi...@re...> - 2009-10-11 18:39:15
|
I have been using libdbi for a long time now. Thanks for the great work to
everyone.
In a new server I'm working on I have noticed memory leaks and I think it's
down to libdbi or the mysql driver. I've written a simple test that opens and
closes a mysql connection - see below. Running this through valgrind's memory
checker gives a leak report for dbi_conn_connect (output attached further
down).
Any help would be greatly appreciated - btw my server (using 0.8.2) is multi-
threaded - I've seen previous posts here about libdbi and thread safety - and
I can confirm it's working fine if you take a couple of precautions. Let me know
if you want more detailed instructions..
Thanks,
mimo
<code>
#include <stdio.h>
#include <stdlib.h>
#include <mysql/mysql.h>
#include <string>
#include <iostream>
#include <dbi/dbi.h>
using namespace std;
int main() {
dbi_initialize(0);
dbi_conn con = dbi_conn_new("mysql");
dbi_conn_set_option(con, "username", "root");
dbi_conn_set_option(con, "dbname", "greylist");
if (dbi_conn_connect(con) != 0) {
cerr << "dbi_conn_connect() failed" << endl;
}
dbi_conn_close(con);
dbi_shutdown();
return 0;
}
</code>
valgrind --leak-check=full --show-reachable=yes --track-origins=yes
./dbi_mysql
==6633== Memcheck, a memory error detector.
==6633== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al.
==6633== Using LibVEX rev 1884, a library for dynamic binary translation.
==6633== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==6633== Using valgrind-3.4.1-Debian, a dynamic binary instrumentation
framework.
==6633== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==6633== For more details, rerun with: -v
==6633==
==6633==
==6633== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2)
==6633== malloc/free: in use at exit: 61,376 bytes in 17 blocks.
==6633== malloc/free: 110 allocs, 93 frees, 122,903 bytes allocated.
==6633== For counts of detected errors, rerun with: -v
==6633== searching for pointers to 17 not-freed blocks.
==6633== checked 204,304 bytes.
==6633==
==6633== 24 bytes in 1 blocks are definitely lost in loss record 1 of 4
==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==6633== by 0x65F2B51: ???
==6633== by 0x65F387A: ???
==6633== by 0x65F1049: ???
==6633== by 0x661810E: ???
==6633== by 0x639B3B9: ???
==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
==6633==
==6633==
==6633== 32 bytes in 1 blocks are still reachable in loss record 2 of 4
==6633== at 0x4C25684: calloc (vg_replace_malloc.c:397)
==6633== by 0x5D9433F: _dlerror_run (dlerror.c:142)
==6633== by 0x5D93EC0: dlopen@@GLIBC_2.2.5 (dlopen.c:88)
==6633== by 0x4E31C08: dbi_initialize (in /usr/lib/libdbi.so.0.0.5)
==6633== by 0x400D9F: main (dbi_mysql.cpp:13)
==6633==
==6633==
==6633== 61,320 (4,088 direct, 57,232 indirect) bytes in 1 blocks are
definitely lost in loss record 3 of 4
==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==6633== by 0x65F9B85: ???
==6633== by 0x65FA26F: ???
==6633== by 0x65FAC64: ???
==6633== by 0x65FAE56: ???
==6633== by 0x6617ED9: ???
==6633== by 0x6619E57: ???
==6633== by 0x639B3EE: ???
==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
==6633==
==6633==
==6633== 57,232 bytes in 14 blocks are indirectly lost in loss record 4 of 4
==6633== at 0x4C278AE: malloc (vg_replace_malloc.c:207)
==6633== by 0x65F9B85: ???
==6633== by 0x65FA28B: ???
==6633== by 0x65FAC64: ???
==6633== by 0x65FAE56: ???
==6633== by 0x6617ED9: ???
==6633== by 0x6619E57: ???
==6633== by 0x639B3EE: ???
==6633== by 0x4E30AF4: dbi_conn_connect (in /usr/lib/libdbi.so.0.0.5)
==6633== by 0x400DDC: main (dbi_mysql.cpp:17)
==6633==
==6633== LEAK SUMMARY:
==6633== definitely lost: 4,112 bytes in 2 blocks.
==6633== indirectly lost: 57,232 bytes in 14 blocks.
==6633== possibly lost: 0 bytes in 0 blocks.
==6633== still reachable: 32 bytes in 1 blocks.
==6633== suppressed: 0 bytes in 0 blocks.
|
|
From: Markus H. <mar...@mh...> - 2009-09-13 22:26:54
|
Phil Longstaff writes: > Is there any release timetable for a new release? 0.8.3 is now about 1 1/2 > years old (Feb 2008) and there are lots of bug fixes in svn. > There is no timetable at this time, but I think we all feel the pressure due to the large number of bugfixes and improvements which should eventually be released. There are two major issues which I'd like to see finished and fixed, respectively. The first one is the new test suite provided by João. Most things work ok, but he's still struggling with the firebird tests at the moment. The second issue is the firebird driver itself which still shows a couple of problems on various platforms. I've done my best to look into this, but I'm at a loss as all tests were ok in 0.8.3, as far as I recall. I'd appreciate if someone with thorough firebird knowledge could have a look at this. Taken together, there is no date but I'd release 0.9 rather sooner than later. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
|
From: Phil L. <plo...@ro...> - 2009-09-13 21:30:08
|
Is there any release timetable for a new release? 0.8.3 is now about 1 1/2 years old (Feb 2008) and there are lots of bug fixes in svn. Phil |
|
From: Markus H. <mar...@mh...> - 2009-05-25 20:53:00
|
Phil Longstaff writes: > Lines 541/542 of dbd_sqlite3 are dangerous. They free the static char* errmsg without resetting the pointer to NULL. This will cause line 624 in dbi_conn_error() to free the pointer again. > I don't know the architecture of libdbi well enough to propose a fix. Perhaps remove line 542 of dbd_sqlite3.c. Perhaps add a dbi_conn_clear_error() which frees the pointer and then clears it. > Hi Phil, thanks for analyzing and reporting this problem. To the best of my knowledge the proper way to handle this is to remove the free() call as libdbi handles the error strings all by itself. I've checked in fixed versions of dbd_sqlite3.c and dbd_sqlite.c which had the same problem. Could you please test the new version and see if it helps? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Phil L. <plo...@ro...> - 2009-05-24 03:04:33
|
Valgrind has provided info on a memory handling problem:
==14314== Invalid free() / delete / delete[]
==14314== at 0x4025DFA: free (vg_replace_malloc.c:323)
==14314== by 0x7F9EB84: dbi_conn_error (in /usr/lib/libdbi.so.0.0.5)
==14314== by 0x7F5EBE2: sqlite3_error_fn (gnc-backend-dbi.c:156)
==14314== by 0x7F9DB90: _error_handler (in /usr/lib/libdbi.so.0.0.5)
==14314== by 0x7F9DC80: dbi_conn_get_table_list (in
/usr/lib/libdbi.so.0.0.5)
==14314== by 0x7F62309: conn_does_table_exist (gnc-backend-dbi.c:1243)
==14314== Address 0x8950cf0 is 0 bytes inside a block of size 1 free'd
==14314== at 0x4025DFA: free (vg_replace_malloc.c:323)
==14314== by 0x7F968CE: dbd_list_tables (in /usr/lib/dbd/libdbdsqlite3.so)
==14314== by 0x7F9DC5B: dbi_conn_get_table_list (in
/usr/lib/libdbi.so.0.0.5)
==14314== by 0x7F62309: conn_does_table_exist (gnc-backend-dbi.c:1243)
I've removed parts of the stack traces which are not important.
1102 dbi_result dbi_conn_get_table_list(dbi_conn Conn, const char *db, const
char *pattern) {
1103 dbi_conn_t *conn = Conn;
1104 dbi_result_t *result;
1105
1106 if (!conn) return NULL;
1107
1108 _reset_conn_error(conn);
1109
1110 result = conn->driver->functions->list_tables(conn, db, pattern);
1111
1112 if (result == NULL) {
1113 _error_handler(conn, DBI_ERROR_DBD);
1114 }
1115
1116 return (dbi_result)result;
1117 }
(this includes the line numbers from the web cvs browser)
dbd_sqlite3.c has:
529 dbi_result = dbd_query(tempconn, sql_cmd);
530 free(sql_cmd);
531 /* fprintf(stderr, "select from sqlite3_master has run\n"); */
532 if (dbi_result) {
533 while (dbi_result_next_row(dbi_result)) {
534 asprintf(&sql_cmd, "INSERT INTO libdbi_tablenames VALUES ('%s')", dbi_result_get_string(dbi_result, "name"));
535 retval = sqlite3_exec((sqlite3*)(conn->connection), sql_cmd, NULL, NULL, &sq_errmsg);
536 free(sql_cmd);
537 }
538 dbi_result_free(dbi_result);
539 }
540 else {
541 dbi_conn_error(tempconn, (const char**)&sq_errmsg);
542 free(sq_errmsg);
543 }
544
545 // sqlite3_close((sqlite3*)(tempconn->connection));
546 dbi_conn_close(tempconn);
547
548 return dbd_query(conn, "SELECT tablename FROM libdbi_tablenames ORDER BY tablename");
dbi_conn_error has:
618 int dbi_conn_error(dbi_conn Conn, const char **errmsg_dest) {
619 dbi_conn_t *conn = Conn;
620 char number_portion[20];
621 static char *errmsg = NULL; // XXX quick hack, revisit this when API is redesigned
622
623 if (errmsg_dest) {
624 if (errmsg) free(errmsg);
625
626 if (conn->error_number) {
627 snprintf(number_portion, 20, "%d: ", conn->error_number);
628 }
629 else {
630 number_portion[0] = '\0';
631 }
632
633 asprintf(&errmsg, "%s%s", number_portion, conn->error_message ? conn->error_message : "");
634 *errmsg_dest = errmsg;
635 }
636
637 return conn->error_number;
638 }
Lines 541/542 of dbd_sqlite3 are dangerous. They free the static char* errmsg without resetting the pointer to NULL. This will cause line 624 in dbi_conn_error() to free the pointer again.
I don't know the architecture of libdbi well enough to propose a fix. Perhaps remove line 542 of dbd_sqlite3.c. Perhaps add a dbi_conn_clear_error() which frees the pointer and then clears it.
Phil
|
|
From: Markus H. <mar...@mh...> - 2009-05-23 19:12:59
|
Toby Thain writes: > I can test on PPC and SPARC, time permitting... > Much appreciated. Let us know what happens. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Markus H. <mar...@mh...> - 2009-05-23 19:12:31
|
Mike Alexander writes: > Thanks. Unfortunately I noticed a couple of issues with this patch. > One of the data types supported by the union is DBI_INTEGER_SIZE3 but > the union doesn't have a 3 byte integer field. My change yesterday > treated it as if it were a 2 byte field, but looking closer I see that > the rest of the code treats it as if it were a 4 byte field. I've > attached a new patch that fixes this. All that's needed is moving 2 > "case DBI_INTEGER_SIZE3" statements one or two lines later. > Thanks, I've checked in the updated version. Runs ok on FreeBSD. > The other thing I noticed is that the Oracle driver still has an endian > problem. It lies about the type in the dbi_data_t struct that it > returns. It stores a long long value for all DBI_INTEGER_SIZE* types. > This won't work on a big endian machine (after my changes). See the > code around line 640 in dbd_oracle.c to see what I'm talking about. > Since I don't have Oracle or documentation for its API, this is not > something I'm prepared to fix. Neither am I. We're in dire need of an oracle maintainer. In any case, we're moving to a new test framework which should make these problems obvious, as long as we find someone who tests oracle on PowerPC... regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Mike A. <mt...@um...> - 2009-05-23 17:47:25
|
--On May 23, 2009 1:31:23 PM -0400 Toby Thain <to...@te...> wrote: > > On 22-May-09, at 4:17 PM, Markus Hoenicka wrote: > >> Mike Alexander writes: >>> I've attached a patch to fix this. This patch makes the code >>> bigger, but not much slower. If this is a problem it could be made >>> conditional >>> on the endianess of the target machine, but this didn't seem worth >>> the >>> trouble to me. >> >> Thanks Mike. I've applied the patch and tested it without any >> problems on FreeBSD. Unfortunately I can't test things on a PowerPC >> box myself, > > > I can test on PPC and SPARC, time permitting... > Thanks, but note that I submitted a slightly changed version of the patch that handles 3 byte integers correctly. See <http://www.mail-archive.com/lib...@li.../msg00255.html> for the new version of the patch. I don't know if 3 byte integers are actually used, but if so the first version of the patch won't work right. -- Mike Alexander mt...@um... Ann Arbor, MI PGP key ID: BEA343A6 |
|
From: Toby T. <to...@te...> - 2009-05-23 17:31:42
|
On 22-May-09, at 4:17 PM, Markus Hoenicka wrote: > Mike Alexander writes: >> I've attached a patch to fix this. This patch makes the code bigger, >> but not much slower. If this is a problem it could be made >> conditional >> on the endianess of the target machine, but this didn't seem worth >> the >> trouble to me. > > Thanks Mike. I've applied the patch and tested it without any problems > on FreeBSD. Unfortunately I can't test things on a PowerPC box myself, I can test on PPC and SPARC, time permitting... --Toby > as "make check" in libdbi-drivers should have revealed this problem > long ago. I didn't make the code conditional as it doesn't seem to > cause much speed loss on low-endian machines, if at all. > > regards, > Markus > > -- > Markus Hoenicka > mar...@ca... > (Spam-protected email: replace the quadrupeds with "mhoenicka") > http://www.mhoenicka.de > > ---------------------------------------------------------------------- > -------- > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity > professionals. Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp asthey present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://www.creativitycat.com > _______________________________________________ > libdbi-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdbi-devel |
|
From: Mike A. <mt...@um...> - 2009-05-23 04:46:54
|
--On May 22, 2009 10:17:47 PM +0200 Markus Hoenicka <mar...@mh...> wrote: > Mike Alexander writes: > > I've attached a patch to fix this. This patch makes the code > bigger, > but not much slower. If this is a problem it could be > made conditional > on the endianess of the target machine, but this > didn't seem worth the > trouble to me. > > Thanks Mike. I've applied the patch and tested it without any problems > on FreeBSD. Unfortunately I can't test things on a PowerPC box myself, > as "make check" in libdbi-drivers should have revealed this problem > long ago. I didn't make the code conditional as it doesn't seem to > cause much speed loss on low-endian machines, if at all. Thanks. Unfortunately I noticed a couple of issues with this patch. One of the data types supported by the union is DBI_INTEGER_SIZE3 but the union doesn't have a 3 byte integer field. My change yesterday treated it as if it were a 2 byte field, but looking closer I see that the rest of the code treats it as if it were a 4 byte field. I've attached a new patch that fixes this. All that's needed is moving 2 "case DBI_INTEGER_SIZE3" statements one or two lines later. The other thing I noticed is that the Oracle driver still has an endian problem. It lies about the type in the dbi_data_t struct that it returns. It stores a long long value for all DBI_INTEGER_SIZE* types. This won't work on a big endian machine (after my changes). See the code around line 640 in dbd_oracle.c to see what I'm talking about. Since I don't have Oracle or documentation for its API, this is not something I'm prepared to fix. -- Mike Alexander mt...@um... Ann Arbor, MI PGP key ID: BEA343A6 |
|
From: Markus H. <mar...@mh...> - 2009-05-22 20:15:26
|
Mike Alexander writes: > I've attached a patch to fix this. This patch makes the code bigger, > but not much slower. If this is a problem it could be made conditional > on the endianess of the target machine, but this didn't seem worth the > trouble to me. Thanks Mike. I've applied the patch and tested it without any problems on FreeBSD. Unfortunately I can't test things on a PowerPC box myself, as "make check" in libdbi-drivers should have revealed this problem long ago. I didn't make the code conditional as it doesn't seem to cause much speed loss on low-endian machines, if at all. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Mike A. <mt...@um...> - 2009-05-22 03:41:00
|
I've been attempting to get libdbi to work on my MacOSX PowerPC machine so I can use it with GnuCash. This has not been working because of an endian bug in dbi_result.c. The methods that return integer values (dbi_result_get_short_idx, dbi_result_get_int_idx, and dbi_result_get_longlong_idx) all assume that they can simply return the member of the field_values union that corresponds to the type they are supposed to return. For example dbi_result_get_int_idx returns field_values[fieldidx].d_long if DBI_INTEGER_SIZEMASK is less than or equal to 4. This won't work on big-endian machines. Instead you need to return the correct member of the union for the value of DBI_INTEGER_SIZEMASK so the compiler knows to cast it to the return type. I've attached a patch to fix this. This patch makes the code bigger, but not much slower. If this is a problem it could be made conditional on the endianess of the target machine, but this didn't seem worth the trouble to me. -- Mike Alexander mt...@um... Ann Arbor, MI PGP key ID: BEA343A6 |
|
From: Markus H. <mar...@mh...> - 2009-03-30 07:06:13
|
Quoting Balazs Scheidler <ba...@ba...>: > I use it this way (as a user of libdbi): > > PKG_CHECK_MODULES(LIBDBI, dbi >= $LIBDBI_MIN_VERSION,, LIBDBI_LIBS="") > > Do you have a more exact problem that I might be able to explain? > No thanks, this is about all I needed to know. I just never got round to look it up. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Balazs S. <ba...@ba...> - 2009-03-29 19:03:19
|
On Tue, 2009-03-17 at 17:48 +0100, Markus Hoenicka wrote: > Quoting Andreas Ericsson <ae...@op...>: > > >> Why not just use pkg-config and install a .pc file? Or am I missing > >> something? > >> > > > > What you're missing is that no compiler in the world will ever look at > > a .pc file, and the information should be available inside the library > > headers to be of any use. > > > > Besides, we seem to have a .pc file. However, I still have to figure > out how to use it :-( I use it this way (as a user of libdbi): PKG_CHECK_MODULES(LIBDBI, dbi >= $LIBDBI_MIN_VERSION,, LIBDBI_LIBS="") Do you have a more exact problem that I might be able to explain? -- Bazsi |
|
From: Markus H. <mar...@mh...> - 2009-03-21 23:02:53
|
Markus Hoenicka writes: > > #define LIBDBI_VERSION ((MAJOR * 10000) + (MINOR * 100) + (REVISION)) [...] > >> major = current - age > >> minor = age + 8 > >> patch = revision > >> I've checked in updated versions of configure.in and include/dbi/dbi.h.in that implement a version numbering scheme along these lines. The current cvs revision should report itself as 0.9.0-pre1. Thanks to Andreas and Florian for patiently steering me towards a better versioning scheme than originally intended. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Markus H. <mar...@mh...> - 2009-03-19 09:57:42
|
Hi, Quoting Andreas Ericsson <ae...@op...>: > Sure, but please add a LIBDBI_VERSION macro as well, or people > will start tweaking them in themselves, which will cause headache > for you if you want to add one later. > > #define LIBDBI_VERSION ((MAJOR * 10000) + (MINOR * 100) + (REVISION)) > > should do it. > Don't worry about that, we've agreed before that this is an extremely useful addition. I'll take care of this on the weekend. > I don't really give a damn where those numbers come from so long as > it can be easily found out which LIBDBI_VERSION a particular piece of > functionality or bugfix appeared in, and so long as it only ever > increases. > This is also a documentation issue. The libdbi manual contains information about deprecated functions, but it doesn't explain when new functions were added. I guess it would be quite helpful to include this information. I'll put that on my todo list. >> major = current - age >> minor = age + 8 >> patch = revision >> >> until major is actually increased? >> > > Umm. Won't major be higher now than it was before? Sorry, but I > just can't wrap my head around what the various libtool macros > are supposed to signify, and the explanations on > http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html > doesn't exactly help (why should age be reset to 0 but nothing else > changed when interfaces are removed?). > If you remove an interface, programs linked against earlier releases will no longer load if they need one of the removed functions. Age=0 simply indicates the fact that your library now doesn't meet the needs of any app linked against an earlier version, and the run-time linker can look for an older version of the library instead. OTOH if you add functions without changing anything else, older apps won't care - the extra functions don't hurt. Therefore Age>0, and the run-time linker will happily use the library. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Andreas E. <ae...@op...> - 2009-03-19 09:24:08
|
Markus Hoenicka wrote: > Hi, > > Florian Forster writes: > > What Andreas is discussing is, as far as I see, the versioning schema > > used by the GNU linker. Markus is talking about the libtool versioning > > system. Unfortunately, that's not the same thing. > > Well analyzed. I should have pointed out upfront that libdbi uses > libtool, which is why I implied we were talking about those numbers. > > > I've been given to understand that the major version under GNU/Linux is > > calculated as > > major = current - age > > while other systems (iIrc FreeBSD) would use > > major = 1 + current - age. > > > > So, if you only add new functions, `current' and `age' are increased > > which will leave `major' at the same value. > > > > That sounds good. > > > The `minor' number is, I think, basically equal to the `age' and the > > `patch' number is equal to the `revision'. For example, the libtool > > version 8:3:8 would result in the ABI version 0.8.3. > > That is: > > major = current - age > minor = age > patch = revision > > If that serves everyone's needs, I'll be happy to use this. > Sure, but please add a LIBDBI_VERSION macro as well, or people will start tweaking them in themselves, which will cause headache for you if you want to add one later. #define LIBDBI_VERSION ((MAJOR * 10000) + (MINOR * 100) + (REVISION)) should do it. I don't really give a damn where those numbers come from so long as it can be easily found out which LIBDBI_VERSION a particular piece of functionality or bugfix appeared in, and so long as it only ever increases. > > Currently, 1:0:1 is > > configured (== 0.1.0). To denote a backwards incompatible change, you'd > > use 2:0:0 which would be translated to 2.0.0. > > This is where the hairy issues start. *All* libdbi releases up to > 0.8.3 have used the libtool interface version 0:5:0. It is just > because all releases were backwards-compatible that we were not > flooded with complaints about linker errors. The next release > is going to add a couple of functions (especially the instance > interface), so we'd wind up having 1:0:1. However, 0.1.0 is not an > obvious successor for 0.8.3. So, should we use: > > major = current - age > minor = age + 8 > patch = revision > > until major is actually increased? > Umm. Won't major be higher now than it was before? Sorry, but I just can't wrap my head around what the various libtool macros are supposed to signify, and the explanations on http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html doesn't exactly help (why should age be reset to 0 but nothing else changed when interfaces are removed?). -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
|
From: Andreas E. <ae...@op...> - 2009-03-19 09:06:12
|
Florian Forster wrote:
> Hi again,
>
> On Tue, Mar 17, 2009 at 05:09:15PM +0100, Markus Hoenicka wrote:
>> I'm not going to do that, as discussed before on this list. In brief,
>> we forgot to update the libtool interface version info in the past. In
>> the worst case your suggestion will cause us to forget to uptate the
>> interface version *and* the library version :-(
>
> updating the ABI version is basically not possible to do automatically,
> that's true. Updating the defines suggested automatically would be easy,
> though:
> -- 8< (configure.{ac,in}) --
> LIBDBI_VERSION_MAJOR=`echo $PACKAGE_VERSION | cut -d'.' -f1`
> LIBDBI_VERSION_MINOR=`echo $PACKAGE_VERSION | cut -d'.' -f2`
> LIBDBI_VERSION_PATCH=`echo $PACKAGE_VERSION | cut -d'.' -f3`
> AC_SUBST(LIBDBI_VERSION_MAJOR)
> AC_SUBST(LIBDBI_VERSION_MINOR)
> AC_SUBST(LIBDBI_VERSION_PATCH)
> -- >8 --
>
> -- 8< (dbi_version.h.in) --
> #define LIBDBI_VERSION_MAJOR @LIBDBI_VERSION_MAJOR@
> #define LIBDBI_VERSION_MINOR @LIBDBI_VERSION_MINOR@
> #define LIBDBI_VERSION_PATCH @LIBDBI_VERSION_PATCH@
> #define LIBDBI_VERSION_STRING "@LIBDBI_VERSION_MAJOR@." \
> "@LIBDBI_VERSION_MINOR@.@LIBDBI_VERSION_PATCH@"
#define LIBDBI_VERSION ((LIBDBI_VERSION_MAJOR * 10000) + \
(LIBDBI_VERSION_MINOR * 100) + LIBDBI_VERSION_PATCH)
Noone wants to use 3 #ifdef's if they can get away with a
single #if ;-)
>
>> But instead of abusing the library version as an interface version,
>> I'd like to use the interface version as the library version.
>
> Yeah, that should work, too..
>
>> I've never understood why a library needs a version number that is
>> different from the interface number.
>
> Well, I usually think of the API as being whatever is *documented*. For
> example, changing the order of members in a struct would, in my opinion,
> not break API compatibility but would break ABI compatibility. As a
> developer, i. e. an ``API user'', this would not be of importance to me.
> Or course, this is a trivial example. I'm sure you can think of some
> more practical examples, a bitfield being widened or a struct being
> changed but the API only documents macros to access the struct or
> something.
>
It can be uglier than that. If you use the long datatype and and change
it to an int later, you're breaking the ABI on 64-bit platforms but not
on 32-bit ones.
> Personally, I like the package version to make a statement towards API
> compatibility, because I mainly use libraries from the viewpoint of a
> developer. The system I'm usually using is the following:
> - The major version increases upon backwards-incompatible API changes.
> - The minor version increases upon backwards-compatible API changes,
> usually additions.
> - The patch version is increased if the API has not been changed at all.
>
> The ``major'' number of this schema would roughly equal `current - age'.
>
>> What changes would justify increasing LIBDBI_MAJOR without affecting
>> LIBDBI_LIB_CURRENT?
>
> If you use `current' as major version, it is increased whenever anything
> in the API changes (assuming you don't start doing extensive
> preprocessor trickery to keep the functions as they are ;)
You can use versioned symbols for that. I don't know if that's considered
preprocessor trickery (as it's actually linker trickery). Almost all the
actual preprocessor trickery I can think of breaks the ABI and requires a
bump of the .so-version at the very least.
> - whether
> backwards compatible or not. So my point is the other way around: The
> `current' version must be increased when I would keep the `major'
> version as is.
>
>> Why would changes that require a new interface be reflected by an
>> increase of LIBDBI_MINOR instead of LIBDBI_MAJOR?
>
> In the schema above: When a function is *added*. In that case:
> - current would be increased.
> - revision would be reset to zero.
> - age would be increased.
>
> - major would stay the same.
> - minor would be increased.
> - patch would be reset to zero.
>
That's how 99% of the library developing world does it. When in doubt,
follow the path of least surprise ;-)
--
Andreas Ericsson and...@op...
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
|
|
From: Florian F. <sou...@no...> - 2009-03-19 07:25:54
|
Good morning, On Thu, Mar 19, 2009 at 01:06:48AM +0100, Markus Hoenicka wrote: > major = current - age > minor = age > patch = revision > > If that serves everyone's needs, I'll be happy to use this. it got my vote :) > However, 0.1.0 is not an obvious successor for 0.8.3. So, should we > use: > > major = current - age > minor = age + 8 > patch = revision > > until major is actually increased? Sounds reasonable, too. I think we've reached a good consensus all around :) Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/ |
|
From: Markus H. <mar...@mh...> - 2009-03-19 00:03:24
|
Hi, Florian Forster writes: > What Andreas is discussing is, as far as I see, the versioning schema > used by the GNU linker. Markus is talking about the libtool versioning > system. Unfortunately, that's not the same thing. Well analyzed. I should have pointed out upfront that libdbi uses libtool, which is why I implied we were talking about those numbers. > I've been given to understand that the major version under GNU/Linux is > calculated as > major = current - age > while other systems (iIrc FreeBSD) would use > major = 1 + current - age. > > So, if you only add new functions, `current' and `age' are increased > which will leave `major' at the same value. > That sounds good. > The `minor' number is, I think, basically equal to the `age' and the > `patch' number is equal to the `revision'. For example, the libtool > version 8:3:8 would result in the ABI version 0.8.3. That is: major = current - age minor = age patch = revision If that serves everyone's needs, I'll be happy to use this. > Currently, 1:0:1 is > configured (== 0.1.0). To denote a backwards incompatible change, you'd > use 2:0:0 which would be translated to 2.0.0. This is where the hairy issues start. *All* libdbi releases up to 0.8.3 have used the libtool interface version 0:5:0. It is just because all releases were backwards-compatible that we were not flooded with complaints about linker errors. The next release is going to add a couple of functions (especially the instance interface), so we'd wind up having 1:0:1. However, 0.1.0 is not an obvious successor for 0.8.3. So, should we use: major = current - age minor = age + 8 patch = revision until major is actually increased? regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Markus H. <mar...@mh...> - 2009-03-18 11:20:34
|
Hi, Quoting Florian Forster <sou...@no...>: > > It'll work, in the sense of ``people will find a way to calculate what > they really need from these numbers'', but is that really necessary? > Just to prove a point? I'm a bit tied up right now, so I'll attend to the details later. Just to let you know that it is not about proving a point, but about avoiding avoidable problems. If the library version numbers can be computed from the libtool interface numbers to match the major-minor-patchlevel scheme, it'll be perfectly fine with me. I just want to avoid maintaining two series of numbers manually which, to the best of my knowledge, are linked to each other anyway. regards, Markus -- Markus Hoenicka mar...@ca... (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de |
|
From: Andreas E. <ae...@op...> - 2009-03-18 09:00:47
|
Markus Hoenicka wrote: > Hi, > > Andreas Ericsson writes: > > If you add functions to the library, it will remain LINK compatible > > with applications compiled against older versions of the library (so > > the ABI-version must not be changed), but programmers who wish to utilize > > I don't understand libtool's interface definition this way: > > http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning > > Unless I'm dense, the ABI version, i.e. LIB_CURRENT does change if you > add functions to the library. However, if you do it in a way that > allows apps programmed against an older version of the interface to > still work properly, LIB_AGE gets bumped up accordingly. > > > No it's not. It depends on how rigid your various version > > numbers are. For example, a change from 0.8.3 to 1.0 means all bets > > are off. Every function in the library could have a new name, or a > > different call signature or whatever. If you bump it from 0.8.3 to > > 0.8.4, you mustn't alter existing parts of the library but can only > > fix bugs that modify existing parts in a link-compatible way. > > 0.8.3 to 0.9.0 means you can add new functions (introducing a new > > .so-version that older applications can link against, but apps built > > against that version of the library cannot necessarily be linked to > > older versions of the library). > > > > First of all, I suggest to move to 1.0 (=1:0:0) because our library > version information has been broken since 0.6 (in fact, the stuff has > been broken from the very beginning as the maintainers back then > arbitrarily started at 0:5:0 instead of 0:0:0). We eventually have to > get this straight, and the changes implemented in the upcoming > release, like instances, provide a good occasion to do so. This is > admittedly a bit unclean, but further building upon the incorrect > interface numbers is probably not going to do us any good. > > Now for your discussion of the version numbers. I see this as a pretty > arbitrary convention to use the second position to denote interface > changes (what is the first position good for?). If you replace 0.8.3 > with 8.3, 0.8.4 with 8.4, and 0.9.0 with 9.0 in your above discussion, > all your points still hold true, but the shorter numbers could easily > be derived from libtool's interface version numbers. > No. Major version bumps is for when you re-design the library (or parts of it) entirely so that it no longer remains backwards compile-compatible. Package managers like to have those three distinctions, and it's otherwise unclear to many when they need to change their code for their apps to keep on working. > > > > What changes would justify increasing > > > LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT? > > > > None. But you could go from 0.8.0 to 0.8.1 without bumping the .so- > > version if you make some simple bugfixes without adding new functionality > > in 0.8.1. > > > > Just as I could go from 8.0 to 8.1 (LIB_CURRENT doesn't change, > LIB_REVISION gets bumped) without affecting the .so number. > > > If by "new interface" you mean adding functionality without touching old > > stuff in the library, it's because old applications can still run with > > the new library if you only bump the API version. > > > > And they can do so if I bump both LIB_CURRENT and LIB_AGE, unless I'm > way off. > > > > Also, a library isn't something > > > that needs to be marketed via version numbers. We'll never jump from > > > 1.2 to 5.0 just because some competitor has 4.0. > > > > > > > It's not about that, and all about being able to add new functionality > > without forcing old applications to be rebuilt against the new API *if* > > you didn't change the old one. > > > > Sure. I just wanted to make my point that library version numbers > need not be arbitrary numbers. It doesn't hurt if they simply reflect > the ABI changes. > > > (why is LIBDBI_LIB_AGE bumped here?) > > > > bzzt! wrong. Now every app linked against an old library will have to be > > relinked against the new one. A major headache for package maintainers. > > > No, because we've bumped LIB_AGE. > Right. I should've read up on libtool. I guess (LIB_CURRENT - LIB_AGE) somehow determine the .so-version. Either way, this is beginning to drift off-topic. Me, as a programmer / package maintainer, I'd like the version number to tell me * what project-version my code is being compiled against. * when new functionality is introduced that new packages may depend upon. * when a version of the library can no longer be used for old apps to link against. * when a library upgrade will prevent my code from compiling against the library's headers (preferrably without having to go and read patches etc). Which of those wishes you decide to honor, and how, is up to you as the package maintainer ofcourse. Sorry for falling into the trap of talking details about a specific solution when what I really want is just the short list above, which can obviously be solved in many ways. I'm just inclined to like the A.B.C idiom as it's fairly widely used. -- Andreas Ericsson and...@op... OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. |
|
From: Florian F. <sou...@no...> - 2009-03-18 08:58:43
|
Hi, I have the feeling you're talking at cross purposes here. On Wed, Mar 18, 2009 at 12:14:27AM +0100, Markus Hoenicka wrote: > Andreas Ericsson writes: > > If you add functions to the library, it will remain LINK compatible > > with applications compiled against older versions of the library (so > > the ABI-version must not be changed), but programmers who wish to utilize > > I don't understand libtool's interface definition this way: > > http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.html#Libtool-versioning > > Unless I'm dense, the ABI version, i.e. LIB_CURRENT does change if you > add functions to the library. However, if you do it in a way that > allows apps programmed against an older version of the interface to > still work properly, LIB_AGE gets bumped up accordingly. What Andreas is discussing is, as far as I see, the versioning schema used by the GNU linker. Markus is talking about the libtool versioning system. Unfortunately, that's not the same thing. libtool is used to create shared libraries on a variety of systems. And not all systems use the same versioning schema of the GNU linker. So instead of specifying the ABI version directly, you give something that looks similar to a version number to libtool from which it will create a version as understood by the runtime system. I've been given to understand that the major version under GNU/Linux is calculated as major = current - age while other systems (iIrc FreeBSD) would use major = 1 + current - age. So, if you only add new functions, `current' and `age' are increased which will leave `major' at the same value. The `minor' number is, I think, basically equal to the `age' and the `patch' number is equal to the `revision'. For example, the libtool version 8:3:8 would result in the ABI version 0.8.3. Currently, 1:0:1 is configured (== 0.1.0). To denote a backwards incompatible change, you'd use 2:0:0 which would be translated to 2.0.0. > > > What changes would justify increasing > > > LIBDBI_MAJOR without affecting LIBDBI_LIB_CURRENT? > > > > None. But you could go from 0.8.0 to 0.8.1 without bumping the .so- > > version if you make some simple bugfixes without adding new > > functionality in 0.8.1. > > Just as I could go from 8.0 to 8.1 (LIB_CURRENT doesn't change, > LIB_REVISION gets bumped) without affecting the .so number. This should be the same thing. > > If by "new interface" you mean adding functionality without touching > > old stuff in the library, it's because old applications can still > > run with the new library if you only bump the API version. > > And they can do so if I bump both LIB_CURRENT and LIB_AGE, unless I'm > way off. AfaIk that's correct. If you increase both, `current' and `age', the `major' version stays the same and the `minor' version gets increased. Again: The same thing. > > > Also, a library isn't something that needs to be marketed via > > > version numbers. We'll never jump from 1.2 to 5.0 just because > > > some competitor has 4.0. > > > > It's not about that, and all about being able to add new > > functionality without forcing old applications to be rebuilt against > > the new API *if* you didn't change the old one. In fact, using the `current' number will yield higher versions much faster than one would manually set the `major' number. As you can see in the example above, the next major version (after `0') will be `2', because a backwards compatible feature has been added and `current' is increased regardless of any backwards compatibility. > Sure. I just wanted to make my point that library version numbers need > not be arbitrary numbers. It doesn't hurt if they simply reflect the > ABI changes. That's right, but.. I for one don't like the libtool schema at all. It's bad enough the developer(s) of a library need to know about it. Using this schema as the package version is very confusing: It isn't the ABI version (=> it's not useful for binary package maintainers), it isn't the API version (=> it's not useful for developers), it's just some piece of information required by libtool to generate an ABI version. So you, as the one executing `make dist', are the only one who ever *needs* to get in touch with these numbers. For everybody else, the libtool version are the ``arbitrary numbers''. It'll work, in the sense of ``people will find a way to calculate what they really need from these numbers'', but is that really necessary? Just to prove a point? Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/ |
9 messages has been excluded from this view by a project administrator.
