Re: [gnome-db] Windows binaries issues

[Vivien Malerba <vmalerba gmail com>]

2009/3/3 Armin Burgmeier <armin arbur net>

- Show quoted text -

On Mon, 2009-03-02 at 18:44 +0100, Vivien Malerba wrote:
>
>
> 2009/3/2 Armin Burgmeier <armin arbur net>
>
>         On Mon, 2009-03-02 at 15:24 +0100, Vivien Malerba wrote:
>         >
>         >
>         > 2009/3/2 Armin Burgmeier <armin arbur net>
>         >         I tried building the latest Glom with the libgda-4
>         windows
>         >         binaries for
>         >         libgda 3.99.12 on
>         >
>         ftp://ftp.gnome.org/pub/GNOME/binaries/win32/libgda/3.99.
>         >
>         >         These files seem to be missing from the -dev
>         package:
>         >
>         >          * gda-binreloc.h
>         >          * gda-error.h
>         >
>         >         Furthermore, the libgda DLL (or the import library)
>         does not
>         >         seem to
>         >         export these functions:
>         >
>         >          * gda_data_model_error_get_type
>         >          * gda_utility_data_model_find_column_description
>         >
>         > Ok, I'll correct that in the next version (if you want them
>         before, I
>         > can rebuild the ZIP files for 3.99.12, just tell me).
>
>
>         Thanks. I can wait for the next release. I copied the headers
>         from the
>         source tarball, and commented out the functions in pygda which
>         require
>         the non-exported libgda functions.
>
>         Using the libgda DLL additionally requires libdb47.dll (bdb).
>         I think
>         this is because GdaDataModelBdb is in the core libgda DLL, not
>         in the
>         BDB provider. Is there a reason for this?
>
> Yes, GdaDataModelBdb is in Libgda because it is meant to be subclassed
> to be adapted to the actual data being stored in each BDB file. I
> understand your concern about linking with the libdb.dll (or .so) even
> though it is not actually used if no BDB file is accessed, and mabe I
> can try to load it only when needed (using GModule).

That would be nice if it's not too much effort. But I can simply ship
libdb47.dll with the Glom installer as well, so it's not a major problem
if it stays as is.

This is now done in SVN trunk rev #3341 (libdb is loaded only when needed):
 $ ldd ./libgda-4.0.so.4.0.0
    linux-gate.so.1 =>  (0xb80d2000)
    libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0xb7f48000)
    librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f3f000)
    libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7e02000)
    libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb7d9a000)
    libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7d5c000)
    libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb7d57000)
    libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7ca0000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7c86000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b28000)
    /lib/ld-linux.so.2 (0x4a2d0000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7b24000)
    libz.so.1 => /usr/lib/libz.so.1 (0xb7b0e000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ae8000)
    libselinux.so.1 => /lib/libselinux.so.1 (0xb7ace000)
    libpcre.so.3 => /lib/libpcre.so.3 (0xb7aa3000)

Cheers,

Vivien