Re: Windows DLLs from Unix with minimum effort

[Brian Dessent]

Jason Curl wrote:

>   libtest.exe      <-- Doesn't seem to work? No idea
>                        what this is...
>   libtest
>   .libs/
>     libtest.exe    <-- Will work when "libmofo-1.dll"
>                        is in the path, e.g. copied to
>                        this dir.
> 
> Can anybody explain what libtool is doing?? It appears to do a lot of
> nifty stuff, but I don't see any dependencies on "libmofo" from
> "libtest.exe" in either case. I'll attach a minimal example when I'm
> back at work tomorrow.

It is a wrapper to allow running the uninstalled binary in the build
tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. 
On a POSIX system this would be a shell script.  I think that in libtool
HEAD, it won't have such a confusing name.

> And the directory it runs from (.libs) indicates it is actually the
> source "lt-libtest.c" that relies on a shell, so as soon as I move the
> executable to a "virgin" computer without Cygwin, the program
> "libtest.exe" won't work.

You shouldn't be manually mucking about like that, you use "make
install" to get an installed copy and that will not be a wrapper.  If
you configured with CC="gcc -mno-cygwin" (i.e. used this "fake mingw"
setup) then the Cygwin dependence should only be for the wrapper which
isn't supposed to be installed or even moved out of the build directory
for that matter.

> I'd also like to generate .lib files (what is the .a file that is
> generated anyway? Is that the .lib import library?)

An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they
are all the exact same thing just named differently.  Don't confuse the
libfoo.a name with a static library which has the same style name but is
a totally different thing (and that's why it's considered deprecated to
name an import library libfoo.a, but some are still done that way, e.g.
all of w32api.)

Brian