Linker error under VC++ .NET between an .exe and a .lib

  • Thread starter Thread starter Igor Kravtchenko
  • Start date Start date
I

Igor Kravtchenko

Hi,

I'm having a pretty idiot problem under VC++ .NET but cannot solve it.
I have an .exe A and a dll B.

A uses some methods of B (so A depends of B).

B exports its methods using __declspec(dllexport) and A imports them using
__declspec(dllimport).

If I manually link A with B, everything works.
If I set a dependency using "Project Dependencies" as I was used under
Visual C++ 6.0 I have a bunch
of link errors.

It seems the "Projet Dependencies" of Visual .NET just sets the order of
build but doesn't explicitly
*links* project to others.

Any remark is welcome,

Igor.
 
I've never used __declspect(dll_import). And setting it through project
dependencies works for me. What I do is have a header file for my DLL project
and just include that. During compilation, the linker just looks through my
LIB file, finds the reference to the function I called, and it's all good.

Have you tried creating a simple 2x project solution and testing it using
only project dependencies and your dll_export/import method?

Best of Luck,
-- Todd Aspeotis
 
Hi,

yes I've created a very simple 2x project to have a school's case.

Linking the .lib explicitly works.
Don't link explicitly but set a project dependencies fails although the
project build order is correct.

Crazy...

Igor.
 
The funny thing is when I add /VERBOSE:LIB to find out what libraries the
linker searchs I don't see my "b.lib".

Igor.
 
Ok, I think I've found the problem.

The link dependencies seems to behave extremely weirdly on multi drives.
Indeed in my previous example the generated file was on c:\ whereas
the project was on d:\.

Putting all on the same drive solves the problem.

Igor.
 
Igor said:
Ok, I think I've found the problem.

The link dependencies seems to behave extremely weirdly on multi drives.
Indeed in my previous example the generated file was on c:\ whereas
the project was on d:\.

Putting all on the same drive solves the problem.

Igor.
Click to expand...
If one of the dxrives is FAT with it's 2 second resolution in time
stamps and the other is NTFS, that is one reason why this might happen.
If both are NTFS, we would love to see a repro case (and that repros
after a clean build).

Ronald Laeremans
Visual C++ team
 
Both are FAT32.
The funny thing is it doesn't work only my system.
At work, I have pretty the same PC but there, it works.

Crazy...

Igor.
 
Back
Top