Re: [gnome-db] Compiling libgda on win32 with MinGW/MSYS

[Brecht Sanders <brecht sanders org>]

> > Hi,
> > I have continued my attempts to get libgda to compile for the win32
platform
> > with MinGW/MSYS.
> > This time I had some success, though I haven't been able to do any
testing
> > yet nor did I include much of the database providers yet.
> > But I got libgda (tarball 2.99.5) compiled, linked and installed.
>
> Great!

Sorry I hadn't responded for a while, it was extremely busy for a while.

But during the gaps where I found some time I did continue the effords
to port to native win32.
Now I'm at the stage where I successfully compile, link and install
libgda with the following db providers:
- mysql
- pgsql
- freetds
- firebird
- oracle
- sqlite3 (embedded)
For the support for sqlite3 ./configure says "yes (embedded)".
How can I tell ./configure to use the sqlite3 that I already have on my
system?
There is no parameter mentioned in ./configure --help.

> > ...
> > Like I said I haven't actually tested the results.
> > How can I run tests? I see there is a testing directory with
executables. Do
> > they need certain parameters and/or databases in order to actually
run
> > tests?
>
>
> You can run "make check" which will compile what's in the "tests" dir
> and execute unit tests (I need to add more unit tests there as there
> are currently only query parsing tests).

I get an error on "make check" saying PATH_TO_TEST_XML is not declared.
Where should this point to?

if gcc -DPACKAGE_NAME=\"GNU\ Data\ Access\" -DPACKAGE_TARNAME=\"libgda\"
-DPACKAGE_VERSION=\"2.99.6\" -DPACKAGE_STRING=\"GNU\ Data\ Access\
2.99.6\" -DPACKAGE_BUGREPORT=\"gnome-db-list gnome org\"
-DBONOBO_EXPLICIT_TRANSLATION_DOMAIN=\"libgda-3.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DYYTEXT_POINTER=1 -DGETTEXT_PACKAGE=\"libgda-3.0\" -DHAVE_LOCALE_H=1
-DHAVE_BIND_TEXTDOMAIN_CODESET=1 -DHAVE_GETTEXT=1 -DHAVE_DCGETTEXT=1
-DENABLE_NLS=1 -DHAVE_ODBC=1 -DHAVE_MYSQL=1 -DHAVE_POSTGRES=1
-DHAVE_FREETDS=1 -DFREETDS_VERSION_MAJOR=0 -DFREETDS_VERSION_MINOR=64
-DHAVE_ORACLE=1 -DHAVE_FIREBIRD=1 -DHAVE_XBASE=1 -I. -I.  -I.. -I..
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/usr/include/libxml2 -I/usr/include   -DCHECK_XML_FILES=\"".."\"
-DLIBGDA_WIN32 -I/usr/include/glib-2.0 -I/usr/include/mysql
-I/usr/include/oracle -Duint=guint -MT check_delimiter-check_delimiter.o
-MD -MP -MF ".deps/check_delimiter-check_delimiter.Tpo" -c -o
check_delimiter-check_delimiter.o `test -f 'check_delimiter.c' || echo
'./'`check_delimiter.c; \
then mv -f ".deps/check_delimiter-check_delimiter.Tpo"
".deps/check_delimiter-check_delimiter.Po"; else rm -f
".deps/check_delimiter-check_delimiter.Tpo"; exit 1; fi
check_delimiter.c: In function `main':
check_delimiter.c:90: error: `PATH_TO_TEST_XML' undeclared (first use in
this function)
check_delimiter.c:90: error: (Each undeclared identifier is reported
only once
check_delimiter.c:90: error: for each function it appears in.)
make[2]: *** [check_delimiter-check_delimiter.o] Error 1
make[2]: Leaving directory `/home/BSAEUOPER/libgda-2.99.6/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/home/BSAEUOPER/libgda-2.99.6/tests'
make: *** [check-recursive] Error 1

> You can also use the programs in the "tools" directory:
> * gda-diagnose will produce HTML about a lot of things (this is
> probably the first one you want to try)

Here I get an error popup: "Gda-ERROR **: Error opening directory
'......../lib/libgda-3.0/providers': No such file or directory
aborting..."
This is probably because I install to a temporary location before
packaging the Windows version, and then install it to the final
location.
I do this because on Windows you can't assume the exact absolute
location at compile time.
Is there any way to tell libgda where to look for its providers?

> * gda-author-dict-file can generate a .XML dictionary file for a
connection

Can you give me an example of a command line (e.g. for sqlite) on how to
run this exactly?

> * gda-list-config can list the configured data sources

Same as gda-diagnose

> To run the tests, you'll need to have some database servers (MySQL,
> PostgreSQL, Oracle, or SQLite file). I can send you a nice SQLite file

> to start with if you want.

That would be really nice of you.

> > Can the solutions to the issues above be incorporated in libgda?
> > I'm sure at least the strtok_r and mkstemp ones are easy to fix.
>
> Those one can go as-is into libgda, yes.

I just read that on Windows strtok() is multithreading-safe, i.e. it
uses only one buffer pointer per thread.
However it's not stateless. I'm not entirely certain what that means,
but I guess it means inside the same thread it will still have data in
the buffer from the last call. Would that be an issue?

> > The glib-mkenums --fprod issue could be a glib2 problem, I'm not
sure.
> > Finally there are the problems with library related files in win32.
>
> Can you send a message on the gtk-devel mailing list about that
> (gtk-app-devel-list gnome org)? If no solution is found, then you
> should file a bug report in bugzilla.

If I find some time to determine what goes wrong where I will report it.

Anyway, I tried with the newer version of glib2 (2.13.0) and it's still
the same.

> > What was the goal of the win32 directory?
>
> I have no idea...
>
>
> > Can I tell the configure/make process not to use this?
>
> Sure, remove the win32 line from the SUBDIRS definition in Makefile.am

> (or in the Makefile file).

I didn't touch it and with the latest tarball it all works fine.

> > One more question. I tried to get the latest SVN version and build
that, but
> > since there is no configure I could not do this. I assume the
autoconf
> > should generate those files but it just seems to choke.
>
> Yes, the configure file is generated by the autotools. If you have
> problems, I can send you mine (for the latest SVN version).

That would be great. Because if I can work on the latest SVN version
it's easier for all of us when I make patches.

> > Is there another way I could approach this?
>
> You could install the autotools in your environment and call the
> autotools programs such as aclocal, autoheader, autoconf and automake.

>
>
> > Thanks
> >     Brecht Sanders
>
> Thanks a lot for your time and work. I'd really like to have
> Libgda/Libgnomedb on Windows...

Me too ;-)