Re: [SUGGESTION] Some lfs functionality in os library, please!

[Jonathan Goble <jcgoble3@...>]

On Sat, Sep 24, 2016 at 6:17 AM, rexonf <rexonf@gmail.com> wrote:
> LuaRocks is not there yet. E.g. I try to install lxp on Windows, it looks
> for libexpat.lib but that's not the name when you compile Expat for windows.

Actually, it DOES need libexpat.lib. When you compile a DLL on
Windows, the compiler generates both the dynamic library (.dll) and a
corresponding .lib file. The latter is an "import library", which is
required to properly link another piece of code during compilation of
that code to the .dll file that it goes with. The import library
contains the information needed by the linker to resolve symbols in
the DLL.

This .lib file is needed during compilation, but is not needed by the
end user, so programs that ship with DLLs generally don't ship the
corresponding .lib files as well, unless they intend for you to
compile your own code linked to their DLL. However, the .lib file is
only necessary when linking at compile time. It is not needed when
dynamically loading a DLL at runtime (such as a Lua module written in
C, loaded with `require 'mylib'`); for that, the DLL alone is all you
need.

Confused yet? Let's add this: .lib files are not necessarily import
libraries. They can also be a static library. So Windows has three
types of libraries: static libraries (.lib), used for static linking
only; dynamic libraries (.dll), used for dynamic linking only; and
import libraries (also .lib), generated by the DLL compiling process
and required to link other code to a DLL at compile time.

The easiest thing to remember is this: you must ALWAYS have a .lib
file in order to link to a library at compile time. In the case of
static linking, that .lib file is your entire library, but in the case
of dynamic linking, it's only an import library allowing the compiler
to resolve the symbols in the .dll file (which is the actual code
library).