[Top][All Lists]

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

Porting from linux/unix to windows - Libtool?

From: Francesco Calimeri
Subject: Porting from linux/unix to windows - Libtool?
Date: Thu, 15 Jun 2006 12:54:51 +0200

Post on the libtool mailing list as someone kindly suggested. Original
thread at


----Original Message----
From: Nobody [mailto:address@hidden On Behalf Of
Sent: Tuesday, June 06, 2006 5:53 AM
To: address@hidden
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 
> libltdl.

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?
thanks.... for your patience...

This is the new Makefile:







all: $(LIB) $(TESTPROG)

$(OLIB): $(CLIB)
        $(LIBTOOLCMD) --mode=compile $(GCC) -g -O -c $(CLIB)

$(LIB): $(OLIB)
        $(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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]