libdbi-devel

[libdbi-devel] Compilation of MySQL driver under MingW

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

I was able to successfully compile the MySQL driver under MinGW.

All that is needed is an include of winsock.h in the dbd_mysql.c file
at the top.

I did it like this:

#ifdef __MINGW32__
#include <winsock.h>
#endif

However, could a similar change be committed to the code?  This will
allow the MinGW platform to compile this driver.

Thanks,

Duncan McQueen

[libdbi-devel] Compilation of MySQL driver under MingW

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

Hi Duncan,

Duncan McQueen writes:
 > #ifdef __MINGW32__
 > #include <winsock.h>
 > #endif
 > 
 > However, could a similar change be committed to the code?  This will
 > allow the MinGW platform to compile this driver.
 > 

I've committed the fix you suggested. It can't do any harm on other
systems, so if that's all it takes to make the driver work on MinGW
we're all done.

I wasn't quite sure where to put the above lines though. According to
your compiler log the file must be included before mysql.h, but does
winsock.h itself have any dependencies? I've put the conditional in
front of all includes, hoping that there are no such
dependencies. Could you please check the version from the CVS
repository to make sure it works?

BTW I recall you compiled the PostgreSQL driver without a hitch. Is
there any chance to test the sqlite/sqlite3 drivers as well? I reckon this
should not be too hard as sqlite/sqlite3 also compile as Win32
apps. With these drivers being ok we could claim full MinGW support
for the core drivers.

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

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

As mentioned off list, I will test out sqlite.

At the current time, I still haven't gotten the freetds driver to
work.  I have been able to successfully compile the driver by doing
the following:

- Changed call of bzero() function to ZeroMemory
- Uncommented calls of fprintf in dbd_connect() function.

However, as I understand it, FreeTDS will not connect to SQL Server
2005 Express (the version I have).

Anyone have SQL Server 2000 and could test it out?

Thanks,

Duncan

On 7/16/07, Markus Hoenicka <mar...@mh...> wrote:
> Hi Duncan,
>
> Duncan McQueen writes:
>  > #ifdef __MINGW32__
>  > #include <winsock.h>
>  > #endif
>  >
>  > However, could a similar change be committed to the code?  This will
>  > allow the MinGW platform to compile this driver.
>  >
>
> I've committed the fix you suggested. It can't do any harm on other
> systems, so if that's all it takes to make the driver work on MinGW
> we're all done.
>
> I wasn't quite sure where to put the above lines though. According to
> your compiler log the file must be included before mysql.h, but does
> winsock.h itself have any dependencies? I've put the conditional in
> front of all includes, hoping that there are no such
> dependencies. Could you please check the version from the CVS
> repository to make sure it works?
>
> BTW I recall you compiled the PostgreSQL driver without a hitch. Is
> there any chance to test the sqlite/sqlite3 drivers as well? I reckon this
> should not be too hard as sqlite/sqlite3 also compile as Win32
> apps. With these drivers being ok we could claim full MinGW support
> for the core drivers.
>
> 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

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

Has OPenJade always been required for a compile?  I get errors related
to it on my MinGW platform - is there a way to ignore it?

On 7/13/07, Duncan McQueen <dwm...@gm...> wrote:
> I was able to successfully compile the MySQL driver under MinGW.
>
> All that is needed is an include of winsock.h in the dbd_mysql.c file
> at the top.
>
> I did it like this:
>
> #ifdef __MINGW32__
> #include <winsock.h>
> #endif
>
> However, could a similar change be committed to the code?  This will
> allow the MinGW platform to compile this driver.
>
> Thanks,
>
> Duncan McQueen
>

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

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

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

> Has OPenJade always been required for a compile?  I get errors related
> to it on my MinGW platform - is there a way to ignore it?
>

A hard dependency on OpenJade is not intended, but this seems to fail  
on some platforms. OpenJade is required to build the documentation  
from the SGML sources. However, the built docs are included in the  
source tarball, so there should be no need to build them again. If  
that fails, pass "--disable-docs" to ./configure. Then make should not  
attempt to build the docs.

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

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

Are there any good examples showing proper use of catching an error
from the database driver?  As I mentioned - my MinGW compiled program
really blows up when the database doesn't exist - I am just looking
for a basic example as to catching the error.

Thanks!

On 8/26/07, Duncan McQueen <dwm...@gm...> wrote:
> Has OPenJade always been required for a compile?  I get errors related
> to it on my MinGW platform - is there a way to ignore it?
>
> On 7/13/07, Duncan McQueen <dwm...@gm...> wrote:
> > I was able to successfully compile the MySQL driver under MinGW.
> >
> > All that is needed is an include of winsock.h in the dbd_mysql.c file
> > at the top.
> >
> > I did it like this:
> >
> > #ifdef __MINGW32__
> > #include <winsock.h>
> > #endif
> >
> > However, could a similar change be committed to the code?  This will
> > allow the MinGW platform to compile this driver.
> >
> > Thanks,
> >
> > Duncan McQueen
> >
>

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

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

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

> Are there any good examples showing proper use of catching an error
> from the database driver?  As I mentioned - my MinGW compiled program
> really blows up when the database doesn't exist - I am just looking
> for a basic example as to catching the error.
>

These are probably not "good" examples, but still:

1) look at the libdbi-drivers/tests/test_dbi.c test program which  
handles a couple of errors gracefully

2) this is what my other pet project uses to connect to a database  
(look for connect_to_db()):
http://refdb.svn.sourceforge.net/viewvc/refdb/refdb/trunk/src/refdbda.c?revision=461&view=markup

hth

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

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

On sqlite - I am trying to find a source package that includes
sqlite.h.  The package I donloaded and compiled only had sqlite3.h

The libdbi driver fails to compile because it can't find sqlite.h


On 7/16/07, Markus Hoenicka <mar...@mh...> wrote:
> Hi Duncan,
>
> Duncan McQueen writes:
>  > #ifdef __MINGW32__
>  > #include <winsock.h>
>  > #endif
>  >
>  > However, could a similar change be committed to the code?  This will
>  > allow the MinGW platform to compile this driver.
>  >
>
> I've committed the fix you suggested. It can't do any harm on other
> systems, so if that's all it takes to make the driver work on MinGW
> we're all done.
>
> I wasn't quite sure where to put the above lines though. According to
> your compiler log the file must be included before mysql.h, but does
> winsock.h itself have any dependencies? I've put the conditional in
> front of all includes, hoping that there are no such
> dependencies. Could you please check the version from the CVS
> repository to make sure it works?
>
> BTW I recall you compiled the PostgreSQL driver without a hitch. Is
> there any chance to test the sqlite/sqlite3 drivers as well? I reckon this
> should not be too hard as sqlite/sqlite3 also compile as Win32
> apps. With these drivers being ok we could claim full MinGW support
> for the core drivers.
>
> 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...>:

> On sqlite - I am trying to find a source package that includes
> sqlite.h.  The package I donloaded and compiled only had sqlite3.h
>
> The libdbi driver fails to compile because it can't find sqlite.h
>
>

There are two series of sqlite and hence two different drivers. SQLite  
2.8.x uses sqlite.h (and the command line app sqlite), whereas SQLite  
3.x uses sqlite3.h (and sqlite3). Unless you have specific reasons to  
support legacy apps you should go for sqlite3 and build the sqlite3  
driver only.

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...>:

> Is there a way to tell libdbi-drivers to use sqlite3.h - I get an
> error on compilation because it can't find it (even though sqlite3.h
> exists).
>

What is the exact ./configure command line you are using? In fact, if  
sqlite3.h is not where it should be, configure should issue an error  
saying it can't find the include file. configure has various options  
to make libraries and headers available to the build system (all of  
these of course translate to appropriate -I and -L gcc arguments). If  
your build system can't find the header, try fiddling with  
--with-sqlite3-incdir first. If that does not help, I'd need more info  
about your system, like directory layout and the exact error messages  
you're getting.

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

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

Well,  I still get an error when compiling the sqlite3 driver under MinGW:

dbd_sqlite3.c: In function '_real_dbd_connect':
dbd_sqlite3.c:207: warning: passing argument 3 of
'_dbd_internal_error_handler' makes pointer from integer without a
cast
dbd_sqlite3.c:211: warning: passing argument 3 of
'_dbd_internal_error_handler' makes pointer from integer without a
cast
dbd_sqlite3.c: In function 'dbd_list_dbs':
dbd_sqlite3.c:331: error: '_POSIX_PATH_MAX' undeclared (first use in
this function)
dbd_sqlite3.c:331: error: (Each undeclared identifier is reported only once
dbd_sqlite3.c:331: error: for each function it appears in.)
dbd_sqlite3.c:411: warning: passing argument 3 of
'_dbd_internal_error_handler' makes pointer from integer without a
cast
make[3]: *** [dbd_sqlite3.lo] Error 1
make[3]: Leaving directory `/home/Test/libdbi-drivers/drivers/sqlite3'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/Test/libdbi-drivers/drivers'
make[1]:

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

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

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

> Well,  I still get an error when compiling the sqlite3 driver under MinGW:
>
> dbd_sqlite3.c: In function '_real_dbd_connect':
> dbd_sqlite3.c:207: warning: passing argument 3 of
> '_dbd_internal_error_handler' makes pointer from integer without a
> cast

I don't know what to make of these warnings. On my system I see the followin=
g:

$ grep _dbd_internal_error_handler /usr/local/include/dbi/*
/usr/local/include/dbi/dbd.h:void =20
_dbd_internal_error_handler(dbi_conn_t *conn,
const char *errmsg, const int errno);

argument 3 is declared as

int sqlite3_errcode;

so I don't see what's wrong here. Do you have an old version of dbd.h =20
in your include path somewhere (/usr/include/dbi/)?

> dbd_sqlite3.c:331: error: '_POSIX_PATH_MAX' undeclared (first use in
> this function)

Apparently the MinGW version of limits.h does not define this =20
constant. Could you please check whether any other include file does? =20
You'd have to include that in addition to limits.h then.

If not, try adding something like this to the top of dbd_sqlite.c:

ifndef _POSIX_PATH_MAX
#define _POSIX_PATH_MAX 512
endif

If you get it to work, please send me a diff so I can fix these =20
problems in the CVS code.

regards,
Markus



--=20
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

[Duncan M. <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.

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.

On 8/28/07, Markus Hoenicka <mar...@mh...> wrote:
> Quoting Duncan McQueen <dwm...@gm...>:
>
> > Well,  I still get an error when compiling the sqlite3 driver under MinGW:
> >
> > dbd_sqlite3.c: In function '_real_dbd_connect':
> > dbd_sqlite3.c:207: warning: passing argument 3 of
> > '_dbd_internal_error_handler' makes pointer from integer without a
> > cast
>
> I don't know what to make of these warnings. On my system I see the following:
>
> $ grep _dbd_internal_error_handler /usr/local/include/dbi/*
> /usr/local/include/dbi/dbd.h:void
> _dbd_internal_error_handler(dbi_conn_t *conn,
> const char *errmsg, const int errno);
>
> argument 3 is declared as
>
> int sqlite3_errcode;
>
> so I don't see what's wrong here. Do you have an old version of dbd.h
> in your include path somewhere (/usr/include/dbi/)?
>
>
> > dbd_sqlite3.c:331: error: '_POSIX_PATH_MAX' undeclared (first use in
> > this function)
>
> Apparently the MinGW version of limits.h does not define this
> constant. Could you please check whether any other include file does?
> You'd have to include that in addition to limits.h then.
>
> If not, try adding something like this to the top of dbd_sqlite.c:
>
> ifndef _POSIX_PATH_MAX
> #define _POSIX_PATH_MAX 512
> endif
>
> If you get it to work, please send me a diff so I can fix these
> problems in the CVS code.
>
> 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
>

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

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

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 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

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

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

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
>

[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
> >
>

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
> > >
> > >
> >
>

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