Re: Porting from linux/unix to windows - Libtool?

[Ralf Wildenhues]

Hello Francesco,

* Francesco Calimeri wrote on Thu, Jun 15, 2006 at 12:54:51PM CEST:
> Post on the libtool mailing list as someone kindly suggested. Original
> thread at 
> 
> https://sourceforge.net/forum/message.php?msg_id=3764300

Hmm.  This doesn't seem to work for me.  (But I scan mingw-users
sometimes, and saw your messages fleeting by...)


> > 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.

Cross-compiled from some unixy system to MinGW?
(Sorry, I don't remember whether the problems you had here are already
solved or not; if not, please post a pointer to them, or describe them,
post the errors, ...)

> > 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..
> :(

There is no problem with doing this manually, at all.

> 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:
> =================================
> LIBNAME=myprint
> TESTPROG=testlibprint
> EXEEXT=.exe
> 
> LIBSTUB=lib$(LIBNAME)
> 
> CLIB=$(LIBSTUB).C
> OLIB=$(LIBSTUB).o
> LOLIB=$(LIBSTUB).lo
> LALIB=$(LIBSTUB).la

> LIBEXT=.dll
> LIB=$(LIBSTUB)$(LIBEXT)

You don't need these two.  You can just
  LIB = $(LALIB)

as that's one thing the wrapper is for: encapsulating the library.

> NOUNDEFINED=-no-undefined
> 
> GCC=g++
> 
> LIBTOOLPATH=#/usr/local/bin/
> LIBTOOL=libtool
> LIBTOOLCMD=$(LIBTOOLPATH)$(LIBTOOL)

I'd just write
  LIBTOOL = $(LIBTOOLPATH)/libtool

and use that, but ok.

> LIBLTDLPATH=/usr/local/lib/
> 
> 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) .

The ln -s isn't necessary either (as you already noticed).

> $(TESTPROG): $(TESTPROG).C
>         $(LIBTOOLCMD) --mode=link $(GCC) $(NOUNDEFINED) -g -O -o
> $(TESTPROG)$(EXEEXT) $(TESTPROG).C -lm -rpath /usr/local/lib
> -L$(LIBLTDLPATH) -lltdl

Don't you want to link $(TESTPROG) against $(LIB), too?
Then add that one the link line as dependency.  And yes,
it's best to add the uninstalled libtool wrapper on the
link line: that way libtool will know what to do.

> clean:
>         rm -f  $(OLIB) $(LOLIB) $(LALIB) $(LIB) $(TESTPROG)$(EXEEXT)
>         rm -fr .libs

Hint:
  libtool --mode=clean rm -f foo.lo libfoo.la testprog

will remove foo.lo, libfoo.la, testprog and all other files that these
wrappers encompass.  (The last one may or may not be a wrapper.)

Cheers,
Ralf