"entry point offerings" = C API (I just got creative on how I articulated this)
Here is the deal.... or maybe should I say architecture.... Business app talks to -> mono -> mono (ado.net adapter) -> native lib via interop My app targets 2.0 mono for all platforms. I am using the (http://sqlite.phxsoftware.com/) sqlite ado.net provider for both windows and linux. Originally I messed up and linked up the all inclusive lib with this thing to my business app. Then I realized I needed to run the all "managed" ado.net provider. All fine and good. I then run my app on windows and have no issues with this entry point not being found on windows. It just works happily. As advertised, I move my code over to Ubutu 8.10 and the .NET mono runtime complains about the missing entry point in the sqlite library that loaded up. So I go and download the latest sqlite 3 code. That gets me to the entry point offering missing that you are helping me with. You then tell me to go define that symbol in my c source file.... I do recompile, reinstall (sudo make install), boom..... the problem still occurs. (although I still need to check that the entry point actually was compiled in still) I go through my entire linux system to find where ALL shared sqlite3 libs are located. I am thinking, let me remove all the old ones (although dangerous.. or do you guys keep ordinal order in your sqlite dll to keep backwards compability?) and just make sure my /usr/lib has my newly built. I do this and still get the problem. I start thinking... why am I using the latest sqlite binaries on both platforms but one has this dllimport (api offering) but linux does not by default. Why have the sqlite guys not compiled with the same flags with this api feature on both platforms. So I thought, I better notify them of this. I also thought I would write the mono guys to. I figure, maybe the groups will make the same code at the .NET managed level run the same on all platforms via releasong compiled code that had the same defines on the c side. I just personally thought it was ambiguous for you guys to be releasing the same version lib that works differently just because of platform? I thought the ado.net guys should know as well so they might post information about this potential snafu! From my humble opinion, it would be nice from the business apps dev perspective if the code you wrote that worked on mono windows worked the same on linux with no crazy library fun like I am having to do right now. Sure, having knowledge is one thing, but having to use the vastness of mine detracts from time I need to be using building apps to help sqlite, ado.net sqlite, and mono look awesome by releasing more apps on their technology. At this point I am curious why you guys release a different lib of the same version with different features for each given platform? And yeah.. I do get the tech... working on compilers (specifically C/C++) will help you with tech realization at all levels! : - ) But you adding that in is VERY helpful, it cuts the ambiguity in your communication. Allan > Date: Sun, 8 Feb 2009 14:34:17 -0800 > From: [email protected] > To: [email protected] > Subject: Re: [sqlite] Question on missing Entry Point for Sqlite 3 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W Allan Edwards wrote: > > I find it odd you have different expected behavior for the same code on > > each different platform. > > What specifically are you referring to there? > > > 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. > > The point you are missing is that the the provider speaks to a native > code shared library. The provider code will behave identically but the > shared library is native code and could have been compiled many > different ways. Your underlying issue is solely because the Windows > SQLite dll has compilation flags set such that the symbol is present and > Linux such that it is not. > > > 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. > > This has nothing to do with behaviour. Your error message is due to a > runtime linking error. The mono code is using GetProcAddress/dlsym > trying to find a symbol in the native code DLL and failing on Linux. > > > 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?) > > The SQLite *source code* includes the functionality. For the shared > library to include the functionality (and symbol) compile time flags > have to be set. http://www.sqlite.org/compile.html The page I > originally pointed you at makes it quite clear - > http://www.sqlite.org/c3ref/column_database_name.html > > > 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. > > The SQLite shared library is unmanaged code. It will have whatever > functionality it was compiled with. The shared library is not cross > platform because it talks to native operating system functionality. You > cannot use the Windows shared library on MacOS or the MacOS one on > Linux, or the Linux one on Windows etc. > > > So does the sqlite team have different entry point offerings for each > > platform of the same sqlite database version? > > SQLite doesn't have "entry point offerings" whatever you think that > means. The SQLite library has numerous functions, structures and > defined constants in the C programming language as defined in the > documentation at http://sqlite.org/c3ref/intro.html When producing the > compiled library you can include and exclude parts of the API as defined > in http://www.sqlite.org/compile.html > > Your mono adapter is assuming that sqlite3_column_database_name and > friends are present in the shared library and gets the error you saw if > not. The Windows DLL downloaded from sqlite.org does include it by > default while other compilations don't by default. But whoever compiles > SQLite can set it to whatever they want. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkmPXeYACgkQmOOfHg372QTt3gCfehn6afkcW1+lUbfSXi+wS39T > ft8AoJIof7r8nTAoAU9SIDxAEVkhxDgP > =xoEq > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
