warning LNK4049: locally defined symbol Func() imported

I'm getting this warning when compiling a project in VC++ 6.0:

Code:

warning LNK4049: locally defined symbol Func() imported

The MSDN description of the warning says:

Originally Posted by MSDN

The symbol was both exported from and imported to the program.

So I'm wondering what kind of danger it's warning me about, and how to I get rid of the warning?

Are you using "__declspec( dllimport )" on Func()?

gg

No, none that I could find.
I searched all project files for the function and all I found were normal function definitions and declarations using extern.

No wait, I found some function declarations that use a macro infront of them. When I searched for the macro name it's #defined all over the place and sometimes it's defined as:
__declspec(dllexport)
and sometimes as:
__declspec(dllimport)

You typically see something like this in a DLL header...

Code:

#if defined(BUILDING_MY_DLL)
#   pragma message ("Compiling MyApi.DLL")
#   define MY_API __declspec(dllexport)
#else
#   pragma message ("Linking to MyApi.DLL")
#   define MY_API __declspec(dllimport)
#endif

So when you're actually compiling the DLL, you have "BUILDING_MY_DLL" defined. That way, anything decorated with "MY_API" will be exported from the DLL.

When you're compiling something that uses the DLL, you should not have "BUILDING_MY_DLL" defined. So when you include the DLL header, anything decorated with "MY_API" will be imported from the DLL. Then you just have to link with the import library to resolve all those imported symbols.

I only remember getting that linker warning when I wasn't doing the above correctly

gg

Some of the header files I saw did that, but others (like stdafx.h) always export.

Is this warning indicating that there is some kind of problem (i.e. could this break anything), or is it just a reminder that something useless is being done in the code?

Can't say if anything will "break" - maybe not since it's just a warning. Ideally, you'd fix the warning

gg

It will break when you distribute an updated DLL and wonder why the changes aren't picked up. Now that's fun: you distribute a bugfix, but it doesn't fix the bug.

Originally Posted by CornedBee

It will break when you distribute an updated DLL and wonder why the changes aren't picked up. Now that's fun: you distribute a bugfix, but it doesn't fix the bug.

After I replaced the DLL with the new one I built, I'm getting trace errors about not being able to load the DLL... So I'm guessing you're right.

What exactly would cause the changes to not be picked up?

When I look at the old & new DLL with Depends, they have the same functions, except the new one is missing 4 functions that the old one has.

>> What exactly would cause the changes to not be picked up?
Sounds like those functions don't have "__declspec(dllexport)" when building the DLL.

gg