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

[Francesco Calimeri]

Just a question: is there a way to tell libtool the desired name of the
final .dll/.so? i mean... I get always some libMYLIB-0.dll, and I need the
libMYLIB.la in order to allow the program to find the library at execution
time; while if the name was libMYLIB.dll (without the "-0") I could drop the
libMYLIB.la file at all.

May anybody help me?
f


----Original Message----
From: Francesco Calimeri [mailto:address@hidden
Sent: Sunday, June 18, 2006 3:27 PM
To: address@hidden; 'General mail list for posts concerning MinGW'
Cc: 'Ralf Wildenhues'
Subject: RE: Porting from linux/unix to windows - Libtool?

> Ok, it seems that now it works.
> 
> ----Original Message----
> From: Ralf Wildenhues [mailto:address@hidden
> Sent: Thursday, June 15, 2006 2:43 PM
> To: Francesco Calimeri
> Cc: address@hidden
> Subject: Re: Porting from linux/unix to windows - Libtool?
> 
> [cut]
> 
>> 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, ...)
> 
> I have a system which needs to be distributed for linux,
> freebsd, macOS, windows, solaris, and who knows where else.
> So the code must be very
> portable: just copy the code and "make". that's it. the
> problem is that I cannot use autoconf/automake. And on the
> internet there are not so many hints for those who need to do
> everything manually. 
> 
> [cut]
> 
>> There is no problem with doing this manually, at all.
> 
> [cut]
> 
> thanks for the advices.
> 
> 
>> 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.
> 
> nono. just in order to be clear, dynamic libraries are
> intended to be used in order to have a sort of plugin
> functions to the system, and the users shoud be capable to
> build what they need by theirselves. Everything worked well
> (even for the users) with the first implementation, which
> relied on libdl (dlopen, dlclose, etc..) and .so libraries
> under linux; but now the beta test should end and the system
> needs to be working also under windows and so on. that's it.
> 
> Thanks to your advices and those from the mingw list, to
> which I'm crossposting now since the topic is exactely the
> same, I've obtained something which seems to work. I post it
> here for two reasone:
> 
>  (i)  maybe someone else will need to do the same or
> something similar in the future, I think this could be useful
>  (ii) please if someoone notices something bad or wrong, or
> simply something which may be improved, please tell me! :)
> 
> ok, here we are:
> 
> ===========================
> // file: libmyprint.C
> /* aliases for the exported symbols */
> // #define myprint    libmyprint_LTX_myprint
> 
> #include <iostream>
> using namespace std;
> 
> 
> /* an exported function */
> extern "C" void myprint ( int number ) {
>   cout << number << endl;
> }
> ===========================
> 
> ===========================
> // file: testlibprint.C
> #include <iostream>
> #include <ltdl.h>
> 
> using namespace std;
> 
> int main() {
>   cout << "Dynamic library test" << endl;
> 
>   int errors=0;
>   errors = lt_dlinit ();
> 
>   char *libname=new char[64];
> 
>   // asking for the library name
>   cout << "Please enter library name :  ";
>   cin >> libname;
>   cout << endl;
> 
>   // open the library
>   cout << "Opening " << libname << "..." << endl;
>   lt_dlhandle handle = lt_dlopenext(libname);
> 
>   if (!handle) {
>     cerr << "*** Cannot open library: " << lt_dlerror() << endl;    
>   return 1; }
> 
>   // load the symbol
>   cout << "Loading symbol myprint..." << endl;
>   typedef void myprint_t (int);
> 
>   // reset errors
>   lt_dlerror();
> 
>   myprint_t * myprint = (myprint_t *) lt_dlsym(handle, "myprint");
>   const char *dlsym_error = lt_dlerror();
> 
>   if (dlsym_error) {
>     cerr << "*** Cannot load symbol 'myprint': "
>          << dlsym_error << '\n';
>     lt_dlclose(handle);
>     return 1;
>   }
> 
>   // perform the calculation
>   cout << "Calling my print..." << endl;
>   myprint(4);
> 
>   // close the library
>   cout << "Closing library..." << endl;
>   lt_dlclose(handle);
> }
> ===========================
> 
> ===========================
> // file: Makefile
> LIBNAME=myprint
> TESTPROG=testlibprint
> EXEEXT=.exe
> 
> INSTALLDIR=/home/kali/test/
> 
> LIBSTUB=lib$(LIBNAME)
> 
> CLIB=$(LIBSTUB).C
> OLIB=$(LIBSTUB).o
> LOLIB=$(LIBSTUB).lo
> LALIB=$(LIBSTUB).la
> LIB=$(LALIB)
> 
> NOUNDEFINED=-no-undefined
> 
> GCC=g++
> 
> LIBTOOLPATH=/usr/bin/
> LIBTOOL=$(LIBTOOLPATH)/libtool
> 
> LIBLTDLPATH=/lib/
> 
> all: $(LIB) $(TESTPROG)
> 
> $(OLIB): $(CLIB)
>       $(LIBTOOL) --mode=compile $(GCC) -g -O -c $(CLIB)
> 
> $(LIB): $(OLIB)
>       $(LIBTOOL) --mode=link $(GCC) $(NOUNDEFINED) -module -g -O -o
> $(LALIB) $(LOLIB) -rpath /usr/local/lib -L$(LIBLTDLPATH) -lm
> 
> $(TESTPROG): $(TESTPROG).C
>       $(LIBTOOL) --mode=link $(GCC) $(NOUNDEFINED) -g -O -o
> $(TESTPROG)$(EXEEXT) $(TESTPROG).C -rpath /usr/local/lib
> -L$(LIBLTDLPATH) -lltdl -lm 
> 
> clean:
>       $(LIBTOOL) --mode=clean rm -f $(LOLIB) $(LALIB) $(LIB)
>       $(TESTPROG)$(EXEEXT) rm -fr .libs
> 
> install:
>       $(LIBTOOL) --mode=install cp $(TESTPROG)$(EXEEXT) $(INSTALLDIR)
>       $(LIBTOOL) --mode=install cp $(LALIB) $(INSTALLDIR)     rm -f
> $(INSTALLDIR)/*.a ===========================
> 
> please note that:
>  - this produces a cyg$(LIBNAME)-0.dll file under cygwin, a
> lib$(LIBNAME)-0.dll under mingw/windows and a .so under
> linux, automatically and without the need of some specific directives;
>  - since there's no need to link somehow the libraries to
> some executable, the .a files can be dropped;
>  - it seems that the #define directive is useless (even if I
> thought the opposite);
>  - the filename of the library MUST start with "lib" under
> cygwin/mingw, unless you want to change the way the system
> looks up for dlls.
> 
> Hope this helps someone else in the future.
> 
> 
> Again, if you find some errors/possible improvements please tell me.
> 
> Thank you all! :)
> f