Mixing VF 6.6 + VF 8.0 + VS C in one grand project

[bsoplinger]

Due to circumstances beyond my control, I need to build a mixed (very mixed) language project. Its primarily a .Net 2003 C project with some Fortran number crunching. These parts can all be done with VF 8.0 and .Net 2003. Unfortunately I also need to link in some other Fortran built with VF 6.6 into the mix. These VF 6.6 are static .lib files but may change to .dll in the future.

What problems should I be on the lookout for with a mix like this? I'm producing multithreaded .dll's if that makes a difference.

[Steven_L_Intel1]

This is just not going to work with static libraries, due to incompatibilities between the run-time libraries. If you can manage to build a DLL of the CVF code, you can isolate the problem and it should work.

[bsoplinger]

>>>
This is just not going to work with static libraries, due to incompatibilities between the run-time libraries.
>>>

Is this just a 'standard reply' or is this a hard and fast thing? Ie, can I bite the bullet, do something unsupported and maybe it'll work or am I just asking for a world of hurt?

Am I correct in assuming if I were to go the 'make a dll' route, I'd need to have a copy of those CVF dll's available to every user who'd be using my resulting program? That is there isn't a way to 'include' the dll into my resulting program?

(I'm more of a Unix person and on those systems its possible to force the inclusion of shared library code into an executable and not use the shared library as shared and I'm asking if there's a WIN equivalent operation)

[Steven_L_Intel1]

It's not "a standard reply" because it's not a common thing to do. I don't give "boilerplate" replies.

The problem is that the CVF library and the IVF library have many routines of the same names (no wonder, since they're related), but they are not interchangeable. If you try to link such an application, at best you'll get "multiple definition" link errors and at worst the application will fail in bizarre ways at run-time.

The only hope of this working is if the library is all computational code and makes NO calls to the CVF run-time library.

Yes, you can build a DLL that builds in all the library support - that's a good approach. You would do this by specifying /libs:static when building the DLL (the default is /libs:dll).

[g_f_thomas]

Let me preface my suggestion with two remarks:

1. Steve knows more than he's revealing so I'd take his advise seriously.
2. I don't quite understand your constraints but here's what I'd try (YMMV, so buckle up and brace yourself).

a. Rename the CVF link.exe to Oldlink.exe.

b. Copy IVF link.exe and mspdb71.dll to

..Program FilesMicrosoft Visual StudioVC98Bin.

c. Rebuild your CVF .lib. The linker will snivel:

warning LNK4224: /PDBTYPE is no longer supported; ignored

d. Go to IVF, ensure that it can find the newly built CVF .lib, and rebuild the solution.

Good Luck,
Gerry T.