Library Conflict

[mattsdad]

I have developed System-A and System-B with a common library of routines which are grouped in to Common_Module. As these systems have matured, I am now required to integrate them together. System-B has been prepared as an API with an interface and a linkable library (System-B.lib). System-A uses System-B.lib.

The common libraries are causing linkage problems. When I leave the code in Common_Module, the link error reads:
_COMMON_MODULE_mp_ROUTINE@8 already defined in System-A.lib (a project in the System-A solution)

If I change the code to interfaces in System-A, the link error reads:
Unresolved external symbol _ROUTINE@8

Is there a way to resolve this simply?

[Steven_L_Intel1]

I assume you are using Visual Studio and are also making System-A dependent on the System-B project. That is fine. The problem you run into is that Visual Studio is merging the contents of System-B.lib into System-A.lib. You can choose to let this happen and then just use System-B.lib (no need for System-A.lib when linking), or, and this is new in version 11, go to the Librarian property page of System-B.lib and set the property "Link library dependencies" to No.

As for changing the code and getting a different symbol, that means that you're no longer seeing the module definition of ROUTINE and the call is being treated as a normal external.

[mattsdad]

Quoting - Steve Lionel (Intel)

As for changing the code and getting a different symbol, that means that you're no longer seeing the module definition of ROUTINE and the call is being treated as a normal external.

When I had the code in the module I needed the CONTAINS keyword, but when the code was changed to interfaces, the compiler wanted the CONTAINS keyword removed. When I did that the symbols for the routines changed.

Is there a work-around to removing the keyword?

[Steven_L_Intel1]

Ok. If you made these procedures no longer contained routines, then the _mp_ symbol is not correct. Do a Build > Rebuild Solution to see if that takes care of the problem.

[mattsdad]

Quoting - Steve Lionel (Intel)

Ok. If you made these procedures no longer contained routines, then the _mp_ symbol is not correct.

Sorry if that was not clear. None of the procedures ever contained otherroutines. It is the module that they are in that has the CONTAINS keyword with all the library's procedures following. When all the procedures are condenced down to interfaces, the compiler requires the CONTAINS keyword to be removed. The linker then recognizes the procedure names as external to the module and looks for them without the module name prepended.

Is there a simple work around for this? (using interfaces that are still recognized as part of a module)

[Steven_L_Intel1]

I was referring to procedures contained in a module.

If you have procedures after a CONTAINS, then their global names will be of the form MODNAME_mp_ROUTINENAME. You say you have removed those procedures and create INTERFACE blocks for them instead. (I assume the code for these procedures are somewhere else.) That makes them ordinary, non-module external procedures so the MODNAME_mp_ prefix is not used. If you USE the module containing the interface, the caller should get the right name.

What exactly is the problem you're trying to solve?

[mattsdad]

I am trying to compile System-A and link it with the System-B.lib which has the common library.

[Steven_L_Intel1]

Did you try my suggestion about "link library dependencies"?

[mattsdad]

Quoting - Steve Lionel (Intel)

Did you try my suggestion about "link library dependencies"?

No, because the main routine is actually in C++ and the libraries eachcontainsabout 200and500 other routines that are necessary for the system to work.

I have a work-around. I renamed the common library in one of the systems. That allows the link to proceed eventhough the executable has the common routines in there twice.

Thanks for your suggestions.