Re: mingw DLL problem

Holger Vogt <[email protected]>
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
Al,

some comments about DLLs:

A dll exports functions which may be used and shared by other programs. 
In your example the function bar() is missing and may be delivered by a dll.

This is how I create one in MINGW using MSYS:

// test_dll.cpp
#include "test_dll_exports.h"

int bar()
{
return (2);
}

//test_dll_exports.h
#include <windows.h>

#ifndef TEST_DLL_EXPORTS_H_INCLUDED
#define TEST_DLL_EXPORTS_H_INCLUDED

#if defined(__cplusplus)
extern "C" {
#endif

__declspec(dllexport) int bar(void);

#if defined(__cplusplus)

}
#endif

#endif
//**************************************

#The makefile:
CC     = g++
OPT    = -O3 -s
MODULE = TestDLL
OTHER  = -Wall
CFLAGS = -O3 -s $(OTHER)

SRCS =  test_dll.cpp
OBJS = $(SRCS:.cpp=.o)

INCDIR = -I.
LIBDIR = -L.

DLL    = $(MODULE).dll

.SUFFIXES: .cc .cpp .o .dll

$(DLL): $(OBJS)
    $(CC) -shared *.o $(CFLAGS) -o $(DLL) --driver-name=g++ $(LIBDIR) 
-Wl,--out-implib,lib$(MODULE).a 2>&1 | c++filt
   
.cpp.o:
    $(CC) $(CFLAGS) $(INCDIR) -c $<

clean::
    rm -f $(OBJS) *~ $(DLL) $(MODULE).a core

You will create a DLL TestDLL.dll and an export library libTestDLL.a 
which does not contain the functions but gives information about their 
location.

If you now want to use the dll, you may either attach it during linking 
or at runtime.

During linking it may be done like this:

/* foo.cpp: simple dll
 load dll TestDLL.dll at link time */

#include <windows.h>
using namespace std;
#include <iostream>

#include "test_dll_imports.h"

//extern int bar();

int foo(int q)
{
  return q*bar();
}

int main(int argc, char* argv[]) {

cout << "something" << "\n";
cout << foo(3);

return 0;
}

// test_dll_imports.h
#include <windows.h>

#ifndef TEST_DLL_EXPORTS_H_INCLUDED
#define TEST_DLL_EXPORTS_H_INCLUDED

#if defined(__cplusplus)
extern "C" {
#endif

__declspec(dllimport) int bar(void);

#if defined(__cplusplus)

}
#endif

#endif

It compiles and links with:
g++ -Wall -s  foo.cpp -o testout.exe -L./ -lTestDLL

You may attach the dll during runtime:

/* foo-rt.cpp: simple dll
 load dll TestDLL.dll at runtime */

#include <windows.h>
using namespace std;
#include <iostream>
//extern int bar();

typedef int(*PFNAPI2)(void);
PFNAPI2 mybar;

int foo(int q)
{
  return q*mybar();
}

int main(int argc, char* argv[]) {

HINSTANCE testapi;

// attach dll
testapi = LoadLibrary("TestDLL.dll");
// get address of function bar from dll
mybar  = (PFNAPI2)GetProcAddress(testapi, TEXT("bar"));   
   
cout << "something: "  << foo(2) << "\n";

// detach dll
if (testapi) FreeLibrary(testapi);

return 0;
}
//*****************************************

which is compiled and linked with:
g++ -Wall -s  foo-rt.cpp -o testo.exe

Unfortunately there is (has been?) a bug during dynamic linking with 
MINGW. DLL detachement does not work correctly, so the next attachement 
may lead to a program crash. I posted this to the MINGW list, but 
probably nobody cared for it. Maybe it is gone with the most recent g++?

Dynamic linking maybe made compatible to LINUX by replacing
HINSTANCE testapi;
by
void *testapi;
and
testapi = LoadLibrary("TestDLL.dll");
by
testapi = dlopen("libdispa.so.1", RTLD_LAZY);
and
mybar  = (PFNAPI2)GetProcAddress(testapi, TEXT("bar"));
by
mybar = (PFNAPI6)dlsym(testapi, "bar");
and
if (testapi) FreeLibrary(testapi);
by
if (testapi) dlclose(testapi);


Regards

Holger



 
 al davis schrieb:
> I still can't figure out how to make it work.
>
> Consider the file  "foo.cc"
> =========
> extern int bar();
> int foo(int q)
> {
>   return q*bar();
> }
> =========
>
>
> On Linux, to make a native .so I can do:
>         g++ -fPIC --shared foo.cc
> and it builds an appropriate file, such that "bar" will be 
> resolved later.
>
>
> The problem is if I do:
>         i586-mingw32msvc-g++  --shared foo.cc
> It responds with:
> ========
> /tmp/cch3JG6k.o:foo.cc:(.text+0x7): undefined reference to 
> `bar()'
> collect2: ld returned 1 exit status
> ========
>
> With a real file, I get a flood of these messages.
>
> What am I doing wrong?
>
>
> _______________________________________________
> Gnucap-devel mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/gnucap-devel
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.