Linking problem on a migrated VC6 Win32 DLL project
It may be that none are called directly (explicitly) by you, but something
in your code IS in fact referencing (if possibly not calling) those entry
points.
The next step I'd take is to do dumpbin /symbols on all of your .OBJ files
and search the output (it's lengthy) for the names of those functions. That
will tell you which module(s) are referencing them. Then you just need to
pour through the code to find the reference. Since you're not calling them
explicitly, there are a couple possibilities:
1. Something that you're calling which is itself implemented in a static
library is the source of the calls. If that's the case, dumpbin /symbols on
your OBJs should turn up nothing.
2. A macro which you've used calls these functions in it's implementation.
-cd
Quote:
> Carl,
> Thanks for your reply -- bare with me if you will...
> The output of dumpbin is attached. In it I see the following:
> OLEACC.dll
> 1001C26C Import Address Table
> 100210A4 Import Name Table
> 0 time date stamp
> 0 Index of first forwarder reference
> 13 LresultFromObject
> 4 CreateStdAccessibleObject
> None of those are called by my project. If one of the other system DLLs
had
> this DLL linked, would it cause it to show in the dumpbin output? Would
> using DELAYLOAD on this DLL make a difference at all?
> FWIW, the code did not change since its last compilation in VC6. I simply
> migrated the project and re-compiled under VC.Net (rc)
> --
> Roy
in
> > > Dependency Viewer shows me that oleacc.dll is linked to my DLL,
however,
> I
> > > do _not_ need it, nor did I explicitly specify this lib in my link
> > options.
> > > I cannot find an option to exclude this module, and since I am
deploying
> > to
> > > Win95 clients (that do not have this DLL), I am now in deep $#!^.
> > Use dumpbin /imports against your DLL to find out what function in
> > oleacc.dll you're using (you're using something - you just don't realize
> > it!).
> > -cd
