From: Steve Lee <steve@fu...> - 2002-10-14 13:25:09
I've just done something similar - built my own DLL that uses another
(for which I only had the dll)- see my recent post which gives the
command line I used.
If you use _declspec() in all cases you dont need a .def at all.
Have you actually marked the Convert128 for export in the bottom
level DLL build? If you have then perhaps it is a name mangling problem
with an extra _ being used. Again the thread from my post has some
pointers to this particular mess (sorry but I don't have it here
For this to work you have to: in the bottom level dll mark the symbol
for export and in the top DLL mark it for import. If you have the
source for both you can use _declspec(dllimport) and _declspec(dllexport)
to mark the functions in each case (usually using conditional compilation
to automatically switch between the 2 in a single .h file). You can
also use .def files to direct the linker directly.
The next thing is that when building the top dll the linker must
see the symbol in the bottom dll. I found I could just add the bottom
dll to the command line when building the top dll and the linker
managed to find all the exported the symbols (way cool!). The traditional
way is to use a import library created from the dll which looks like
a plain old static library to the linker. If you have a MSVC generated
implib (foo.lib for foo.dll) you can use the reimp utility to create
a .a file that ld understands (again see the thread)
Hope this isnt too abstract and gives you some pointers.
1)check the symbol is really exported from bottom DLL
2)check the build of the top dll is trying to import the symbol
3)check the build of the top dll links something that tells the linker
about the symbol
and it *should* work :-^
Sorry again I can't give details right now
With this subject, how am I to deduce you're responding to "undefined
reference _imp__dll function call"? PLEASE, if you receive a digest and
respond to one of the items in it, change the Subject to something relative.