6 replies to this topic

[tazor2012]

I have a third party statically linked .lib including in my static.lib which exposes only 1 API. the client is using MFC and so i had to recompile both those static.lib's wth the MFC with shared dll option and /MD in vs2008.
the client is still experiencing linker issues such as: already defined in msvcrt.lib(MSVCR90.dll) errors
I know my static lib only exports 1 API. however,i have no idea really what the third party lib exports etc. they seem to be suggesting that my lib is exporting other common functions which is conflicting with their system and want me to only export my single API.
I am just not experienced enough to know if this is a configuration issue on their part OR i have to figure out exactly what I am exporting and limiting it somehow when i recompile my static.lib so it does not include those parts which are in common with their system. THus only utilize those parts of the third party lib that i need which is hard as i just link it and use it.
any help or direction in this matter would be apprecaited. i have this fully functional on my end but dont know what to do to make it work on their end. i read somewhere about .def files etc. just not sure what to do here. I have never really worked with .def files before either.

Summary:
third party static lib into my static lib. my static lib has just one api that i let them use. i have no issues on my end but they have the following issues:


the clients response:
Specifically linking is failing due to the fact that the library is statically linking with many libraries common with the larger manufacturing tool chain build. These common library functions are being exported by the library causing the linking conflicts.
In order to resolve this problem the static library can only expose the functions associated with the one API itself in order to guarantee no linking conflicts result. Exported functions can be manipulated when the static library is built using a combination of linker options and module definition (.def file) statements.

the third party was simply stating : Integration of the static lib is failing due to linking errors. Example: ……xyz already defined in msvcrt.lib(MSVCR90.dll)

Edited by tazor2012, 07 September 2012 - 11:07 AM.

[mrbastard]

It sounds like the 3rd party lib is using a different c runtime to your own stuff.

In the project setting, under 'C++'/'code generation', check that they both use the same combination of static/dll, debug/release and single/multithreaded.

Although the lib may only expose a single function, any basic c stuff (including the memory allocator) is provided by the crt.

[tazor2012]

firstly i would like to thank you for your response.

i have created my own dll to test against this code and in order for that to work i had to make sure
i recompiled the third party lib first with the correct options mfc with shared dll and /md
then included it in my lib and recompile / linked it with the same options.
finally i created the test dll which utilizes the static lib with the same options and it works. that is why i am just so confused why they are having this issue.
do you think this is primarily a compiler / linker option? like since they integrating this into their systems perhaps they have some stuff that is not using /md? just curious what your thoughts are because i dont see this issue on my side.
how would i make sure they are using the right CRT all across their platform? how could i troubleshoot this effectively? for example, from the way they mentioned the error it looks like a lnk2005 error? which is usually a linker/compiler option mismatch. what do you think i should do first to ensure this is not on my side and subsequently tell them what?
figured you a senior SW developer and might have an idea.

as far as any basic c stuff are you suggesting that the stuff they are finding common is just crt based really? and ensuring the correct crt is being used will clear that up?

thank you soooo much for your reply in advance!

[mrbastard]

I'm not sure I understand what you're asking now. They have a link error caused by some of their stuff using a different version of the CRT to your lib. They need to use the same version of the CRT throughout. There's no way you can ensure they do this beside standing next to them when they do it and shouting at them when they do it wrong...

What would you do in the case that they were simply mistyping the name of your API function and getting a compile error? This is the same kind of thing - they just need to do it right.

[tazor2012]

how can i determine which version of the CRT i am using for creating my static lib? so the /MD option utilizes which version of the CRT? i was thinking if i shared the version of the CRT i am using they can just build their project with that one.

as i was researching i came across this interesting post...
http://stackoverflow.com/questions/8097733/how-to-distribute-c-run-time-crt-libraries

your thoughts would be highly appreciated. I feel like i am really close to figuring this out.

[mrbastard]

That link talks about distributing the 2008 crt to end users - that's a related problem, but a different one.

They should be able to build a version of your lib using the same crt as they're using for the thing they want to link with the lib. You don't need to distribute anything to them beyond your code - they build it using their usual project settings, all good. Or is the problem that you want to give them your lib but not the source?

This page is a good reference on the relationship between the compiler options and the crt used - note that it's for 2012, but other than the version numbers everything should be the same.

[skarab]

I guess you distribute only the .lib, in this case it's up to you to ensure the CRT version.
Note that for 2008 SP1 there are two CRT versions, this one 9.0.30729.1 and this one 9.0.30729.6161, the latest is part of the MS11-025 hotfix, which is automatically installed in Windows 7 updates, BUT not on windows XP, so you have to make sure your client is using the same OS/stuff.
While it seams ugly, I personally always enforce CRT version when building, it's the only safe way I've found around years.

edit: but it doesn't seems to be your issue for now, maybe you even dont need shared stuff, if it breaks at link time its surely a MD/MT conflict as stated before.

Edited by skarab, 12 September 2012 - 06:37 AM.