I've been having some trouble importing dlls from other libraries, in particular, TIFF/DIB image libraries, with the digital mars compiler. Using dll's generated by DM, I have no problems, but I repeatedly get symbol undefined errors with called functions from the dll's. I've tried both implicit and explicit dll use, as outlined on this site, any tips, help, or suggestions? Thanks.

Probably the name mangling doesn't match. Look at exactly what names are exported by your dlls, and what the DM executable expects them to be.

"Anonymous" <Anonymous_member@pathlink.com> wrote in message news:arjpm1$1mu2$1@digitaldaemon.com...
> I've been having some trouble importing dlls from other libraries, in particular, TIFF/DIB image libraries, with the digital mars compiler.
Using
> dll's generated by DM, I have no problems, but I repeatedly get symbol
undefined
> errors with called functions from the dll's. I've tried both implicit and explicit dll use, as outlined on this site, any tips, help, or
suggestions?
> Thanks.
>
>

This is my first time using dlls, so please bare with me. Using the explicit
method for including dlls (decalring each function with the IMPORTS statement in
the .def file), will allow me to compile the program if I use the expected
mangled function name, but it doesn't find that file in the dll, as seems
obvious to me.
The dll I'm trying to use is IMGLIB.dll, which, according to libunres.exe (via
implib creating a library from the dll), and it's own documentation, contains
the function ReadFileIntoDIB(Among many others). This is the exact name returned
from libunres, is that then the mangled name?
When I attempt to include this file into my program, the linker looks at it as
_ReadFileIntoDIB@4(I'm assuming this is the mangled name) As I stated above, if
I include this in the IMPORTS list, it allow me to compile, but doesn't find it
in the dll(Which, by the way, is in the same directory as the program).
If it matters, I have no prototypes or extern declarations of the function, I am
attempting to merely call it and hope that the linker figures it out.

Do you know what the problem is? Does the dll need to be somewhere else, am I not adding something, etc?

Thank you for your prompt and helpful reply, I just can't seem to figure this out.

In article <arkvtc$30cm$1@digitaldaemon.com>, Walter says...
>
>Probably the name mangling doesn't match. Look at exactly what names are exported by your dlls, and what the DM executable expects them to be.

The problem is that the compiler generates a name with @4 appended, and the DLL has the name in it without the @4. So, they don't match up. The solution is here:

www.digitalmars.com/faq.html#sysimport


"Anonymous" <Anonymous_member@pathlink.com> wrote in message news:arlmco$nvn$1@digitaldaemon.com...
> This is my first time using dlls, so please bare with me. Using the
explicit
> method for including dlls (decalring each function with the IMPORTS
statement in
> the .def file), will allow me to compile the program if I use the expected
> mangled function name, but it doesn't find that file in the dll, as seems
> obvious to me.
> The dll I'm trying to use is IMGLIB.dll, which, according to libunres.exe
(via
> implib creating a library from the dll), and it's own documentation,
contains
> the function ReadFileIntoDIB(Among many others). This is the exact name
returned
> from libunres, is that then the mangled name?
> When I attempt to include this file into my program, the linker looks at
it as
> _ReadFileIntoDIB@4(I'm assuming this is the mangled name) As I stated
above, if
> I include this in the IMPORTS list, it allow me to compile, but doesn't
find it
> in the dll(Which, by the way, is in the same directory as the program). If it matters, I have no prototypes or extern declarations of the
function, I am
> attempting to merely call it and hope that the linker figures it out.
>
> Do you know what the problem is? Does the dll need to be somewhere else,
am I
> not adding something, etc?
>
> Thank you for your prompt and helpful reply, I just can't seem to figure
this
> out.
>
> In article <arkvtc$30cm$1@digitaldaemon.com>, Walter says...
> >
> >Probably the name mangling doesn't match. Look at exactly what names are exported by your dlls, and what the DM executable expects them to be.
>
>

Thank you very much, and I'm sorry for having asked something out of the FAQ.

In article <arlntd$pf6$1@digitaldaemon.com>, Walter says...
>
>The problem is that the compiler generates a name with @4 appended, and the DLL has the name in it without the @4. So, they don't match up. The solution is here:
>
>www.digitalmars.com/faq.html#sysimport