Debugging Toolkit Applications on Creo 3.0 Parametric (Error LNK2038)

[MarkStallard]

For the past 5 months have been developing a Creo Parametric Toolkit application on Creo 2.0 using Visual Studio 2010. I write, test and debug my code in a Debug build. When I'm ready to deploy a sample to my testers, I create a Release build. This has been my standard practice for over 10 years.

My company plans to upgrade to Creo Parametric 3.0 M050 by the time I finish this application. For that reason, I decided to switch my development to Creo 3.0, which requires Visual Studio 2012. As is so often the case, the biggest adjustment is linking the code. My Release build seems to link just fine, but the Debug build is another story.  My output window fills with LNK2038 errors like this one:

protk_dll_NU.lib(srcenv.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MTd_StaticDebug' in ConfigFactory.obj

These errors appear for both Creo Parametric Toolkit and OTK C++. ConfigFactory is the name of one of my own C++ classes, and it actually has no dependencies on either Creo toolkit. It just happens to be the first .obj file name in the link command.

The VS2012 linker seems to require all modules to have identical RuntimeLibrary attributes, which presumably means that I need a separate protk_dll_NU.lib file for the Debug build. Unfortunately, the Pro/Tk and OTK libraries all seem to support Release builds only.

Did I make an obvious mistake here? I honestly hope so for my own sake. I need to produce both Debug builds, which I can attach a debugger to, and Release builds, which are smaller and faster than the Debug builds.

|+|  M a r k  |+|

[GabrielZaha]

I'm still on Creo 2 and VS2010 so I'm not sure if this will help but what I would try first is to find where the error is coming from: Creo libraries or Visual studio. For this I'd try to compile the application for Creo 2 but using VS2012 and see if I get the same error. If I get the same error then most likely are the linker option otherwise it should be the Creo libraries

[MarkStallard]

Hi Gabriel -

Thank you for replying to my post.

     [...] I would try first is to find where the error is coming from: Creo libraries or Visual studio.

I know that the problem is "coming from" VS 2012's linker. It expects to see Debug builds of protk_dll_NU.lib and otk_cpp.lib, but those libraries come in Release builds only. I'm also using Boost and Apache Xerces in this project, and I have no link errors with those libraries. I need Debug builds of the PTC libraries, unless someone else can tell me how to persuade VS 2012 otherwise.

     For this I'd try to compile the application for Creo 2 but using VS2012 and see if I get the same error.

I don't need to do that, and I also know what to expect if I did. PTC advises its toolkit customers to use VS 2010 for Creo 2.0 and VS 2012 for Creo 3.0. In the past, I have tried using versions of Visual Studio that are newer than those mandated by PTC. Every time I tried that, Visual Studio would fail to link my program with the older PTC libraries and the newer Microsoft libraries.

What I really need are Debug versions of PTC's toolkit libraries, unless someone knows a suitable workaround.

|+|  M a r k  |+|

[GabrielZaha]

Hmmm ... this doesn't sound like good news. As far as I remember PTC libraries always came as release libraries only but I never had any issues with the Debug builds. Seems like I'll need a lot of planning and testing when we will decide to upgrade.

Just of curiosity: did the pt_install_test project had any issues? Were you able to capture those issues there or only in your project?

[MarkStallard]

Gabriel -

I did not build and run pt_install_test for Creo 3.0. I did, however, review that and other PTC examples following your suggestion. I don't believe the PTC examples will lead me to a solution.

The PTC examples use make (nmake on Windows) to build compile and link C and C++ code. For pt_install_test, there are three makefiles:

• make_install, which builds a single-thread .exe or .dll.
• make_install_cxx, which builds equivalent executables using C++ source code
• make_install_md, which builds a multi-threaded .exe or .dll.

None of these makefiles will compile and link an executable that a debugger can read.

Also interesting to note is that make_install had only one change over the Creo 2.0 version, which was to add the compiler option -D_USING_V110_SDK71_. It still links using protk_dll.lib, which is deprecated according to the Creo 3.0 release notes.

I am alarmed over being unable to debug toolkit applications on Creo 3.0. I will be opening a support call soon.

|+|  M a r k  |+|

[FV · Accepted solution]

Hi all,

Mark,

If you are not using boost the only thing you'll have to do is to change /MTd to /MT for runtime library in the 'Debug' configuration. Creo 3.0 all maintenance releases up to M060 are seems to work fine in Debug and Release configurations with this change.

You'll have to use 'Visual Studio 2012 - Windows XP (v110_xp)' platform toolset (...SDK71...) otherwise your code will not run on Windows 7 machines.

If you are using boost then the VS built-in _DEBUG macro and changing /MTd to /MT will play nasty tricks. In this case you'll either need to build boost libraries for '_DEBUG /MT' variation or undef _DEBUG in a project configuration - I used the later approach, did not want to mess with boost's jam configurator...

HIH.

Feliks.

[MarkStallard]

Before Feliks replied, I opened a support call with PTC on this issue. They replied to me with a Visual Studio 2012 project using OTK C++ with both a Debug and Release build. It was at that point that I discovered the phenomenon that Feliks describes here:

If you are using boost then the VS built-in _DEBUG macro and changing /MTd to /MT will play nasty tricks. In this case you'll either need to build boost libraries for '_DEBUG /MT' variation or undef _DEBUG in a project configuration - I used the later approach, did not want to mess with boost's jam configurator..

I actually was already using /MT (multi-threaded static release), but the linker said I was using /MTd (multi-threaded static debug). It turns out that my Visual Studio project had explicitly defined the _DEBUG preprocessor macro on the compiler command line. The Visual Studio 2012 compiler, see /D_DEBUG, decided that it should silently change /MT to /MTd. The linker then saw my code compiled for static debug and refused to link it with the Creo libraries compiled for static release.

So, does that mean that my Debug build is just a Release build by any other name? Will Visual Studio fail to attach its debugger to this build? Thankfully, no, I can still use the debugger because I selected compiler option /Zi (use "Program Database" for Debug Information Format).

If all this sounds like a brain-cramp, that's because it is. I don't know why Microsoft would force anyone to do this, and this will happen to anyone who develops using a commercial library like Creo Parametric Toolkit or OTK C++.

I'm giving credit to Feliks for the correct answer, but it was PTC's Technical Support who cleared up the problem for me.

|+|  M a r k  |+|

[LarsZiegler]

Hello Mark,

I also have the problem with the _DEBUG preprocessor Definition.

Did you get a feedback of PTC?

Greetings Lars