Re: [gnome-db] Problem with sqlite provider in 4.0.1

Murray Cumming <[email protected]>
Newsgroups gmane.comp.gnome.db
Message-ID <1239909082.7962.3.camel@murrayc-x61>
On Thu, 2009-04-16 at 14:17 -0400, Joe Marcus Clarke wrote:
> I wonder how the libgda sqlite provider works on Linux.  On FreeBSD, we
> are currently building it with the system sqlite3, but this appears to
> be broken.

Don't do that. If there's some easy way to do that in the libgda build
system then it should be removed. It breaks things.

>   The code assumes an older version of the libgda-column API.
> See this excerpt from gda-sqlite-provider.c:
> 
>                         gda_column_set_description (0, "name");
>                         gda_column_set_name (0, "name");
>                         gda_column_set_g_type (0, G_TYPE_STRING);
>                         gda_column_set_description (1, "nargs");
>                         gda_column_set_name (1, "nargs");
>                         gda_column_set_g_type (1, G_TYPE_INT);
>                         gda_column_set_description (2, "specificname");
>                         gda_column_set_name (2, "specificname");
>                         gda_column_set_g_type (2, G_TYPE_STRING);
> 
> That code triggers a segmentation fault in libgda when executed as 0x1
> is an invalid memory address (i.e., not a GdaColumn).  However, if we
> build libgda using the built-in sqlite, the problem is not seen.
> 
> I'm wondering what is the preferred way to build libgda, and if Linux is
> currently using the embedded sqlite, or somehow working around this API
> mismatch problem.  Thanks.
> 
> Joe
> 
> _______________________________________________
> gnome-db-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-db-list
-- 
Murray Cumming
[email protected]
www.murrayc.com
www.openismus.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.