How to get rid of linker warning ? (LNK4089: OLEAUT32.DLL)

[OReubens]

If you create a new MFC based project, using MFC as DLL, and compile the release build, you end up getting following error:

LINK : warning LNK4089: all references to 'OLEAUT32.dll' discarded by /OPT:REF


Is there a way to get rid of the warning ? I've tried adding OLEAUT32.lib to the 'Ignore specific library' linker settings, but then you end up getting another error (giving the impression that OLEAUT32.DLL is needed, although it isn't).

mfcs71.lib(stdafx.obj) : error LNK2019: unresolved external symbol __imp__SysFreeString@4 referenced in function "public: __thiscall ATL::CComBSTR::~CComBSTR(void)" (??1CComBSTR@ATL@@QAE@XZ)


I realise "it's just a warning". But I really want to get rid of it.

[bumbobway]

Tell the linker to ignore it by adding the /IGNORE:4089 switch to the linker command line from the Project->Settings dialog

[JohnCz]

Either in your project or any import library there is a reference to OLEAUT32.dll.
Your program does not need it so linker discarded all. This only informational message, nothing to worry about.

[OReubens]

Tell the linker to ignore it by adding the /IGNORE:4089 switch to the linker command line from the Project->Settings dialog

Unfortunately this won't do. This'll ignore ALL LNK4089 errors, which isn't what I want. I still want to be able to get warned about other libraries thay may be linked unnecessarily.

Either in your project or any import library there is a reference to OLEAUT32.dll.

The reference seems to be in the MFCS71.lib. Which I need (because I need MFC), but I don't need OLEAUT32.DLL. There is no reference in code which is under my control.
C'mon EVERYONE making MFC programs with .NET 2003 must have this very same 'problem'.

Your program does not need it so linker discarded all. This only informational message, nothing to worry about.

I know it's informational, but it's annoying for one (because it ends up in the Tasks list).
And our dev. requirements contract insists that all code be compiled at warning level 4 and should have _NO_ warnings.

An /IGNORE would do if it could be made to ONLY ignore the OleAut32.DLL, if it ignores all, we have a problem.

[JohnCz]

Obviously, as you noted ignoring OleAut32.DLL since that will produce link error.

If this is really a big problem, try to create reference in your program, for example calling SysAllocString. That should satisfy linker and avoid annoying warning.

[OReubens]

That's not a good solution either since that will needlessly increase the workingsetsize of all the MFC based programs

[JohnCz]

Originally posted by OReubens
That's not a good solution either since that will needlessly increase the workingsetsize of all the MFC based programs

?????????????

[OReubens]

if I add some 'dummy' code to force a usage of oleaut32.dll, even though my program doesn't need oleaut32.dll, that will cause OLEAUT32.dll to be loaded into the process space of each MFC program that does that.

This will increase the amount of memory each of those exe's will need.

Forcing a load of a DLL you don't really need is just plain stupid.

[JohnCz]

I think you should do some more reading about basic concepts of a DLLs. The whole idea is to save memory by using DLL

DLLs are mapped into virtual memory of the process while one instance is occupying physical memory.

As for reading this will be good for starters I think:
Advantages of Using DLLs
Differences Between Applications and DLLs
About Dynamic-Link Libraries

Now another topic. I do not know how much weight you put into simple expression "just plain stupid".
I think using it to answer post of somebody who is trying to help (voluntarily) is just plain stupid (using yours expression), even if post was not right (and that is not a case). Is it normal in Belgium, Europe or is it just you?

Everybody is in title to express own opinion about topic and that is what this forum is about – discussion based on some tangible facts. Insults are not why we are here.

By the way just plain stupid was used to describe ideas like electricity, steam engines, phone, laser and space travel.

[OReubens]

I think you should do some more reading about basic concepts of a DLLs. The whole idea is to save memory by using DLL

Sigh... No I don't. I have been teaching advanced classes in Project management, Debugging, Assembly language (multiple CPU's), Optimisation (Windows specific and otherwise), multithreading and some other 'high level' topics. I know pretty much all there is to know about how DLL's work in Windows (and the differences of how DLL's work in Win 95/98/ME vs NT/2000/XP)

I just can't figure out how to get rid of this darned warning. The end result is the exe's don't need the DLL, but if you exclude the DLL the linker DOES think it needs it. ARGH !

Insults are not why we are here.

I didn't call YOU stupid. I didn't intend to insult you, if you feel that is what happend, ok, I appologise.


It is the act of loading a DLL you don't need that I called stupid.
- It adds to the processes footprint/memory size. This can be a big deal if your program needs to handle a lot of memory.
- It takes time to load the DLL, granted, negligeable if it's already loaded by some other process.
- Loading a DLL DOES take memory. While most of the DLL just gets mapped, there is always some bit of data involved.

Avoiding to load DLLs is one of the 'big issues' I really have to hammer out in my classes on optimisation. People have so many misconceptions about DLL's.

If you have (a lot of) similar code across many processes, then YES DLL's are a better choice than staticaly linked libraries. But if you can make do without the DLL that is by far a much better choice.
If all you need is one little function out of a DLL, then you end up adding a lot of overhead.
Here I need nothing out of the DLL. Loading it is all overhead. Not a very smart solution just to get rid of a warning message.

[JohnCz]

Originally posted by OReubens
Sigh... No I don't. I have been teaching advanced classes in Project management, Debugging, . . .

Sigh.
Teachers were teaching that the Earth is flat and that the Earth is in the center the Universe. Would you trust me if I told you that there are people who still believe that is true?

Originally posted by OReubens
I just can't figure out how to get rid of this darned warning. The end result is the exe's don't need the DLL, but if you exclude the DLL the linker DOES think it needs it. ARGH !

And you will not be able to, using conventional method.
If your customer is so concern about so called "clean build" and does not understand that this message is simply informal you will have to use unorthodox approach.

Are you really concern about a little chunk of memory taken from 4GB (2GB for application) of virtual memory? I think the answer is YES.

Well, have you thought about delayed loading of DLLs? Here you go.
Also you can call explicitly call LoadLibrary. Here you go again.
Unless you can think about something else, place any call to OLEAUT32.DLL; this can be done at the very end of application (PostNCDestroy for that matter). It would cause linker to shut up. You will not betray your DLL loading principals.

Remember I am just trying to help. Good Luck.

P.S.
Where I am coming from there is neither stupid questions nor stupid ideas. Ideas may be crazy, and do not have to be used or implemented.
And there are always some stupid answers. I am not referring to your post – just general remark.

[OReubens]

Teachers were teaching that the Earth is flat and that the Earth is in the center the Universe. Would you trust me if I told you that there are people who still believe that is true?

Oh there's one of two of those believers in each class. Hence the 'hammering' I was referring to ;-). It's not usually about the earth being flat. But there are so many misconceptions floating about that just don't seem to go away.
Some of the were true once, when dinosaurs still roamed the earth and computers were bigger than a T-Rex and had 4K of memory. But there're completely obsolete on more modern computers.

If your customer is so concern about so called "clean build" and does not understand that this message is simply informal you will have to use unorthodox approach.

There are various reasons as to why getting rid of the warnings is a big issue. I _ALWAYS_ compile at warning level 4, and I never leave any of the warnings there. They're there for a reason, and half the time, ignoring them will actually cause a bug in your code. It takes a little effort to get a clean compile (and link), but you get a much better grasp of the code you're writing (or modifying).
I Agree that the linker warning is somewhat less of an issue, but still... it's annoying, because the whole solution build now ends in 'outstanding tasks' being reported.
If there is no other solution than /IGNORE:4089 available, I can add an 'exception' to the project production report, but it's not a good idea to have too many exceptions :-)

Are you really concern about a little chunk of memory taken from 4GB (2GB for application) of virtual memory? I think the answer is YES.

Most definately. Several of the executables are already running on fewer memory than is optimally required. But 2Gb is all there is. We have already pointed out they (the customer) should really consider porting the entire solution to a Win64 platform.

Well, have you thought about delayed loading of DLLs? Also you can call explicitly call LoadLibrary

Sure we have, and something like delayloading this was already in place since before MS decided to provide the feature as part of the compiler/linker features.
I really hate the fact that with .NET MS is forcing us to list the delay loaded libraries in the project settings, and no longer offerring the posibility for using
#pragma comment(linker, "/delayload:Mylib.dll")
;-( ;-(

The problem is that for some of the more memory hungry exe's, we can't do this because we can't assure there will be a big enough spot of memory left for the dll to load in, so we HAVE to load everything up front.
We're being thrown back to this project because some of the exe's wouldn't run on XP due to 'out of memory' problems. Windows XP adds a whole lot more DLL's (and bigger DLLs) into the memory space of a process. We had to cut some of the features (so we could drop some of the DLL's) to make things still work.
(and no we can't do anything about the other memory consumption, that is already strained as it is) ;-)

[XamKan]

Tell the linker, to allow functions and/or data that are never referenced, by adding the '/OPT:NOREF' switch, to the linker command line, from the Project->Settings dialog.

[krebstar]

Sorry to revive such an old topic, but did the last solution work? What are the implications of adding this /OPT:NOREF switch? Does it just turn off the warnings or does it actually remedy the problem of the original poster?

Thanks..

[BruceDawson]

Using /OPT:NOREF to get rid of this warning is a bad idea. One might even call it stupid. It will make your executable larger (sometimes a lot larger) and offers no real value.

Forcibly bringing in the DLL by calling one of its functions is also a bad idea. One might even call it stupid. It will increase your load time and offers no real value. Yes, the load time increase is probably not significant, but this solution is just ugly. Why should an innocuous linker warning be fixed by something so illogical?

The correct solution is /ignore:4089. The linker warning has zero value for most people. I have never found it to give me useful information. When using libraries it is quite normal and healthy for a library function to reference a DLL. If I don't call that library function then that DLL is not needed, so the linker should remove all references to that DLL. This is all good and normal -- the only problem is that the linker brags about what a great job it is doing.

I believe that this warning was removed from VC++ 2008, so upgrading to the latest version of VC++ is another option. This also indicates that Microsoft agrees that the warning should be ignored.

So there you have it: either use /ignore:4089 or upgrade to VC++ 2008.