0

I am sharing a static lib with a client. it is using vs2008 sp 1.

i am using a third party lib which i built with the mfc with shared dll and /MD option release version

I then built my own static lib which includes this third party lib with MFC with shared dll option and /MD release version.

i created a test dll to just make sure it work. no issues runs fine. I am not using MFC at all. only the client is that is why they told me to use MFC with shared dll and /MD.

now they are complaining that they are getting

xyz already defined in msvcrt.lib(MSVCR90.dll) errors. these look like LNK2005 errors i think.

they are stating the following:

"Specifically linking is failing due to the fact that "my library" is statically linking with many libraries common with the larger manufacturing tool chain build. These common library functions are being exported by the "my library" causing the linking conflicts.

furthermore they state:

"In order to resolve this problem the "my library" can only expose the functions associated with the single API (from my static lib) itself in order to guarantee no linking conflicts result. Exported functions can be manipulated when the "my library" is built using a combination of linker options and module definition (.def file) statements"

I am not sure what could cause this issue. this is not a problem on my end but there. I am thinking maybe they are having issues using incorrect options or the wrong CRT version?

also, I am not sure i can comply with their request of maybe not linking with msvcrt.lib(MSVCR90.dll) as my static lib does rely on standard c functions etc.

i am pretty lost at the moment, i did research a couple of links How to distribute C run-time (CRT) Libraries

and

http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/

but if what is stated in the link the issue with the CRT then i am not sure how to figure out what CRT i am using my static lib in vs2008. i have used /verbose to see it but it does not work. and i know dumpbin or dependency walker will not cut it for a static lib.

Been struggling with this for a few days and have researched like crazy. no answers as to why they could be having issues with msvcrt.lib(MSVCR90.dll).

Community
  • 1
  • 1
Dave Powell
  • 671
  • 5
  • 14
  • 26
  • 4
    His setting doesn't match yours, he's compiling his program with /MT instead of /MD – Hans Passant Sep 12 '12 at 00:00
  • how are you able to tell that? any ideas? – Dave Powell Sep 12 '12 at 00:22
  • 1
    Psychic powers. The error message helps a bit too. – Hans Passant Sep 12 '12 at 00:24
  • well from what i read /mt uses LIBCMT.lib whereas /md uses MSVCRT.lib. However, since the message they provided i guess was not complete as in i did not see any reference to LIBCMT.lib i could not make the connection. just explaining my thought process. probably is messed up. but i guess you are saying if they are having issues with msvcrt.lib(MSVCR90.dll) then it means they are using /MT? – Dave Powell Sep 12 '12 at 00:30

1 Answers1

0

Get the names of the conflicting libraries from their error messages. Add the names of these libraries to your static lib's project settings (in the linker settings i believe). There should be a line for "ignore libraries," this is where you should add the library names. Make sure your project compiles and your tests pass. Then send them your newly compiled static lib and see if they still have conflicts. If they do, get the names of the conflicting libraries and repeat the process.

this and similar fixes are described here: http://support.microsoft.com/kb/148652

You might try adding MFC support to your project to try to expose the conflicts locally in your development environment; i bet that would cause you the same errors they are getting. It happens when the C runtime and MFC libraries link out of order.

ryan0
  • 1,482
  • 16
  • 21
  • Actually i think this is just a project setting, as Hans Passant was saying. You (or they) need to play with the C++/Code Generation/Runtime Library setting, as described here: http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx – ryan0 Sep 12 '12 at 04:56
  • how do you know which is it really then? because this article you mentioned seems like a plausible issue....now i am confused can you tell me your reasoning please so i know for the future? thanks – Dave Powell Sep 12 '12 at 04:59
  • Create your test dll using MFC like your client, so that you can reproduce their errors locally. Then play with the aforementioned setting until you no longer get linker errors. – ryan0 Sep 12 '12 at 05:08
  • This kind of issue (in visual studio) is usually fixed by including static libraries in specific orders, or ignoring them in static libraries i am including, etc. When it deals with a unique library or symbol, the technique described in my answer should be followed. But when it's something like the c-runtime library (as in this case), that has "project settings" written all over it, because that's such a widely used library. In other words, the problem is more basic than i first thought. The proper project settings should fix it. You might have to recompile all of them to find the issue. – ryan0 Sep 12 '12 at 05:18
  • i appreciate the detailed response. i will make a mfc dll anyway i guess to check it out. i dont have any exp with it however but i can't imagine it would be hard. on the flip side the client issue as of right now is project setting related at least based on what they are stating. – Dave Powell Sep 12 '12 at 05:55