Post on the mailing list instead of the forum. Original thread at
From: Nobody [mailto:nobody@...] On Behalf Of
Sent: Tuesday, June 06, 2006 5:53 AM
Subject: [mingw - C/C++] RE: Porting from linux/unix to windows - Libt
> First, you should use dllexport on the symbols you want exported from
> a library.
> (And dllimport on those you are importing, except in your case this
> isn't necessary as you're doing dynamic runtime linking.)
I thought that was not necessary since I wanted to use libtool: I need some
code that does not need to be changed but only cross-compiled.
> Second, if you're using libtool you need to enable -no-undefined on
> win32 if you want a shared library (that is why you only got a static
> lib under Cygwin.) More details on this option here:
That was something I knew, but forgot! my fault! :)
> Third, don't hardcode that the name of the shared library as ending in
> .so in a makefile, as that is not portable at all.
> It varies greatly -- .dll on windows, .dylib on Darwin, .a on some
> systems, etc. Similarly you should use $(EXEEXT) instead of assuming
> that executables have no extension. (If you used automake you
> wouldn't have to worry about any of this, btw.)
Unfortunately I cannot use automake at the moment; this is not my choice..
> Fourth, dlopen() does not exist on native Windows, so you should
> expect link errors if you try to use it. Cygwin emulates dlopen(), so
> if you're using Cygwin then you can use it just as you would on linux.
> But not so on mingw which doesn't emulate anything. The native way of
> doing things is
> LoadLibrary() and GetProcAddress(). Now the whole point of ltdl is to
> abstract away these kinds of differences, and so using it is the right
> idea. However, the fact that you're still getting link errors about
> dlopen would imply that you have an installation problem of ltdl.
> Perhaps you're trying to use the Cygwin version of the library with
> mingw -- that definitely won't work. You'll need a mingw-compiled
This is something, again, I knew: but again, my fault: for some reason my
libtool installation was broken. I've reinstalled everything.
> Finally, please use the mailing list. These forums have a terrible
> interface and the only reason that anyone ever responds to them is
> because postings are one-way mirrored to the mailing list. (We have
> discussed closing them permanently and I hope that happens ASAP.)
Done; hope that now it's fine....
Ok, now I've fixed some stuff thanks to your advices... And finally have
obtained, relying on lt_dlopen, lt_dlclose and so, something which does not
need to be touched, and once compiled generates a .so on linux, a *cyg*.dll
on cygwin, and a lib*.dll on mingw.
Now: on mingw the generated binaries are an .exe and a .dll. I noticed that
the executable does not only needs the .dll and the libltdl-3.dll (which was
expected), but also the ".la" file. Did I make some mistake? In addition, is
it due to have everithing under the ".lib\" folder? How can I control this,
and what I need to distribute along with the app?
thanks.... for your patience...
This is the new Makefile:
all: $(LIB) $(TESTPROG)
$(LIBTOOLCMD) --mode=compile $(GCC) -g -O -c $(CLIB)
$(LIBTOOLCMD) --mode=link $(GCC) $(NOUNDEFINED) -module -g -O -o
$(LALIB) $(LOLIB) -rpath /usr/local/lib -lm
#ln -s .libs/$(LIB) .
$(LIBTOOLCMD) --mode=link $(GCC) $(NOUNDEFINED) -g -O -o
$(TESTPROG)$(EXEEXT) $(TESTPROG).C -lm -rpath /usr/local/lib
rm -f $(OLIB) $(LOLIB) $(LALIB) $(LIB) $(TESTPROG)$(EXEEXT)
rm -fr .libs
Thanks in advance,