Linking problem on a migrated VC6 Win32 DLL project 
Author Message
 Linking problem on a migrated VC6 Win32 DLL project

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 $#!^.

Any ideas?

--
Roy



Sat, 24 Apr 2004 02:28:21 GMT  
 Linking problem on a migrated VC6 Win32 DLL project



Quote:
> 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



Sat, 24 Apr 2004 02:35:15 GMT  
 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



Sat, 24 Apr 2004 04:58:36 GMT  
 Linking problem on a migrated VC6 Win32 DLL project
Another thread has already mentioned the MFC 7.0 accesses oleacc.dll. No
idea why though...

/Andreas

Quote:
> 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



> > 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




wrote
> 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



Sun, 25 Apr 2004 05:14:20 GMT  
 Linking problem on a migrated VC6 Win32 DLL project
Thanks, guys!

--
Roy


Quote:
> Another thread has already mentioned the MFC 7.0 accesses oleacc.dll. No
> idea why though...

> /Andreas


> > 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


in

> > > 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




> wrote
> > 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



Sun, 25 Apr 2004 21:15:26 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. DLL functions exported with decorated names in a migrated VC6 project

2. Migrating project from Win32 C to Win32 C++

3. Problem linking a VC generated static LIB into a win32 DLL project

4. Compiler warning C4530 in VC6.0 migrated project

5. Compiler warning C4530 in VC6.0 migrated project

6. Problem with linking a VC6 project under Vc7

7. linke erro in MFC project but no link erro in win32 project

8. A bit problem migrating from VC6 to VC7

9. Linking problem: missing .lib file from dll project

10. DLL Linking error (VC project problem)

11. Linking VC6 project with object file of assembly program

12. Linking errors with Win32 Application project

 

 
Powered by phpBB® Forum Software