[sqlite] Compiling SQLite as .lib increases project size and build time?

[Kurt D. Knudsen]

Hi all,

Since we're moving our project over from flat-files to an SQL DB, I've
noticed that projects that utilize SQLite3 have increased to over 500k
in size. Their original sizes were between 50-100k. Also, the build
times have increased dramatically. I have SQLite added as a separate
project in my solution (Visual Studio 2008) and have its Configuration
Type as .lib. If I set it to .dll, then the rest of the projects fail to
link properly stating:

1>LINK : fatal error LNK1181: cannot open input file
'..\release\sqlite.lib'

I'm curious to know if this is normal behavior and if SQLite must be
compiled as a .lib as opposed to a .dll? The odd thing is, I have other
projects in the solution that are set to compile as a .dll and they link
fine with each other.

Relevant information:

Visual Studio 2008 Professional

Compiling as Release

Let me know if you need more information.

Thanks,

Kurt

_______________________________________________
sqlite-users mailing list
sqlite...@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[Pavel Ivanov]

> 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

[Teg]

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...@sqlite.org
KDK> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

--
Best regards,
Teg mailto:T...@djii.com

[Kurt D. Knudsen]

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

[Igor Tandetnik]

Kurt D. Knudsen wrote:
> 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?!)

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

[Pavel Ivanov]

> 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

[Kurt D. Knudsen]

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

[Kurt D. Knudsen]

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?

[Pavel Ivanov]

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

[Kurt D. Knudsen]

Seems I need to put the following in the Preprocessor Definitions:

SQLITE_ENABLE_COLUMN_METADATA

This makes it compile just dandy. Now my file sizes are back to normal. Hoorah.

You guys are amazing, a baker's dozen internets to each of you.

Regards,