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

["Vivien Malerba" <vmalerba gmail com>]

On 4/3/07, Brecht Sanders <brecht sanders org> wrote:
> > > 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.

Aren't we all sometimes!

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

This is an ongoing problem, because SQLite does not export enough
information about its database structure, so now as a temporary
solution, the SQLite code is embedded which allows libgda to access
the internals of the database. However I'm working on improving SQLite
on that point, and then it'll be possible to use the SQLite version
installed on your box.

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

Try to use the current SVN version, this problem has been corrected.

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

No, there is not, the paths to the providers' directory, or to the
config or ressources files are hard-coded at compile time (based on
the --prefix specified when configuring).

Of course it would be possible to test for the existence of a global
GDA_HOME or similar environment variable and use it as a if that was
specified as the --prefix spec.

Another possibility would be to borrow some code from the autopackage
project which make it possible to discover at runtime the real
directory from which the applications are run, and then automatically
adjust the directories. This would have the side effect of making the
whole thing relocatable transparently.

What do you think?

> > * 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-author-dict-file-3.0 -p SQLite -c
"DB_DIR=/path/to/dir;DB_NAME=my_db" -o dict.xml
will create a dict.xml file for the database located at /path/to/dir/my_db.db

> > * gda-list-config can list the configured data sources
>
> Same as gda-diagnose

Yes, this is a general problem you'll have with all the programs using libgda.

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

Yes, as several parts of libgda could make use of the same buffer
which would result in an erratic behaviour.

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

Ok.

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

Ok.

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

Thanks,

Vivien