lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

For me, having libraries that build by default as shared is a pain, because I then have to figure out how to compile them statically (if that isn't already part of the build instructions, makefile, etc., which it usually isn't these days).

Mind you, it's a minor pain, but it is definitely a pain of the "same damn spot" kind.

Why not just go with the shared library approach to minimise my pain, I hear you ask.

Because sorting out issues that revolve around shared libraries in the field is an even bigger pain.

Just the other day, my app (a non Lua one) wouldn't run on a machine I installed it on. It took me half a day to figure out that the reason was that an outdated DLL was hiding in C:/Windows/system32 and it was getting loaded through a sequence of interdependent DLLs.

If you do not have access to the installation machine itself, and have to talk a user through various trial and error scenarios, then this has some serious consequences in how you are perceived by the customer.

Building statically linked applications removes a lot of this problem.

And since my example was for Windows, please do not even attempt to get me sold on "side by side".

Phew, feels good to get that off my chest ;-)