Puzzling error from std::stringstream in VS2019

[John E]

I'm trying to fix a problem with std::stringstream (in VS2019) which was previously building fine in VS2008. This function appears in my main exe:-

MissingPluginDialog::MissingPluginDialog (Session * s, list<string> const & plugins)
	: ArdourDialog (_("Missing Plugins"), true, false)
{
	/* This dialog is always shown programatically. Center the window.*/
	set_position (Gtk::WIN_POS_CENTER);

	set_session (s);

	add_button (_("OK"), RESPONSE_OK);
	set_default_response (RESPONSE_OK);

	Label* m = manage (new Label);

	std::stringstream sstr;
	sstr << _("This session contains plugins that cannot be found on this system:\n\n");

	m->set_markup (sstr.str ());
	get_vbox()->pack_start (*m, false, false);

	show_all ();
}

The code compiles fine and it even links if I comment out the red lines - but ordinarily, the linker tells me that this use of std::stringstream somehow conflicts with its usage in one of the support DLL's (called libpbd64.dll)

1>libpbd64D.lib(libpbd64D.dll) : error LNK2005: "public: __cdecl std::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> >::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> >(void)"
(??0?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@XZ) already defined in missing_plugin_dialog.obj
1>libpbd64D.lib(libpbd64D.dll) : error LNK2005: "public: void __cdecl std::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> >::`vbase destructor'(void)"
(??_D?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAAXXZ) already defined in missing_plugin_dialog.obj

I visited MSDN and followed the advice about LNK2005 (which told me that I could add /FORCE:MULTIPLE to my linker options). Sure enough that works (it changes the error into a warning) but I don't understand why there's even a warning. This is clearly a local object so surely it can't possibly conflict with an object in some other DLL ??

[2kaud]

I suspect that the class definition for stringstream used in the .dll is different from that used in the .exe. That's probably why it compiles OK with VS2008, but not VS2019. There has been large changes to the std:: files since VS2008.

From msdn:

or two different versions of a standard library to your executable

Simple rule of thumb. Don't use std::classes et al in .dlls. If you have to, make sure that the .dll is compiled with the same compiler/version as that for the .exe. If you don't have source for the .dll, then you ned to get the compiler specific version.

[John E]

Believe it or not - even this produces the same error !!

MissingPluginDialog::MissingPluginDialog (Session * s, list<string> const & plugins)
	: ArdourDialog (_("Missing Plugins"), true, false)
{
	std::stringstream any_name;
}

Yet if I leave the c'tor empty (i.e. I comment out the line std::stringstream any_name;) I don't get the linker error

[2kaud]

yes - probably because of different versions of std::stringstream exe/dll. You can't mix versions! This is the sort of thing that was called 'dll hell'! In the above, std::stringstream default constructor is called.

[John E]

But it's a stack based variable. Why would the linker even care if it was different in a different module (which it shouldn't be in theory - as I built them both using VS2019).

One problem I've reported in a different thread is that VS2019's debugger seems to think my code is linked to the VC runtime 14.27.29110 - when in fact it should be using 14.28.29333 (as that's the only one installed on my system). Back in my old VS2008 days, when linking a DLL or EXE it was possible to add something called a manifest which forced the module to use a specific version of the runtime. Is that still possible? I haven't heard manifests being mentioned for quite a few years.

[2kaud]

If both were built with VS2019, then I don't know. Other than there seems to be something wrong with your VS install. I'd be tempted to completely remove it and re-install from scratch. Have you got any other versions OF VS installed?

[John E]

Have you got any other versions OF VS installed?

Only as toolsets. When I display the Properties dialog for any project, the selected toolset is Visual Studio 2019 (v142). But if I drop down that list, there's also LLVM (clang-cl) which I installed once to evaluate Clang. But there are also 2 other toolset called Visual Studio 2015 (v140) and Visual Studio 2015 - Windows XP (v140_xp) - neither of which I installed deliberately (unless maybe they were needed to support Clang).

[John E]

there are also 2 other toolset called Visual Studio 2015 (v140) and Visual Studio 2015 - Windows XP (v140_xp) - neither of which I installed deliberately

It's just come back to me... when I first installed VS2019 on my latest machine, I needed to use some libs that I'd previously built on a different machine using VS2015. I assumed that it wouldn't be possible to mix & match between old and new compilers (because that was never supported in early versions of MSVC) so I think that must be why I installed the VS2015 toolsets.

But compatibility between old and new compilers has improved over the years and I'm pretty sure I've never needed the VS2015 toolsets (and in any case, I've since rebuilt all thise libs using VS2019). So over the weekend I might try uninstalling them and see if that fixes anything.

[John E]

This morning I uninstalled the VS2015 build tools. I then launched VS2019 and checked that they weren't showing any more (which they weren't). But whenever I try to build any source file now (either a Debug build or a Release build) I get this error:-

7>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\include\yvals.h(12,10): fatal error C1083: Cannot open include file: 'crtdbg.h': No such file or directory

So I bit the bullet and also uninstalled the VS2019 build tools and re-installed them - but I still get the same error!!

If I open the installer and look at the various individual options, there's a section called SDK's libraries and frameworks which has a few dozen entries beginning with "C++" but the only one that's installed is C++ ATL for latest v142 build tools (x86 & x64). Do I maybe need some of the others? Further down, there's an entry called Visual Studio SDK which isn't installed and another called Windows 10 SDK (10.0.19041.0) which isn't installed either.

[2kaud]

Under SDK's, libraries and frameworks - I have:

C++ ATL for latest v142 build tools (x86 & x64)
Windows 10 SDK (10.0.19041.0)

[John E]

Thanks. BTW - I've just found crtdbg.h in this folder:- C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt

I tried adding it to my Windows path but VS2019 doesn't seem to take any notice of it. Is there somewhere within VS2019 where I can either add things to its search path (or at least see which paths are getting searched) ?

[VictorN]

Thanks. BTW - I've just found crtdbg.h in this folder:- C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\ucrt

I tried adding it to my Windows path but VS2019 doesn't seem to take any notice of it. Is there somewhere within VS2019 where I can either add things to its search path (or at least see which paths are getting searched) ?

John, did you try to install the Windows 10 SDK (10.0.19041.0) instead?

[John E]

Just in the middle of doing it... it creates a Windows Restore Point (which seems to be taking a long time for some reason)

[2kaud]

PS Has this fixed the previous error with the debug build with the missing subfolder? [ https://forums.codeguru.com/showthre...th-Debug-build ]

[John E]

Unfortunately 2kaud, I can't tell at the moment (I can't even compile anything yet - let alone debug it)

VictorN - I managed to install the Windows 10 SDK (10.0.19041.0) and if I open a Visual Studio Command Prompt, it's added this folder to my path:-

C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86

But what it hasn't added is the folder which now contains the header files, such as crtdbg.h :-

C:\Program Files (x86)\Windows Kits\10\Include\10.0.19041.0\ucrt

Adding folders to the VS path used to be childishly simple in earlier versions of MSVC - but I'm blowed if I can find a way to do it with VS2019.