[Mingw-users] [mingw - C/C++] Porting from linux/unix to windows - Libtool?

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3763387
By: kaliaragorn

Sorry for posting that, but looked around through the forums and could not find
a workaround for my problem. Hope to have chosen the right forum.

I have a very complex application developed under linux, exploiting a hand-made
makefile.

I was able to port it under cygwin and also under mingw, so that's perfect (simply
compiling under cygwin and mingw, respectively).

Now the application needs to exploit some shared (dynamic) libraries; the
implementation relies on libldl (so dlopen, dlclose and so on). Thus, the idea
is to exploit libltdl and libtool in order to be able to port the application
on windows through both cygwin and mingw (I do really need an application which
does not rely on cygwin1.dll stuff for licensing reasons) -- I've changed any
"dlopen" to "lt_dlopen" and similar stuff. Everything seems to be fine under
linux. The problem is now the porting!

In order to be a bit clean, I've written a very simple (stupid (tm)) application
which look for functions in a shared library, and tried to port it on cygwin
and mingw (on windows, of course). Could not make it! Can someone _please_ help
me solving this?

The library is:



===== 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;
}
===== END : libmyprint.C =====



The (stupid) application is:



===== 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 << ".so..." << 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);
}
===== END : testlibprint.C =====


Under linux, this simple Makefile worked perfectly:


===== FILE: Makefile =====
LIBNAME=myprint
TESTPROG=testlibprint

LIBSTUB=lib$(LIBNAME)
CLIB=$(LIBSTUB).C
OLIB=$(LIBSTUB).o
SOLIB=$(LIBSTUB).so
LOLIB=$(LIBSTUB).lo
LALIB=$(LIBSTUB).la
GCC=g++

all: $(SOLIB) $(TESTPROG)

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

$(SOLIB): $(OLIB)
        libtool --mode=link $(GCC) -module -g -O -o $(LALIB) $(LOLIB) -rpath
/usr/local/lib -lm
        ln -s .libs/$(SOLIB) .

$(TESTPROG): $(TESTPROG).C
        libtool --mode=link $(GCC) -g -O -o $(TESTPROG) $(TESTPROG).C -lm -rpath
/usr/local/lib  -lltdl

clean:
        rm $(OLIB) $(SOLIB) $(LALIB) $(LOLIB) $(TESTPROG)
        rm -fr .libs
===== END : Makefile =====


Under cygwin it compiles, but does not generate any .so (and this is expected),
nor any DLL. Mingw does not compile at all, complaining about undefined references
to dlopen() and similar.

Please, please, help me.

Bests,
Francesco

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=286529