On Jul 29, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> Well, that is just it. I am never going to make an executable
> out of the library. I need to produce a .dll under Windows that
> can be loaded by name at runtime.
The rules for portable dlopening with libtool say that, when you link
a program that may dlopen a certain library, you must use libtool and
use the -dlopen flag. In this case, if the library cannot be
dlopened, libtool will link the program with the library (or its
dependencies) and add the symbol table of the library so that libltdl
will find them.
> It seems that this is just not possible with libtool, which I find
> odd because this is exactly the sort of thing that libtool should
> have been designed to do.
It does it, it's just a little bit harder to do it portably, and
libtool must be updated regarding cygwin's recent abilities of linking
static libraries into shared libraries.
I wonder if we shouldn't just remove the complex procedure to create
DLLs required by old, obsolete releases of Cygwin, and create only
static libraries on them, and arrange for libtool to use the new,
simpler mechanisms on recent releases of Cygwin.
What kind of test would we have to do to tell whether we have recent
enough a release of Cygwin to decide?
> it would seem that the current version does not work unless all my
> .c files are in the same directory and I compile them all into one
> .dll
Did you try libtool convenience libraries? That should work for files
in multiple directories. It's just regular static libraries that
currently don't work, even though they could: it's just a matter of
porting libtool to the newer Cygwin tools.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
