I actually forwarded this to the mono and ado.net mono providers group. I find it odd you have different expected behavior for the same code on each different platform. The windows version works great... when I move the "same" code over to the mono runtime (of the same version) on linux... it has this exception.
Roger, obviously you know what you are doing but your technical fix is not the entire answer. Between sqlite, mono, and the mono ado.net sqlite adapter group, you would think that behavior for the same versioned libs would be the same across Windows, Linux, and MacOS. As you know, working on a code base for a long time gives you the ability to give quick answers. I am hoping the other groups will come back and give the quick answer since they wrote the code. In other words.... I am not sure it is your groups problem? Here are some questions... Does the windows compilation of sqlite 3 (latest source include this entry point?) Does the linux compliation of sqlite 3 (latest source include this entry point?) If I use the same ADO.NET "managed" librarys from the ADO.NET provider group (that provides the adapter in mono) and it works fine on windows, why does the same .NET code not work on Linux with no modification or recompile? I am literally using the SAME managed library from the ADO.nET group. That would for sure indicate an entry point missing on my linux build of sqlite? So does the sqlite team have different entry point offerings for each platform of the same sqlite database version? Allan > Date: Sun, 8 Feb 2009 13:24:32 -0800 > From: rog...@rogerbinns.com > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Question on missing Entry Point for Sqlite 3 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W Allan Edwards wrote: > > What is interesting is that on windows the same managed provider works fine > > (sqlite). But on linux I receive this error. > > That is because the Windows SQLite DLL is compiled by the SQLite team > with SQLITE_ENABLE_COLUMN_METADATA turned on. > > > I flipped the switch on the define you mentioned and rebuilt sqlite on > > linux and this did not fix the problem. > > Then you didn't do it right :-) You can check using 'nm --extern-only' > on the resulting .so you built to see if sqlite3_column_origin_name is > defined. I have no idea how mono picks up shared libraries but it may > not be picking up the one you defined. > > > Would it be true that the same development experience should occur on both > > linux, windows, and macosx if you are using the same versions of the same > > tools? > > Depends on the tool. There are some platform differences such as the > maximum length of pathnames and how SQLite deals with that. If you are > doing aggressive threading then threads will be activated in different > orders. If errors happen at the operating system level then the codes > reported by SQLite may differ slightly. Those are all rare occurrences. > Doing good old fashioned SQL will give you identical results across all > platforms with SQLite. It is fine for developers to use whatever their > platform of choice is and worry about the other platforms a lot later in > the development process for the SQLite side of your project. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmPTYsACgkQmOOfHg372QSdjQCgwtQDIZpeecaViJqwZOS1PVoZ > w84AoIz2V8szjGMMM1dvB+YDqkMcHvUm > =exHe > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
