DLL Questions

new topic     » topic index » view thread      » older message » newer message

I've been working on a Euphoria version of SWIG, and seem to be making good
progress. Basically, it will take a modified version of a C include file and
generate the C source for a DLL, the .DEF for the DLL, and a Euphoria
wrapper to automatically link and wrap all the functions in the DLL. This
makes it (in theory) fairly easy to link Euphoria to a pre-existing library.

I'm running into trouble when I try to create the DLL. I'm using lcc-win32
(a C compiler for Win32), and it is mangling the routine names. I'm hoping
someone on the list can give me a clue here.

My C file looks more or less like this:

   #include <windows.h>
   #include <math.h>
   #include "junk.c"

   BOOL WINAPI LibMain(HINSTANCE hDLL, DWORD Reason, LPVOID Reserved) {
      // assume things go well
      return TRUE;
   }

The "junk.c" file looks like this:

   int foo( int z ) { return z+100 };
   int bar( int z ) { return z-100 };

and the .DEF file looks like this:

   Library junk
   EXPORTS
   foo
   bar

So far, so good; it compiles cleanly from the command line. I run into
trouble when I try to use the DLL. The names are mangled by adding an
underscore to the beginning of them:

   _foo
   _bar

If I adjust the Euphoria code to look for the mangled routine names, it
finds them, and they work fine. One way sround the name mangling is to
write:

   Library junk
   EXPORTS
   foo=foo
   bar=bar

But it seems a bit of a hack. Is this behavior normal? What's the proper way
to turn off the name mangling?

The point where I really run into trouble is when I try to include routines
from the standard include files. For example:

   Library junk
   EXPORTS
   pow

Since pow() is declared as external in math.h, the dll *should* be able to
find it. The code compiles just fine, but when I go to link it, I get the
error:

   Specified export _pow is not defined.
   Missing exports. Program aborting.

The trick of adding:

   pow=pow

to the .DEF file does not work here.

I suspect the problem is that lcc (the compiler) mangling the names, so when
lcclink (the dll linker) tries to resolve them, it can't find them in the
link table. But I can't find any command line options for lcc or lcclink
that seem to have any bearing on this.

Any suggestions?

Thanks!

-- David Cuny

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu