I am about to COFF this ELF out man!!!! By preprocessor do you mean #define? I did a search in my sqlite.c file for
SQLITE_ENABLE_COLUMN_METADATA.. then I #defined above them ALL! Instead of telling me this was incorrect... why not tell me what your approach might be? I have a feeling it would have something do with the .configure fun file? > Date: Sun, 8 Feb 2009 18:10:19 -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: > > 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 _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
