libdbi-devel — Discussion about development of the core library and DBD interface

[libdbi-devel] improvements of test cases

[J. H. F. <jo...@gm...>]

Hello,

I am working in the improvements of libdbi tests and need of your
opinion about the files attached.


My motivation is split the tests and use a framework to do unit tests
and functional tests on every routine of libdbi.

It's very simple. But can help to organize the cycle of development
and test of the project.

You can download from: http://joaohff.pbwiki.com/f/tests-libdbi-cgreen.tar.gz

Thanks for attention.

PS: I use the framework cgreen from
http://www.lastcraft.com/cgreen.php, it's a LGPL and very interesting
to work. It has support for mock objects, asserts, tests suits and
group of test suits. To
use the exemples:
untar the file in libdbi-drivers
cd tests
cd cgreen; make
cd ..; make check.

Tested with sqllite3 and postgresql. Mysql not work and I don't know
why... :(. For currently I am working on it.

-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com

[libdbi-devel] Bug in configure script for libdbi-drivers-0.8.3-1

[Markus H. <mar...@mh...>]

Hi,

Dan Wells writes:
 > In other words, and to repeat,
 > --enable-libdbi
 > --enable-libdbi=yes
 > --enable-libdbi=no
 > --disable-libdbi
 > all result in no linking.

Thanks for discovering this odd behaviour. The implementation of the
test for the --enable-libdbi option in configure was indeed
faulty. I've checked in a fixed version into CVS. If you badly need a
working tarball, please let me know. I'd then wrap up a new
prerelease.
 
 > 
 > Attached is fixed version of configure.  I am not sure how helpful it will be when using autoconf, but it's at least a start.
 > 

configure is built from configure.in by the package maintainer. Your
attempt to help is greatly appreciated, but it is (the much simpler
and shorter) configure.in that needed to be fixed.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] Bug in configure script for libdbi-drivers-0.8.3-1

[Dan W. <db...@ca...>]

Hello,

After some recent mucking around, I seem to have found a bug in the configure script for the relatively recent libdbi-drivers version 0.8.3-1.  Basically, linking against libdbi is now the default option, but the old --enable-libdbi option is now broken and is in fact analogous to the new option --disable-libdbi, and therefore does exactly the opposite of what one would want.  More precisely
--disable-libdbi is treated as --enable-libdbi=no
and
--enable-libdbi is treated as --enable-libdbi=yes
(a now redundant option)
but the configure script only checks if --enable-libdbi is set without checking the actual value.  If it is set AT ALL, linking is disabled.

In other words, and to repeat,
--enable-libdbi
--enable-libdbi=yes
--enable-libdbi=no
--disable-libdbi
all result in no linking.

Attached is fixed version of configure.  I am not sure how helpful it will be when using autoconf, but it's at least a start.

Thanks,
DW

[libdbi-devel] libdbi and bind functions, testing

[J. H. F. <jo...@gm...>]

Hello,

I need to work with some bind functions in libdbi. And I will test all
and put on dbi_test.c.

Before, a little test whit the code:

#include <stdio.h>
#include <dbi/dbi.h>
int main() {
dbi_conn conn;
dbi_result result;
dbi_inst instance;
double threshold = 1;
unsigned int idnumber;
const char *fullname = (char *)malloc(sizeof(char) * 30);
int error;
dbi_initialize_r(NULL, &instance);
conn = dbi_conn_new_r("pgsql", instance);
dbi_conn_set_option(conn, "host", "127.0.0.1");
dbi_conn_set_option(conn, "port", "5432");
dbi_conn_set_option(conn, "username", "regress");
//dbi_conn_set_option(conn, "password", "");
dbi_conn_set_option(conn, "dbname", "libdbitest");
dbi_conn_set_option(conn, "encoding", "UTF-8");
if (dbi_conn_connect(conn) < 0) {
	printf("Could not connect. Please check the option settings\n");
}
else {
	result = dbi_conn_queryf(conn, "SELECT id, name FROM authors "
		"WHERE hours_of_sleep > %0.2f", threshold);
	if (result) {
		while (dbi_result_next_row(result)) {
			error = dbi_result_bind_uint(result, "id", &idnumber);			
			dbi_result_bind_string(result, "name", &fullname);
			printf("%i. %s\n", idnumber, fullname);
		}
		dbi_result_free(result);
	}
	
	dbi_conn_close(conn);

}

dbi_shutdown_r(instance);

return 0;
}

In database:

libdbitest=# select * from authors;

 id | name  | hours_of_sleep
----+-------+----------------
  1 | joao  |              2
  2 | joao  |              2
  3 | joao  |             20
 40 | joao  |             20
 40 | jOO   |              2
 40 | Erika |              2
 40 | Er    |              2
(7 registros)

The result of program:

 ./dbi_bind_test
custom_functions went to 0x804bcb0
custom_functions went to 0x804d498
custom_functions went to 0x8051a88
134514196.
2. joao
3. joao
40. joao
40. jOO
40. Erika
40. Er


Two questions:

1. Is correct the use of bind functions?
2. Why the first result is 134514196. ?


Thanks.
-- 
-----------------------------------------------------------
João Henrique Freitas - joaohf_at_gmail.com
Campinas-SP-Brasil
BSD051283
LPI 1
http://joaohf.pbwiki.com
http://www.livejournal.com/users/joaohf/

Re: [libdbi-devel] [patch] plugin support

[Markus H. <mar...@mh...>]

Rainer Gerhards writes:
 > The problem was that I originally had the caller define the instance
 > structure (well, kind of... ;)). I discovered this didn't work (I was
 > too much rsyslog-minded, especially in my assumptions), changed things
 > and forgot to re-test with the old interface. New patch attached,
 > replaces the old one. I have done some limited testing with rsyslog
 > itself.
 > 

I've applied and checked in the suggested patch with a few minor
modifications:

1) dbi.h is an autogenerated file, so I moved the changes into
   dbi.h.in

2) some drivers need access to the instance (see below), so I added
   the accessor dbi_driver_get_instance()

I've adapted test_dbi.c in libdbi-drivers and checked both
interfaces. It turned out that some drivers (ingres, sqlite, sqlite3)
run dbi_conn_new() in order to access databases other than the one
they're connected to. This works when using the old interface, but
must fail when the plugin-safe interface is used instead. I've changed
these calls to dbi_conn_new_r() which works ok with both interfaces.

However, this means that we'll have to move at least to 0.9 because
the next libdbi release won't work with 0.8.x drivers as soon as you
use the plugin-safe interface. Both libdbi and libdbi-drivers
currently call themselves 0.9.0-pre1. Once we move to a new major
release, we should review the discussion about unifying the version
numbers and the library versioning information, see this feature
request:


http://sourceforge.net/tracker/index.php?func=detail&aid=1578577&group_id=65979&atid=512948

This would finally get us to 1.0 for both libdbi and
libdbi-drivers. Before doing so, I'd once again ask everyone to test
the new interface with all OSes you can get hold of, and to speak up
now if any other important changes are required.

I'll update the Programmer's Manual and the Driver Manual in the next
days to reflect the API changes.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] [patch] plugin support

[Rainer G. <rge...@hq...>]

>  > As a side-note, one must be careful when converting to the new
>  > interface. If just the dbi_initialize_r() is used but the others
use
> the
>  > old functions, there is a lot of trouble. I ran myself into it.
>  > Unfortunately, I have no smart idea how to circumvent it. The
> deprecated
>  > macros will probably help... ;)
>  >
> 
> A half-assed way to circumvent this problem is to have
> dbi_initialize_r set dbi_inst_legacy in addition to the structure
> pointed to by **Inst. This will allow to run the old functions safely
> and correctly as long as the initialization function is called only
> once. However, this way we'll probably help to cover up many
> incomplete migration attempts, so it may be more prudent to have the
> apps crash right away so they get fixed.

I thought about that, but the "as long as the init function is called
only once" is indication of a subtle problem with it. Consider this:

- thinking about a plug-in system
- still assume that the loader keeps a 
  single static data area in memory no matter
  how many plugins use libdbi
- there is *exactly* one plugin that uses the
  Old interface
- there is one or more plugins using the new
  Interface

In that situation, without the flag, everything works ok because the old
interface plugin finds everything as expected. With a flag, the first
call to dbi_initialize_r would kind of disable the old style interface
calls, thus giving the old interface plugin a hard time.

Granted, it is a very very unusual case, probably never to be seen in
practice. It's also questionable if keeping things happy in that case
outweights the benefits of another solution. But together with your
thoughts on preventing incomplete migration attempts it probably adds to
solid reasoning NOT to support such a flag.

I just wanted to pass the info, hopefully its useful.

Rainer

Re: [libdbi-devel] [patch] plugin support

[Markus H. <mar...@mh...>]

Rainer Gerhards writes:
 > The problem was that I originally had the caller define the instance
 > structure (well, kind of... ;)). I discovered this didn't work (I was
 > too much rsyslog-minded, especially in my assumptions), changed things
 > and forgot to re-test with the old interface. New patch attached,
 > replaces the old one. I have done some limited testing with rsyslog
 > itself.
 > 

This one works for me, using the old interface. I'll attempt to modify
libdbi-driver's test program to allow testing both interfaces. I'll be
back with the results of the new interface as soon as time permits.

 > As a side-note, one must be careful when converting to the new
 > interface. If just the dbi_initialize_r() is used but the others use the
 > old functions, there is a lot of trouble. I ran myself into it.
 > Unfortunately, I have no smart idea how to circumvent it. The deprecated
 > macros will probably help... ;)
 > 

A half-assed way to circumvent this problem is to have
dbi_initialize_r set dbi_inst_legacy in addition to the structure
pointed to by **Inst. This will allow to run the old functions safely
and correctly as long as the initialization function is called only
once. However, this way we'll probably help to cover up many
incomplete migration attempts, so it may be more prudent to have the
apps crash right away so they get fixed.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] [patch] plugin support

[Rainer G. <rge...@hq...>]

The problem was that I originally had the caller define the instance
structure (well, kind of... ;)). I discovered this didn't work (I was
too much rsyslog-minded, especially in my assumptions), changed things
and forgot to re-test with the old interface. New patch attached,
replaces the old one. I have done some limited testing with rsyslog
itself.

As a side-note, one must be careful when converting to the new
interface. If just the dbi_initialize_r() is used but the others use the
old functions, there is a lot of trouble. I ran myself into it.
Unfortunately, I have no smart idea how to circumvent it. The deprecated
macros will probably help... ;)

Rainer

On Sat, 2008-02-16 at 17:07 +0100, Markus Hoenicka wrote:
> Rainer Gerhards writes:
>  > Please review the patch, comments are of course welcome.
>  > 
> 
> Thanks for the patch, which looks pretty clean and useful. However, a
> quick test on FreeBSD using libdbi-drivers "make check" (which
> still uses the *old* interface) causes a coredump:
> 
> 5 drivers available: /usr/local/bin/bash: line 4:  5147 Segmentation fault: 11  (core dumped) ${dir}$tst
> 
> and gdb says:
> 
> (gdb) bt
> #0  0x28080561 in dbi_driver_get_name () from /usr/local/lib/libdbi.so.0
> #1  0x0804a8df in ask_for_conninfo (ptr_cinfo=0xbfbfe240) at test_dbi.c:525
> #2  0x08049883 in main (argc=1, argv=0xbfbfe758) at test_dbi.c:69
> 
> I'll further investigate, but if you see an obvious error in the code
> based on this observation, let me know.
> 
> regards,
> Markus
> 

[libdbi-devel] [patch] plugin support

[Markus H. <mar...@mh...>]

Rainer Gerhards writes:
 > Please review the patch, comments are of course welcome.
 > 

Thanks for the patch, which looks pretty clean and useful. However, a
quick test on FreeBSD using libdbi-drivers "make check" (which
still uses the *old* interface) causes a coredump:

5 drivers available: /usr/local/bin/bash: line 4:  5147 Segmentation fault: 11  (core dumped) ${dir}$tst

and gdb says:

(gdb) bt
#0  0x28080561 in dbi_driver_get_name () from /usr/local/lib/libdbi.so.0
#1  0x0804a8df in ask_for_conninfo (ptr_cinfo=0xbfbfe240) at test_dbi.c:525
#2  0x08049883 in main (argc=1, argv=0xbfbfe758) at test_dbi.c:69

I'll further investigate, but if you see an obvious error in the code
based on this observation, let me know.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] error compiling CVS head (doc generation)

[Markus H. <mar...@mh...>]

Rainer Gerhards writes:
 > fmtutil: no info for format `pdfjadetex'.

This simply means that you do not have jadetex (a TeX macro package to
turn openjade's TeX output into PDF) installed. If there is
no suitable package for your OS, you can pass --disable-docs to
./configure to get rid of this problem.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] [patch] plugin support

[Rainer G. <rge...@hq...>]

As discussed on the -user mailing list, I have created a small patch to
support calling libdbi from plugins (where several plugins may call into
dbi_initialize() not knowing about each other).

I have used the _r naming conventions for the changed functions. Please
note that I needed to change a bit more code as rootconn was also
affected by the requirement.

I have tried to keep as consistent with the libdbi interface as
possible. However, in dbi_initialize_r(), I have slightly different
calling conventions. I now needed to pass a second output parameter (the
instance pointer). Fully in line with existing calling conventions would
be to make dbi_initialize_r() return the dbi_inst handle. However, that
would have required to introduce a new function to query the loaded
driver count. I think this would be more intrusive and probably
confusing to existing code. So I decided to go for a output param.

Please review the patch, comments are of course welcome.

Rainer

[libdbi-devel] error compiling CVS head (doc generation)

[Rainer G. <rge...@hq...>]

Hi,

I have pulled CVS head. Whenever I compile  (make) the complete package,
I get this error:

-------
Making all in doc
make[2]: Entering directory `/home/rger/proj/libdbi.new/doc'
Converting programmers-guide.sgml to PDF...
openjade -t tex -V tex-backend -d ../doc/include/doc-print.dsl
programmers-guide.sgml
pdftex "&pdfjadetex" programmers-guide.tex
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
kpathsea: Running mktexfmt pdfjadetex.fmt
fmtutil: no info for format `pdfjadetex'.
Sorry, I can't find the format `pdfjadetex.fmt'; will try `pdftex.fmt'.
entering extended mode
(./programmers-guide.tex
! Undefined control sequence.
l.1 \FOT
        {3}\Seq%
? 
-------------

any idea?

Rainer

[libdbi-devel] Problems in dbi_result_get_binary_copy_idx

[Markus H. <mar...@mh...>]

Jo=E3o Henrique Freitas writes:
 > I have a problem in the function dbi=5Fresult=5Fget=5Fbinary=5Fcopy.=

 >=20
 > That function call the dbi=5Fresult=5Fget=5Fbinary=5Fcopy=5Fidx.
 >=20
 > In the code dbi=5Fresult.c on line 1310 and 1311. The size variable
 > always is 0 or a low value and malloc allocates insufficient space i=
n
 > pointer to newblob. The result is in line 1316 , memcpy not works li=
ke
 > expected.
 >=20
 > And so I think that has a little bug in dbi=5Fresult=5Fget=5Fbinary=5F=
copy=5Fidx.
 >=20

Your analysis is correct. The problem is caused by the improper use of
the field index in the call to
dbi=5Fresult=5Fget=5Ffield=5Flength=5Fidx(). libdbi uses a 0-based inde=
x
internally, but when an API function is called, we need to use the
user-visible 1-based index instead. Therefore this call retrieved the
size of an adjacent column, causing the blob to get truncated.

I've checked in a fix (see the attached diff for reference). I've also
checked in an extended version of your test=5Fdbi.c patch which covers
all database engines and also fixes a few minor errors in your
patch. I was a little surprised to learn that one of the API functions
was not covered by a test. Thanks for getting this to my attention.

regards,
Markus

[libdbi-devel] Problems in dbi_result_get_binary_copy_idx

[<jo...@gm...>]

SSBoYXZlIGEgcHJvYmxlbSBpbiB0aGUgZnVuY3Rpb24gZGJpX3Jlc3VsdF9nZXRfYmluYXJ5X2Nv
cHkuCgpUaGF0IGZ1bmN0aW9uIGNhbGwgdGhlIGRiaV9yZXN1bHRfZ2V0X2JpbmFyeV9jb3B5X2lk
eC4KCkluIHRoZSBjb2RlIGRiaV9yZXN1bHQuYyBvbiBsaW5lIDEzMTAgYW5kIDEzMTEuIFRoZSBz
aXplIHZhcmlhYmxlCmFsd2F5cyBpcyAwIG9yIGEgbG93IHZhbHVlIGFuZCBtYWxsb2MgYWxsb2Nh
dGVzIGluc3VmZmljaWVudCBzcGFjZSBpbgpwb2ludGVyIHRvIG5ld2Jsb2IuIFRoZSByZXN1bHQg
aXMgaW4gbGluZSAxMzE2ICwgbWVtY3B5IG5vdCB3b3JrcyBsaWtlCmV4cGVjdGVkLgoKQW5kIHNv
IEkgdGhpbmsgdGhhdCBoYXMgYSBsaXR0bGUgYnVnIGluIGRiaV9yZXN1bHRfZ2V0X2JpbmFyeV9j
b3B5X2lkeC4KCkkgaGF2ZSB0ZXN0ZWQgd2l0aCBtb2RpZmljYXRpb24gaW4gbGliZGJpLWRyaXZl
cnMvdGVzdHMvdGVzdF9kYmkuYwp3aXRoIHRoZSBmb2xsb3dpbmcgcGF0Y2ggdG8gcHJvdmUgdGhp
cyBidWcuIEluIG15IHByb2plY3QgSSBzZWUgdGhpcwpidWcgdG9vLgoKVGhhbmtzCgpQUzogVmVy
c2lvbiB1c2VkIDAuOC4zLXByZTEgYW5kIG15c3FsIGRyaXZlcgoKLS0gCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkpvw6NvIEhlbnJp
cXVlIEZyZWl0YXMgLSBqb2FvaGZfYXRfZ21haWwuY29tCkNhbXBpbmFzLVNQLUJyYXNpbApCU0Qw
NTEyODMKTFBJIDEKaHR0cDovL2pvYW9oZi5wYndpa2kuY29tCmh0dHA6Ly93d3cubGl2ZWpvdXJu
YWwuY29tL3VzZXJzL2pvYW9oZi8K

[libdbi-devel] Problems in dbi_result_get_binary_copy_idx

[<jo...@gm...>]

SSBoYXZlIGEgcHJvYmxlbSBpbiB0aGUgZnVuY3Rpb24gZGJpX3Jlc3VsdF9nZXRfYmluYXJ5X2Nv
cHkuCgpUaGF0IGZ1bmN0aW9uIGNhbGwgdGhlIGRiaV9yZXN1bHRfZ2V0X2JpbmFyeV9jb3B5X2lk
eC4KCkluIHRoZSBjb2RlIGRiaV9yZXN1bHQuYyBvbiBsaW5lIDEzMTAgYW5kIDEzMTEuIFRoZSBz
aXplIHZhcmlhYmxlCmFsd2F5cyBpcyAwIG9yIGEgbG93IHZhbHVlIGFuZCBtYWxsb2MgYWxsb2Nh
dGVzIGluc3VmZmljaWVudCBzcGFjZSBpbgpwb2ludGVyIHRvIG5ld2Jsb2IuIFRoZSByZXN1bHQg
aXMgaW4gbGluZSAxMzE2ICwgbWVtY3B5IG5vdCB3b3JrcyBsaWtlCmV4cGVjdGVkLgoKQW5kIHNv
IEkgdGhpbmsgdGhhdCBoYXMgYSBsaXR0bGUgYnVnIGluIGRiaV9yZXN1bHRfZ2V0X2JpbmFyeV9j
b3B5X2lkeC4KCkkgaGF2ZSB0ZXN0ZWQgd2l0aCBtb2RpZmljYXRpb24gaW4gbGliZGJpLWRyaXZl
cnMvdGVzdHMvdGVzdF9kYmkuYwp3aXRoIHRoZSBmb2xsb3dpbmcgcGF0Y2ggdG8gcHJvdmUgdGhp
cyBidWcuIEluIG15IHByb2plY3QgSSBzZWUgdGhpcwpidWcgdG9vLgoKVGhhbmtzCgotLSAKLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
Sm/Do28gSGVucmlxdWUgRnJlaXRhcyAtIGpvYW9oZl9hdF9nbWFpbC5jb20KQ2FtcGluYXMtU1At
QnJhc2lsCkJTRDA1MTI4MwpMUEkgMQpodHRwOi8vam9hb2hmLnBid2lraS5jb20KaHR0cDovL3d3
dy5saXZlam91cm5hbC5jb20vdXNlcnMvam9hb2hmLwo=

Re: [libdbi-devel] [libdbi-users] escape a string, not quoted

[Markus H. <mar...@mh...>]

[cc'ing the developers lists - someone might be listening...]

Jo=E3o Henrique Freitas writes:
 > Ok Markus.
 >=20
 > I am working in the code....
 >=20
 > Currently the functions dbi=5Fconn=5Fescape=5Fstring(),
 > dbi=5Fconn=5Fescape=5Fstring=5Fcopy(), and
 > dbi=5Fconn=5Fescape=5Fbinary=5Fcopy() quote and escape. Is possible =
create
 > dbi=5Fconn=5Fescape=5Fonly=5Fstring(), dbi=5Fconn=5Fescape=5Fonly=5F=
string=5Fcopy(), and
 > dbi=5Fconn=5Fescape=5Fonly=5Fbinary=5Fcopy() functions to only escap=
e a string,
 > not quote. This seems to be much simple to do.
 >=20
 > And will do not break the current API.
 >=20
 >=20
 > Other suggestion is implement an option in functions dbi=5Fconn=5Fes=
cape=5F*
 > to select quote or not to quote a string
 >=20

Good to hear you're working on the code. I can imagine several
solutions. Before outlining them, let me briefly reiterate two issues
related to backwards-compatibility:

1) external API: this is the one that libdbi end-users use to
   implement their stuff. If we simply add functions, old code will
   continue to work with the new libdbi versions. If we change the
   prototypes, or alter the way a function behaves, we'll break
   existing code. We can do that if we have enough reason to do so,
   but this warrants a new series (0.9 in our case, or 1.0 if we move
   to proper library versioning as discussed earlier on this list).

2) driver API: this is the one that driver authors use. If we add
   functions to the external API which requires implementations in
   each driver, we also have to move to new libdbi and libdbi-drivers
   series as existing drivers won't work with the next libdbi release.

That is, if we don't want to move to 0.9 or 1.0 right away, we'd have
to avoid changing the driver API and we mustn't alter the
implementations of existing functions. I see the following solutions,
in increasing order of invasiveness:

1) add new functions dbi=5Fconn=5Fescape=5Fstring(),
   dbi=5Fconn=5Fescape=5Fstring=5Fcopy(), and dbi=5Fconn=5Fescape=5Fbin=
ary=5Fcopy()
   and implement them entirely in libdbi. All these functions have to
   do is to call the dbi=5Fconn=5Fquote=5F* equivalents and strip the q=
uotes
   (i.e. the first and the last character) from the resulting strings
   or blobs. No driver API change, backwards compatible external API
   change.

2) as per your suggestion, add a boolean argument to the existing
   functions which selects whether or not to add the quotes. The
   functions could be implemented in libdbi, or be passed to the
   drivers. Backwards incompatible external API change, optional
   driver API change.

3) the cleanest solution: add the new functions to the external API
   and pass them to the drivers. Backwards incompatible external API
   change, driver API change.

My personal taste suggests 1) but I'm open to suggestions.

regards,
Markus

--=20
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] libdbi in Debian being outdated and seems orphaned: can I take over the package?

[Markus H. <mar...@mh...>]

Quoting Thomas Goirand <th...@go...>:

> Hello,
>
> Bellow is the mail I received from the upstream of libdbi. The current
> maintainer, David Parker, is Cc: to this message, so he can reply if he
> is still interested in doing the maintenance.
>
> If David is not willing to continue maintaining it, I can try to take
> over the package.
>

Did you Thomas, or David, get any feedback from Jeremy Malcolm? I know =20
Jeremy from the RefDB mailing list, and I recall that he intended to =20
package RefDB and maybe libdbi too.

> The last entry in the Debian changelog is "Tue, 20 Jan 2004", which is
> quite old. And there's this "quite annoying" bug with no reply from the
> current maintainer:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D312115
>
> which made the lib removed from Etch.
>

I have never seen a crash like this on any recent version of libdbi. =20
However, I'm testing libdbi on FreeBSD and on Windows/Cygwin, and =20
there is always a chance that Debian is a little less forgiving in =20
terms of memory allocation errors. But then, I use valgrind to check =20
alloc problems quite frequently, and I didn't see any errors in libdbi =20
except that it may lose some memory. In any case you should keep in =20
mind that libdbi-drivers (not libdbi itself) contains a test program =20
(try "make check") that you can use to test all available drivers on =20
your particular platform. If that works ok, there are good chances =20
that the application using libdbi screwed up things and caused the =20
reported bug.

regards,
Markus


--=20
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] libdbi in Debian being outdated and seems orphaned: can I take over the package?

[Thomas G. <th...@go...>]

Hello,

Bellow is the mail I received from the upstream of libdbi. The current
maintainer, David Parker, is Cc: to this message, so he can reply if he
is still interested in doing the maintenance.

If David is not willing to continue maintaining it, I can try to take
over the package.

The last entry in the Debian changelog is "Tue, 20 Jan 2004", which is
quite old. And there's this "quite annoying" bug with no reply from the
current maintainer:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312115

which made the lib removed from Etch.

I have never maintained shared libs before, but I have some packaged
that I maintain already, it seems to me that I can do it, and I'm
willing to learn and spend the time for it (as a side note, I'm still
searching for sponsors for some of my packages to fix the bugs). I also
want to maintain libminiupnp (ITP for miniupnpc is already done, but
it's going to be renamed as such), so I will learn anyway.

Best regards,

Thomas Goirand

Markus Hoenicka wrote:
> Hi Thomas,
> 
> thanks for the heads up. I was not aware that libdbi is eligible for
> being kicked out of Debian. I'm pretty sure the other maintainers aren't
> either, so I've cc'ed the developers list too.
> 
> Unfortunately I'm not in a position to maintain the Debian packages
> myself as I do not run Debian on any of my boxes currently. I'm afraid
> that none of the other developers runs Debian either (if you do, please
> speak up now!). I'd greatly appreciate if you could lend us a hand in
> keeping libdbi in Debian.
> 
> I've checked the status of the package. It is badly outdated as we've
> switched to 0.8.x eons ago. Moreover it lists David Parker as package
> maintainer. He is one of the original developers of libdbi but he has
> been inactive for several years now. I believe we need to find a
> different maintainer for libdbi0 and the driver packages.
> 
> Let me know if you need further input from my end, or if I have to
> actively do something from my end in order to update the packages and
> keep them in Debian.
> 
> regards,
> Markus
> 
> 
> Quoting Thomas Goirand <th...@go...>:
> 
>> Hello,
>>
>> I am a Debian maintainer, and I did a Debian package for
>> libapache-mod-log-sql, as you can see here:
>>
>> http://qa.debian.org/developer.php?log...@go...
>>
>> Unfortunately, it has been asked to me to remove the build of the
>> libapache2-mod-log-sql-dbi as there are many unsolved problems in the
>> current Debian libdbi package, and that maybe the libdbi package will be
>> removed from Debian.
>>
>> First, are you aware of that? Are you willing to ask for an update, or
>> take over the current maintainer in Debian? I think it would be silly if
>> your package was removed if it's maintained.
>>
>> If you don't want to spend the time on building and maintaining the
>> software so it's uploaded to Debian, let me know, I can spend that time
>> for you.
>>
>> If you do have the time, I think you should send a mail to the
>> deb...@li... so your package is updated in the
>> unstable distribution, and then reaches the current testing. I can help
>> you by letting you know the normal procedure on how to do it.
>>
>> In any case, let me know.
>>
>> Best regards,
>>
>> Thomas Goirand, GPLHost CEO

Re: [libdbi-devel] libdbi in Debian

[Markus H. <mar...@mh...>]

Hi Thomas,

thanks for the heads up. I was not aware that libdbi is eligible for =20
being kicked out of Debian. I'm pretty sure the other maintainers =20
aren't either, so I've cc'ed the developers list too.

Unfortunately I'm not in a position to maintain the Debian packages =20
myself as I do not run Debian on any of my boxes currently. I'm afraid =20
that none of the other developers runs Debian either (if you do, =20
please speak up now!). I'd greatly appreciate if you could lend us a =20
hand in keeping libdbi in Debian.

I've checked the status of the package. It is badly outdated as we've =20
switched to 0.8.x eons ago. Moreover it lists David Parker as package =20
maintainer. He is one of the original developers of libdbi but he has =20
been inactive for several years now. I believe we need to find a =20
different maintainer for libdbi0 and the driver packages.

Let me know if you need further input from my end, or if I have to =20
actively do something from my end in order to update the packages and =20
keep them in Debian.

regards,
Markus


Quoting Thomas Goirand <th...@go...>:

> Hello,
>
> I am a Debian maintainer, and I did a Debian package for
> libapache-mod-log-sql, as you can see here:
>
> http://qa.debian.org/developer.php?log...@go...
>
> Unfortunately, it has been asked to me to remove the build of the
> libapache2-mod-log-sql-dbi as there are many unsolved problems in the
> current Debian libdbi package, and that maybe the libdbi package will be
> removed from Debian.
>
> First, are you aware of that? Are you willing to ask for an update, or
> take over the current maintainer in Debian? I think it would be silly if
> your package was removed if it's maintained.
>
> If you don't want to spend the time on building and maintaining the
> software so it's uploaded to Debian, let me know, I can spend that time
> for you.
>
> If you do have the time, I think you should send a mail to the
> deb...@li... so your package is updated in the
> unstable distribution, and then reaches the current testing. I can help
> you by letting you know the normal procedure on how to do it.
>
> In any case, let me know.
>
> Best regards,
>
> Thomas Goirand, GPLHost CEO
>



--=20
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Question about how libdbi loads drivers

[Markus H. <mar...@mh...>]

Quoting Duncan McQueen <dwm...@gm...>:

> if I pass something like 'dbd' - will it effectively look in the
> current directory plus 'dbd'?
>

I've never tried this, but libdbi uses the opendir() function to  
access the directory. To the best of my knowledge this function works  
with both absolute and relative paths. Passing "dbd" to  
dbi_initialize() should indeed look into the dbd subdirectory of the  
current working directory.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Compilation of MySQL driver under MingW

[Markus H. <mar...@mh...>]

Quoting Duncan McQueen <dwm...@gm...>:

> I couldn't get make test to work - it seemed to hang on:
>
> make check-TESTS
> make[2]: Entering directory `/home/Test/libdbi-drivers/tests'
>
> But to even get that far I had to alter the test_dbi.c (since MinGW
> has no sleep function).  See attached patch
>
>

That's not good news. I'll add the patch to the cvs version tonight.  
I'm afraid you'll have to fire up your debugger to see why make check  
fails. To this end, please cd into the tests directory and run the  
test like this (you most likely know all this, but still):

gdb test_dbi

and then on the gdb command line:

run

If the whole thing crashes, a backtrace (command: bt) should tell you  
what's the culprit.

regards,
Markus




-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [libdbi-devel] Question about how libdbi loads drivers

[Markus H. <mar...@mh...>]

Quoting Duncan McQueen <dwm...@gm...>:

> Where does it look for the dbd directory that stores the drivers?
> Does it look in the current runtime directory (ie what would be
> returned by getcwd)?
>

This is up to your app. You can pass a directory to dbi_initialize()  
to have libdbi look in that directory for the drivers. This can of  
course be also the return value of getcwd, or a subdirectory of the  
user's home directory, or whatever you like. If you pass NULL instead,  
a compile-time default will be used which you can influence with  
appropriate libdbi configure switches.

regards,
Markus



-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[libdbi-devel] Question about how libdbi loads drivers

[Duncan M. <dwm...@gm...>]

Where does it look for the dbd directory that stores the drivers?
Does it look in the current runtime directory (ie what would be
returned by getcwd)?

Re: [libdbi-devel] Compilation of MySQL driver under MingW

[Duncan M. <dwm...@gm...>]

I couldn't get make test to work - it seemed to hang on:

make check-TESTS
make[2]: Entering directory `/home/Test/libdbi-drivers/tests'

But to even get that far I had to alter the test_dbi.c (since MinGW
has no sleep function).  See attached patch


On 8/29/07, Duncan McQueen <dwm...@gm...> wrote:
> I took a look at the README.w32 file - the procedure is the same for
> MinGW - just that you need to use MSYS to compile the drivers.
>
> This section is NOT applicable to the MinGW version:
>
> Once libdbi is compiled for Win32 and you have a DLL, you can use that
> DLL like any other. The only requirement is that the cygwin runtime
> DLL is available on the target machine also, since non-Windows API
> functions are implemented by cygwin.
>
>
>
>
>
> On 8/29/07, Duncan McQueen <dwm...@gm...> wrote:
> > >
> > > It is certainly something to brag about. The more platforms we cover,
> > > the closer we get to world domination :-)
> > >
> > > I've made only a few changes to the patch. First, I've noticed that
> > > Makefile.w32 erroneously used -ldbi twice in the XY_LIBS definitions,
> > > and I've also removed the second one from the SQLITE3_LIBS definition
> > > that your patch added. Second, I've changed the definition of
> > > _POSIX_PATH_MAX to 256. I inserted 512 off the top of my head, but
> > > limits.h on FreeBSD uses 256 which is more likely to be correct.
> > >
> >
> > Sounds good to me.  I was hacking at that Makefile to get it to work
> >
> > > Just to make sure I understand what you're doing. Is it exactly the
> > > same procedure to build Win32 DLLs using MinGW as it is on Cygwin? In
> > > that case I'd like to change a few comments in the Makefiles, readmes,
> > > and other docs which now only talk about Cygwin.
> >
> > Yes, it is the same procedure - at least close.  Under MinGW you must
> > use MSYS (if you use the Makefile.w32) as compare dot the Cygwin
> > shell.  Benefit is - not dependencies on some cygwin dll for runtime.
> >
> > >
> > > Finally, did you try and run "make check"? It'll ask you for a
> > > particular driver and then run a couple of tests with this database
> > > engine. Could you please send me the outputs of this command for each
> > > database engine you use, just to make sure everything works as
> > > intended?
> > >
> >
> > I will run a make check on each one.  I have used the resulting dlls
> > for each of the three (postgresql, mysql and sqlite3) in a basic
> > application with success.  But I can send you the results of a make
> > check.
> >
> > > regards,
> > > Markus
> > >
> > >
> > >  >
> > >  > On 8/28/07, Duncan McQueen <dwm...@gm...> wrote:
> > >  > > On 8/28/07, Markus Hoenicka <mar...@mh...> wrote:
> > >  > > > Quoting Duncan McQueen <dwm...@gm...>:
> > >  > > >
> > >  > > > > Part of the problem may be I am compiling using GCC 4.2.1 - and
> > >  > > > > excessive warning messages seem to be the norm there.  My dbd.h is
> > >  > > > > from CVS as of two days ago.
> > >  > > > >
> > >  > > >
> > >  > > > In that case it might help to manually cast the int variable to const
> > >  > > > int, like this:
> > >  > > >
> > >  > > > _dbd_internal_error_handler(conn, "could not open database", (const
> > >  > > > int) sqlite3_errcode);
> > >  > > >
> > >  > > > Does your GCC like this better?
> > >  > > >
> > >  > > >
> > >  > >
> > >  > > I will check tonight on both of these.
> > >  > >
> > >  > > > > I will look on the POSIX_PATH_MATH and try to add it.  I know I have
> > >  > > > > seen other source where it was defined as you mentioned.
> > >  > > > >
> > >  > > > >> ifndef _POSIX_PATH_MAX
> > >  > > > >> #define _POSIX_PATH_MAX 512
> > >  > > > >> endif
> > >  > > > >>
> > >  > > >
> > >  > > > This should of course read:
> > >  > > >
> > >  > > > #ifndef _POSIX_PATH_MAX
> > >  > > > #define _POSIX_PATH_MAX 512
> > >  > > > #endif
> > >  > > >
> > >  > > > regards,
> > >  > > > Markus
> > >  > > >
> > >  > > > --
> > >  > > > Markus Hoenicka
> > >  > > > mar...@ca...
> > >  > > > (Spam-protected email: replace the quadrupeds with "mhoenicka")
> > >  > > > http://www.mhoenicka.de
> > >  > > >
> > >  > > >
> > >  > > > -------------------------------------------------------------------------
> > >  > > > This SF.net email is sponsored by: Splunk Inc.
> > >  > > > Still grepping through log files to find problems?  Stop.
> > >  > > > Now Search log events and configuration files using AJAX and a browser.
> > >  > > > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > >  > > > _______________________________________________
> > >  > > > libdbi-devel mailing list
> > >  > > > lib...@li...
> > >  > > > https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> > >  > > >
> > >  > >
> > >  > Index: Makefile.w32
> > >  > ===================================================================
> > >  > RCS file: /cvsroot/libdbi-drivers/libdbi-drivers/Makefile.w32,v
> > >  > retrieving revision 1.8
> > >  > diff -u -w -b -i -p -r1.8 Makefile.w32
> > >  > --- Makefile.w32     21 Nov 2005 21:18:15 -0000      1.8
> > >  > +++ Makefile.w32     29 Aug 2007 01:57:01 -0000
> > >  > @@ -39,19 +39,22 @@ MSQL_LIBS = -L /usr/local/lib -L /usr/lo
> > >  >  MYSQL_LIBS = -L /usr/local/lib -ldbi -lmysqlclient -liberty -lz
> > >  >  PGSQL_LIBS = -L /usr/local/lib -ldbi -ldbi -lpq -liberty
> > >  >  SQLITE_LIBS = -L /usr/local/lib -ldbi -ldbi -lsqlite -liberty
> > >  > +SQLITE3_LIBS = -L /usr/local/lib -ldbi -ldbi -lsqlite3 -liberty
> > >  >  driverdir = ${exec_prefix}/lib/dbd
> > >  >
> > >  >  LIBMSQL_DLL_NAME = libdbdmsql.dll
> > >  >  LIBMYSQL_DLL_NAME = libdbdmysql.dll
> > >  >  LIBPGSQL_DLL_NAME = libdbdpgsql.dll
> > >  >  LIBSQLITE_DLL_NAME = libdbdsqlite.dll
> > >  > +LIBSQLITE3_DLL_NAME = libdbdsqlite3.dll
> > >  >
> > >  >  LIBMSQL_DLL_EXP_LIB = libdbdmsql.dll.a
> > >  >  LIBMYSQL_DLL_EXP_LIB = libdbdmysql.dll.a
> > >  >  LIBPGSQL_DLL_EXP_LIB = libdbdpgsql.dll.a
> > >  >  LIBSQLITE_DLL_EXP_LIB = libdbdsqlite.dll.a
> > >  > +LIBSQLITE3_DLL_EXP_LIB = libdbdsqlite3.dll.a
> > >  >
> > >  > -all: libmysql-dll libpgsql-dll libsqlite-dll libmsql-dll
> > >  > +all: libmysql-dll libpgsql-dll libsqlite-dll libsqlite3-dll libmsql-dll
> > >  >
> > >  >  libmsql-dll: $(top_srcdir)/drivers/msql/dbd_msql.o
> > >  >      $(CC) -shared -Wl,--out-implib=$(top_srcdir)/drivers/msql/.libs/$(LIBMSQL_DLL_EXP_LIB) -o $(top_srcdir)/drivers/msql/.libs/$(LIBMSQL_DLL_NAME) -L$(top_srcdir)/src/.libs $(LDFLAGS) $(top_srcdir)/drivers/msql/*.o $(MSQL_LIBS)
> > >  > @@ -65,7 +68,10 @@ libpgsql-dll: $(top_srcdir)/drivers/pgsq
> > >  >  libsqlite-dll: $(top_srcdir)/drivers/sqlite/dbd_sqlite.o
> > >  >      $(CC) -shared -Wl,--out-implib=$(top_srcdir)/drivers/sqlite/.libs/$(LIBSQLITE_DLL_EXP_LIB) -o $(top_srcdir)/drivers/sqlite/.libs/$(LIBSQLITE_DLL_NAME)  $(LDFLAGS) $(top_srcdir)/drivers/sqlite/*.o $(SQLITE_LIBS)
> > >  >
> > >  > -install: install-libmysql install-libpgsql install-libsqlite install-libmsql
> > >  > +libsqlite3-dll: $(top_srcdir)/drivers/sqlite3/dbd_sqlite3.o
> > >  > +    $(CC) -shared -Wl,--out-implib=$(top_srcdir)/drivers/sqlite3/.libs/$(LIBSQLITE3_DLL_EXP_LIB) -o $(top_srcdir)/drivers/sqlite3/.libs/$(LIBSQLITE3_DLL_NAME)  $(LDFLAGS) $(top_srcdir)/drivers/sqlite3/*.o $(SQLITE3_LIBS)
> > >  > +
> > >  > +install: install-libmysql install-libpgsql install-libsqlite install-libsqlite3 install-libmsql
> > >  >
> > >  >  install-libmsql:
> > >  >      cp $(top_srcdir)/drivers/msql/.libs/$(LIBMSQL_DLL_NAME) $(driverdir) && \
> > >  > @@ -83,8 +89,13 @@ install-libsqlite:
> > >  >      cp $(top_srcdir)/drivers/sqlite/.libs/$(LIBSQLITE_DLL_NAME) $(driverdir) && \
> > >  >      cp $(top_srcdir)/drivers/sqlite/.libs/$(LIBSQLITE_DLL_EXP_LIB) $(driverdir)
> > >  >
> > >  > +install-libsqlite3:
> > >  > +    cp $(top_srcdir)/drivers/sqlite3/.libs/$(LIBSQLITE3_DLL_NAME) $(driverdir) && \
> > >  > +    cp $(top_srcdir)/drivers/sqlite3/.libs/$(LIBSQLITE3_DLL_EXP_LIB) $(driverdir)
> > >  > +
> > >  > +
> > >  >
> > >  > -.PHONY: libdbdmysql.dll libdbdpgsql.dll libdbdsqlite.dll libdbdmsql.dll install install-libmysql install-libpgsql install-libsqlite
> > >  > +.PHONY: libdbdmysql.dll libdbdpgsql.dll libdbdsqlite.dll libdbdsqlite3.dll libdbdmsql.dll install install-libmysql install-libpgsql install-libsqlite install-libsqlite3
> > >  >
> > >  >
> > >  >  # Tell versions [3.59,3.63) of GNU make to not export all variables.
> > >  > cvs diff: Diffing debian
> > >  > cvs diff: Diffing doc
> > >  > cvs diff: Diffing doc/include
> > >  > cvs diff: Diffing drivers
> > >  > cvs diff: Diffing drivers/firebird
> > >  > cvs diff: Diffing drivers/freetds
> > >  > cvs diff: Diffing drivers/ingres
> > >  > cvs diff: Diffing drivers/msql
> > >  > cvs diff: Diffing drivers/mysql
> > >  > cvs diff: Diffing drivers/oracle
> > >  > cvs diff: Diffing drivers/pgsql
> > >  > cvs diff: Diffing drivers/sqlite
> > >  > cvs diff: Diffing drivers/sqlite3
> > >  > Index: drivers/sqlite3/dbd_sqlite3.c
> > >  > ===================================================================
> > >  > RCS file: /cvsroot/libdbi-drivers/libdbi-drivers/drivers/sqlite3/dbd_sqlite3.c,v
> > >  > retrieving revision 1.15
> > >  > diff -u -w -b -i -p -r1.15 dbd_sqlite3.c
> > >  > --- drivers/sqlite3/dbd_sqlite3.c    20 Feb 2007 00:00:25 -0000      1.15
> > >  > +++ drivers/sqlite3/dbd_sqlite3.c    29 Aug 2007 01:41:51 -0000
> > >  > @@ -204,11 +204,11 @@ int _real_dbd_connect(dbi_conn_t *conn,
> > >  >         access rights or an existing database is corrupted or created
> > >  >         with an incompatible version */
> > >  >      if (sq_errmsg) {
> > >  > -      _dbd_internal_error_handler(conn, sq_errmsg, sqlite3_errcode);
> > >  > +      _dbd_internal_error_handler(conn, sq_errmsg, (const int) sqlite3_errcode);
> > >  >        free(sq_errmsg);
> > >  >      }
> > >  >      else {
> > >  > -      _dbd_internal_error_handler(conn, "could not open database", sqlite3_errcode);
> > >  > +      _dbd_internal_error_handler(conn, "could not open database", (const int) sqlite3_errcode);
> > >  >      }
> > >  >      return -1;
> > >  >    }
> > >  > @@ -408,7 +408,7 @@ dbi_result_t *dbd_list_dbs(dbi_conn_t *c
> > >  >      }
> > >  >
> > >  >      if (sq_errmsg) {
> > >  > -      _dbd_internal_error_handler(conn, sq_errmsg, retval);
> > >  > +      _dbd_internal_error_handler(conn, sq_errmsg, (const int) retval);
> > >  >        free(sq_errmsg);
> > >  >        break;
> > >  >      }
> > >  > Index: drivers/sqlite3/dbd_sqlite3.h
> > >  > ===================================================================
> > >  > RCS file: /cvsroot/libdbi-drivers/libdbi-drivers/drivers/sqlite3/dbd_sqlite3.h,v
> > >  > retrieving revision 1.1
> > >  > diff -u -w -b -i -p -r1.1 dbd_sqlite3.h
> > >  > --- drivers/sqlite3/dbd_sqlite3.h    29 Apr 2005 20:42:39 -0000      1.1
> > >  > +++ drivers/sqlite3/dbd_sqlite3.h    29 Aug 2007 01:39:41 -0000
> > >  > @@ -33,6 +33,10 @@ enum enum_field_types { FIELD_TYPE_DECIM
> > >  >     other systems use limits like 32 (PostgreSQL) and 64 (MySQL) */
> > >  >  #define MAX_IDENT_LENGTH 128
> > >  >
> > >  > +#ifndef _POSIX_PATH_MAX
> > >
> > >  > +#define _POSIX_PATH_MAX 512
> > >  > +#endif
> > >  > +
> > >  >  #define SQLITE3_RESERVED_WORDS { \
> > >  >      "ACTION", \
> > >  >      "ADD", \
> > > --
> > > Markus Hoenicka
> > > mar...@ca...
> > > (Spam-protected email: replace the quadrupeds with "mhoenicka")
> > > http://www.mhoenicka.de
> > >
> > >
> >
>

[libdbi-devel] Fwd: Compilation of MySQL driver under MingW

[Duncan M. <dwm...@gm...>]

---------- Forwarded message ----------
From: Duncan McQueen <dwm...@gm...>
Date: Aug 28, 2007 8:20 PM
Subject: Re: [libdbi-devel] Compilation of MySQL driver under MingW
To: Markus Hoenicka <mar...@mh...>


Attached is my patch (let me know if it isn't quite correct - made it
using cvs diff).

I had to modify the Makefile.w32 to add sqlite3.  However, I tested
this on a simple application and it worked.  Therefore, we should have
support for sqlite3, mysql, postgres and possibly freetds (if I can
ever test it) native on Windows under MinGW.  This is very exciting
(to me, at least).


On 8/28/07, Duncan McQueen <dwm...@gm...> wrote:
> On 8/28/07, Markus Hoenicka <mar...@mh...> wrote:
> > Quoting Duncan McQueen <dwm...@gm...>:
> >
> > > Part of the problem may be I am compiling using GCC 4.2.1 - and
> > > excessive warning messages seem to be the norm there.  My dbd.h is
> > > from CVS as of two days ago.
> > >
> >
> > In that case it might help to manually cast the int variable to const
> > int, like this:
> >
> > _dbd_internal_error_handler(conn, "could not open database", (const
> > int) sqlite3_errcode);
> >
> > Does your GCC like this better?
> >
> >
>
> I will check tonight on both of these.
>
> > > I will look on the POSIX_PATH_MATH and try to add it.  I know I have
> > > seen other source where it was defined as you mentioned.
> > >
> > >> ifndef _POSIX_PATH_MAX
> > >> #define _POSIX_PATH_MAX 512
> > >> endif
> > >>
> >
> > This should of course read:
> >
> > #ifndef _POSIX_PATH_MAX
> > #define _POSIX_PATH_MAX 512
> > #endif
> >
> > regards,
> > Markus
> >
> > --
> > Markus Hoenicka
> > mar...@ca...
> > (Spam-protected email: replace the quadrupeds with "mhoenicka")
> > http://www.mhoenicka.de
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >>  http://get.splunk.com/
> > _______________________________________________
> > libdbi-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libdbi-devel
> >
>