-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W Allan Edwards wrote: > You then tell me to go define that symbol in my c source file....
No. You have to have it defined when compiling SQLite. Defining it elsewhere such as your C source will have no effect. It affects the compilation of SQLite only. > I do recompile, reinstall (sudo make install), How exactly are your ensuring that SQLITE_ENABLE_COLUMN_METADATA is defined for the SQLite compilation? > (although I still need to check that the entry point actually > was compiled in still) I already explained how to do that using 'nm --external-only' > or do you guys keep ordinal order in your sqlite dll to keep backwards > compability?) Linking by ordinal is a Windows+COFF thing. Linux uses ELF - http://en.wikipedia.org/wiki/Executable_and_Linkable_Format Versioning is done by the shared library file name. If you look in /usr/lib and other locations you can see how the versioning is done. Use a long listing and you'll also see symbolic links. > why am I using the latest sqlite binaries on both platforms but one has > this dllimport (api offering) but linux does not by default. I have already explained that several times. > Why have the sqlite guys not compiled with the same flags with this api feature on both platforms. The "SQLite guys" did not compile the DLL for your Linux platform. Linux distributions pick the SQLite version and flags, and they produce the shared library. It does so happen that configure doesn't have the flag enabled by default and that was reported as http://www.sqlite.org/cvstrac/tktview?tn=3635 but it is no big deal. This functionality is optional. That is why you have to define a preprocessor flag in order to get it. > So I thought, I better notify them of this. There are exactly two things that will solve your problem: 1 - The mono bindings that you use gracefully accepting that the symbols may not be in the shared library they are using and handling as appropriate. This is easy to do because the missing symbols are detected as an exception. 2 - The SQLite DLL that you are using having SQLITE_ENABLE_COLUMN_METADATA defined during its compilation. No amount of whining will change that. > 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. SQLite works just fine the same way with the same defines. This is not and never has been a SQLite issue. There is no need for the SQLite team to do anything. > I just personally thought it was ambiguous for you guys to be releasing the same version lib > that works differently just because of platform? SQLite does not do that. SQLite behaves exactly the same with the same defines. I realise you find it hard to believe you aren't the only user of SQLite, but there are many many others. The defines are present so that they can customise the functionality present for their intended use. For example SQLite is used in some MP3 players that have very little RAM. Consequently they exclude all the functionality they aren't using. Heck some people even exclude the ability to parse SQL (prepared queries are stored in the database). Others do the opposite and include lots more stuff and bump various numbers a lot higher. > 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 It does work the same. If you require that SQLite be compiled with a certain set of flags (just as your mono bindings currently require that the library be compiled with SQLITE_ENABLE_COLUMN_METADATA) then the best approach is to provide the library tailored just the way you want it. Or report a bug to whoever does your bindings and ask them to deal with the situation appropriately. You keep talking about the code "working the same". The code does work the same. The issue you are having is the bindings complaining about a missing symbol. No SQLite code is invoked for a missing symbol - there is no difference in the SQLite code. The issue is in your bindings. > 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. SQLite is already awesome. > At this point I am curious why you guys release a different lib of the > same version with different features for each given platform? "SQLite guys" did not do this. SQLite is the same for all platforms. Whoever compiles the library can choose to include or exclude functionality as appropriate to their platform. On Windows it just so happens that SQLITE_ENABLE_COLUMN_METADATA is something that is included and the Linux packagers (who are in no way "SQLite guys") decided not to include that. > 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. I have no idea what means. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmPkIcACgkQmOOfHg372QQAgACeOkT7OE7gdCABNxRBZTowFTLh R4UAnRxpnCkj8X+ShsDHhyyiDVhmgSeK =Z2LE -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
