This API is available in SQLite only if you compile with SQLITE_ENABLE_COLUMN_METADATA defined. Obviously you don't compile with this option and don't need it, so just remove these function names from .def file.
Pavel On Thu, Dec 17, 2009 at 10:30 AM, Kurt D. Knudsen <kknud...@zystemsgo.com> wrote: > Yeah, seems to be giving me odd Linker errors now. I'm stumped. The .def file > is in the project's folder and is referenced in the properties page. When I > compile SQLite3, I get the following: > > 1>Compiling... > 1>sqlite3.c > 1>Linking... > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_database_name > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_database_name16 > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_origin_name > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_origin_name16 > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_table_name > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_column_table_name16 > 1>sqlite3.def : error LNK2001: unresolved external symbol > sqlite3_table_column_metadata > 1>D:\SQLite\Release\sqlite3.lib : fatal error LNK1120: 7 unresolved externals > 1>Build log was saved at "file://d:\SQLite\sqlite\Release\BuildLog.htm" > 1>sqlite3 - 8 error(s), 0 warning(s) > ========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ========== > > Any ideas? > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Kurt D. Knudsen > Sent: Thursday, December 17, 2009 10:19 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Compiling SQLite as .lib increases projectsizeandbuild > time? > > Hi Pavel, > > I think that's the issue. The .def file was never included. I put the .def > file in the sqlite's project folder and am getting linker errors when I > compile. I probably didn't reference it properly, I'll report back in a few > minutes with success or failure. > > > --- Igor --- > In Sqlite project, check Properties | Linker | Advanced | Import Library. > Make sure it's not empty (normally, you should see something like > $(OutputDir)$(TargetName).lib in there). > > Linker produces an import library (a LIB file) as a side-effect or building a > DLL (unless this is suppressed). Projects using the DLL need the import > library to link to. > > Igor Tandetnik > > -- > It is set to generate a .lib according to that setting, but from what Pavel > said, it never does because the .def file is missing from the project. I've > never heard of .def files before so this is a new issue for me. This is all > quite exciting :) > > Thanks, > > Kurt > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Pavel Ivanov > Sent: Thursday, December 17, 2009 10:04 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] Compiling SQLite as .lib increases project sizeandbuild > time? > >> If I remove the dependency on sqlite from HouseKeeper, it gives linker >> errors with unresolved symbols for sqlite3_* functions. Adding sqlite as >> a dependency to HouseKeeper causes it to look for the sqlite.lib file. > > Make sure that .def file is included in you Sqlite project. When > compiling project as dll, compiler generates stub .lib file anyway for > linking with anybody who will need this dll. But if you don't include > .def file and thus don't define any functions to export from dll, > compiler doesn't generate .lib file and it can cause the error you > see. > > Pavel > > On Thu, Dec 17, 2009 at 9:49 AM, Kurt D. Knudsen <kknud...@zystemsgo.com> > wrote: >> Pavel, >> >> I have not defined it in the Linker properties. I have a solution called >> 'SQLite Test' and inside it consists of 4 projects: >> >> HouseKeeper - compiles as .dll >> Common - compiles as .dll >> SQLiteTest - compiles as .exe >> Sqlite - forced to compile as .lib (Why?!) >> >> Under Project Dependencies: >> * HouseKeeper is dependent on Common and sqlite. >> * Common is dependent on just sqlite >> * SQLiteTest is dependent on HouseKeeper, Common, and sqlite >> >> If I remove the dependency on sqlite from HouseKeeper, it gives linker >> errors with unresolved symbols for sqlite3_* functions. Adding sqlite as >> a dependency to HouseKeeper causes it to look for the sqlite.lib file. >> >> --- >> >> Teg, >> >> I'd like to keep it an external .dll file if possible, it doesn't make >> sense to me to have it added to each project that uses SQLite. SQLite >> is, as stated above, its own project inside of the solution. >> >> How do I go about making the other projects reference the .dll instead >> of requiring the .lib? I should note that I am not the original author >> of this solution, just modifying it to use SQLite instead of flat-files. >> So I am unsure how the other developer set the solution up since >> HouseKeeper and Common both compile as .dll. >> >> I've been trying to contact the original developer that we hired but >> can't seem to get a hold of him since we're in different time zones. >> I'll try again to see if he can help me properly set up the solution if >> I am making no sense here :) >> >> I hope you guys can help me out; it'd make life quite a bit easier. >> >> Thanks, >> >> Kurt >> >> -----Original Message----- >>> 1>LINK : fatal error LNK1181: cannot open input file >>> '..\release\sqlite.lib' >> >> Is this filename something that you wrote yourself in configuration of >> your project? If you compile something as dll you don't need to mention >> its library as additional linking source in dependent projects. >> >> Pavel >> >> -----Original Message----- >> From: sqlite-users-boun...@sqlite.org >> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Teg >> Sent: Thursday, December 17, 2009 9:13 AM >> To: General Discussion of SQLite Database >> Subject: Re: [sqlite] Compiling SQLite as .lib increases project size >> andbuild time? >> >> Hello Kurt, >> >> The size increase is because you're including code IN the program >> instead of having it in a DLL. That's one of the benefits of DLLs. The >> second thing, the build time thing is because you've chosen to build >> SQLite each and every time you build the entire project. That's purely >> a design choice in how you build. It's how I do it too. Your other >> option is to make Sqlite it's own project and only build it when it >> changes but, link it in by manually adding the lib path and lib name >> to the linker. >> >> I have some projects I build every time when doing a release, like >> SQlite and I have some projects like OpenSLL where I build once and >> only reference the lib. >> >> I find that SQlite builds very quickly. Takes about 20 seconds in >> release 64 bits with full optimization. I could make it faster if I >> turned on pre-compiled headers but, it doesn't seem worth the effort. >> During development, it only build when it changes. >> >> Perhaps you only have one project and you've lumped everything >> together? I'd break SQlite out into it's own project then use project >> dependencies to make the linker include it. >> >> C >> >> Thursday, December 17, 2009, 9:01:04 AM, you wrote: >> >> KDK> Hi all, >> >> KDK> >> >> KDK> Since we're moving our project over from flat-files to an SQL DB, >> I've >> KDK> noticed that projects that utilize SQLite3 have increased to over >> 500k >> KDK> in size. Their original sizes were between 50-100k. Also, the build >> KDK> times have increased dramatically. I have SQLite added as a >> separate >> KDK> project in my solution (Visual Studio 2008) and have its >> Configuration >> KDK> Type as .lib. If I set it to .dll, then the rest of the projects >> fail to >> KDK> link properly stating: >> >> KDK> >> >> 1>>LINK : fatal error LNK1181: cannot open input file >> KDK> '..\release\sqlite.lib' >> >> KDK> >> >> KDK> I'm curious to know if this is normal behavior and if SQLite must >> be >> KDK> compiled as a .lib as opposed to a .dll? The odd thing is, I have >> other >> KDK> projects in the solution that are set to compile as a .dll and they >> link >> KDK> fine with each other. >> >> KDK> >> >> KDK> Relevant information: >> >> KDK> >> >> KDK> Visual Studio 2008 Professional >> >> KDK> Compiling as Release >> >> KDK> >> >> KDK> Let me know if you need more information. >> >> KDK> >> >> KDK> Thanks, >> >> KDK> >> >> KDK> Kurt >> >> KDK> _______________________________________________ >> KDK> sqlite-users mailing list >> KDK> sqlite-users@sqlite.org >> KDK> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> >> >> -- >> Best regards, >> Teg mailto:t...@djii.com >> >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 > _______________________________________________ > 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
