www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - VisualD and VS2012

reply Manu <turkeyman gmail.com> writes:
Who here uses VisualD under VS2012?

I just installed 2012 and tried it out, I'm having some strange problems
that I don't seem to have under VS2010.
So, the trouble scenario is when I try and link a C++ lib against a VisualD
project.
I set the C++ lib project as a dependency of the D executable project in
the solution dependencies, and then it tries to link, but there are
problems:

1>libcpmtd.lib(xthrow.obj) : error LNK2038: mismatch detected for
'_MSC_VER': value '1600' doesn't match value '1700' in
Fuji_Debug.lib(MFPrimitive_Plug.obj)
1>   Creating library .\FeedBack_Debug.lib and object .\FeedBack_Debug.exp
1>Fuji_Debug.lib(pngerror.obj) : error LNK2001: unresolved external symbol
__report_rangecheckfailure
1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved external
symbol "void __cdecl std::_Xbad_alloc(void)" (?_Xbad_alloc std  YAXXZ)
referenced in function "char * __cdecl std::_Allocate<char>(unsigned
__int64,char *)" (??$_Allocate D std  YAPEAD_KPEAD Z)
1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved external
symbol "char const * __cdecl std::_Syserror_map(int)" (?_Syserror_map std
  YAPEBDH Z) referenced in function "public: virtual class
std::error_condition __cdecl
std::_System_error_category::default_error_condition(int)const "
(?default_error_condition _System_error_category std
  UEBA?AVerror_condition 2 H Z)
1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved external
symbol "char const * __cdecl std::_Winerror_map(int)" (?_Winerror_map std
  YAPEBDH Z) referenced in function "public: virtual class
std::basic_string<char,struct std::char_traits<char>,class
std::allocator<char> > __cdecl
std::_System_error_category::message(int)const " (?message 
_System_error_category std  UEBA?AV?$basic_string DU?$char_traits D std 
 V?$allocator D 2  2 H Z)
1>libcpmtd.lib(stdthrow.obj) : error LNK2019: unresolved external symbol
_CrtDbgReportW referenced in function "void __cdecl
std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)"
(?_Debug_message std  YAXPEB_W0I Z)
1>.\FeedBack_Debug.exe : fatal error LNK1120: 5 unresolved externals

Linking the exact same .lib file against a C++ exe project, there is no
problem, so this only occurs when linking to a VisualD built exe.
I suspect that VisualD is either executing the VS2010 linker, even though
I'm running VS2012, or maybe it's trying to link the VS2010 libs instead of
the 2012 libs?

I suspect it's yet another one of those 'paths are all confused' problems,
where the issue lies somewhere between sc.ini and VisualD's overrides...
but maybe not?

Anyone with experience on this?
Rainer?
Jan 21 2014
next sibling parent "Bigsandwich" <bigsandwich gmail.com> writes:
Yeah, looks like its linking the 2010 runtime:

http://stackoverflow.com/questions/70013/how-to-detect-if-im-compiling-code-with-visual-studio-2008

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

On Tuesday, 21 January 2014 at 09:38:31 UTC, Manu wrote:

 Who here uses VisualD under VS2012?

 I just installed 2012 and tried it out, I'm having some strange 
 problems
 that I don't seem to have under VS2010.
 So, the trouble scenario is when I try and link a C++ lib 
 against a VisualD
 project.
 I set the C++ lib project as a dependency of the D executable 
 project in
 the solution dependencies, and then it tries to link, but there 
 are
 problems:

 1>libcpmtd.lib(xthrow.obj) : error LNK2038: mismatch detected 
 for
 '_MSC_VER': value '1600' doesn't match value '1700' in
 Fuji_Debug.lib(MFPrimitive_Plug.obj)
 1>   Creating library .\FeedBack_Debug.lib and object 
 .\FeedBack_Debug.exp
 1>Fuji_Debug.lib(pngerror.obj) : error LNK2001: unresolved 
 external symbol
 __report_rangecheckfailure
 1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved 
 external
 symbol "void __cdecl std::_Xbad_alloc(void)" 
 (?_Xbad_alloc std  YAXXZ)
 referenced in function "char * __cdecl 
 std::_Allocate<char>(unsigned
 __int64,char *)" (??$_Allocate D std  YAPEAD_KPEAD Z)
 1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved 
 external
 symbol "char const * __cdecl std::_Syserror_map(int)" 
 (?_Syserror_map std
   YAPEBDH Z) referenced in function "public: virtual class
 std::error_condition __cdecl
 std::_System_error_category::default_error_condition(int)const "
 (?default_error_condition _System_error_category std
   UEBA?AVerror_condition 2 H Z)
 1>Fuji_Debug.lib(ReadAssImp.obj) : error LNK2019: unresolved 
 external
 symbol "char const * __cdecl std::_Winerror_map(int)" 
 (?_Winerror_map std
   YAPEBDH Z) referenced in function "public: virtual class
 std::basic_string<char,struct std::char_traits<char>,class
 std::allocator<char> > __cdecl
 std::_System_error_category::message(int)const " (?message 
 _System_error_category std  UEBA?AV?$basic_string DU?$char_traits D std 
  V?$allocator D 2  2 H Z)
 1>libcpmtd.lib(stdthrow.obj) : error LNK2019: unresolved 
 external symbol
 _CrtDbgReportW referenced in function "void __cdecl
 std::_Debug_message(wchar_t const *,wchar_t const *,unsigned 
 int)"
 (?_Debug_message std  YAXPEB_W0I Z)
 1>.\FeedBack_Debug.exe : fatal error LNK1120: 5 unresolved 
 externals

 Linking the exact same .lib file against a C++ exe project, 
 there is no
 problem, so this only occurs when linking to a VisualD built 
 exe.
 I suspect that VisualD is either executing the VS2010 linker, 
 even though
 I'm running VS2012, or maybe it's trying to link the VS2010 
 libs instead of
 the 2012 libs?

 I suspect it's yet another one of those 'paths are all 
 confused' problems,
 where the issue lies somewhere between sc.ini and VisualD's 
 overrides...
 but maybe not?

 Anyone with experience on this?
 Rainer?
Jan 21 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 1:38 AM, Manu wrote:

 I suspect that VisualD is either executing the VS2010 linker, even though I'm
 running VS2012, or maybe it's trying to link the VS2010 libs instead of the
2012
 libs?


This should be easy to verify one way or the other. Check the paths in the 
config files. Worst case, delete the VS2010 libs and executables (or simply 
rename the directory they're in).
Jan 21 2014
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2014 08:33, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/21/2014 1:38 AM, Manu wrote:


 I suspect that VisualD is either executing the VS2010 linker, even though
 I'm
 running VS2012, or maybe it's trying to link the VS2010 libs instead of
 the 2012
 libs?


 This should be easy to verify one way or the other. Check the paths in the
 config files. Worst case, delete the VS2010 libs and executables (or simply
 rename the directory they're in).


It's not so simple, because VisualD attempts to override the paths in the
config files, it gets complicated and I have no clear view where the paths
used actually come from.
The reason is, it's common to have many versions of Visual Studio installed
in parallel on the same machine, so while working with VisualD, the
libs+linker that DMD should be using is the one that belongs to the *active
VS environment*; sc.ini should be ignored, it is only configured for one
particular VS upon installation, so it's wrong every time you change
environment (often).

Perhaps the problem here is that sc.ini isn't being ignored; it seems to be
configured to point to VS2010...
...yes, seems to be the case. I amended my sc.ini file to point to the
VS2012 stuff and it works much better. Only one link error:

1>libcpmtd.lib(stdthrow.obj) : error LNK2019: unresolved external symbol
_CrtDbgReportW referenced in function "void __cdecl
std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)"
(?_Debug_message std  YAXPEB_W0I Z)

Strange.. I wonder where that's supposed to come from :/

So, VisualD should be ignoring sc.ini as I understand it, but it seems that
it's not... Rainer?
Jan 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 5:09 PM, Manu wrote:

 It's not so simple,  because VisualD attempts to override the paths in the
config
 files, it gets complicated and I have no clear view where the paths used
 actually come from.


VisualD cannot find files that are not there - so remove those files, and then 
see what happens.
Jan 21 2014
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2014 11:16, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/21/2014 5:09 PM, Manu wrote:


 It's not so simple,  because VisualD attempts to override the paths in
 the config

 files, it gets complicated and I have no clear view where the paths used
 actually come from.


 VisualD cannot find files that are not there - so remove those files, and
 then see what happens.


I'm not sure what you mean... remove sc.ini?
VisualD doesn't appear to be doing any magic (although it should). It's
just taking the usual paths from sc.ini verbatim. This would seem to be the
problem.
Jan 21 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 5:24 PM, Manu wrote:

 On 22 January 2014 11:16, Walter Bright <newshound2 digitalmars.com
 <mailto:newshound2 digitalmars.com>> wrote:

     On 1/21/2014 5:09 PM, Manu wrote:

         It's not so simple,  because VisualD attempts to override the paths in
         the config

         files, it gets complicated and I have no clear view where the paths
used
         actually come from.


     VisualD cannot find files that are not there - so remove those files, and
     then see what happens.


 I'm not sure what you mean... remove sc.ini?



I mean remove these files: "I suspect that VisualD is either executing the 
VS2010 linker, even though I'm running VS2012, or maybe it's trying to link the 
VS2010 libs instead of the 2012 libs?"

That would clear up the suspicion and the maybes.
Jan 21 2014
parent reply Manu <turkeyman gmail.com> writes:
On 22 January 2014 12:45, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/21/2014 5:24 PM, Manu wrote:


 On 22 January 2014 11:16, Walter Bright <newshound2 digitalmars.com

 <mailto:newshound2 digitalmars.com>> wrote:

     On 1/21/2014 5:09 PM, Manu wrote:

         It's not so simple,  because VisualD attempts to override the
 paths in
         the config

         files, it gets complicated and I have no clear view where the
 paths used
         actually come from.


     VisualD cannot find files that are not there - so remove those files,
 and
     then see what happens.


 I'm not sure what you mean... remove sc.ini?



 I mean remove these files: "I suspect that VisualD is either executing the
 VS2010 linker, even though I'm running VS2012, or maybe it's trying to link
 the VS2010 libs instead of the 2012 libs?"

 That would clear up the suspicion and the maybes.


I don't think there's any maybe's about it, I amended sc.ini to point to
the VS2012 paths instead of the original 2010 paths, and VisualD
immediately started working fine within VS2012 (except for the CRT problem
I bugged separately).
Are you suggesting I; revert sc.ini to its original VS2010 configuration,
then remove the VS2010 paths so VD can't find it, and see if it then tries
the 2012 paths as a fallback?
Jan 21 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 7:05 PM, Manu wrote:

 I don't think there's any maybe's about it, I amended sc.ini to point to the
 VS2012 paths instead of the original 2010 paths, and VisualD immediately
started
 working fine within VS2012 (except for the CRT problem I bugged separately).
 Are you suggesting I; revert sc.ini to its original VS2010 configuration, then
 remove the VS2010 paths so VD can't find it, and see if it then tries the 2012
 paths as a fallback?


I was only suggesting ways to verify which linker it was executing and which 
libraries it was linking against.
Jan 21 2014
prev sibling parent reply "Rainer Schuetze" <r.sagitario gmx.de> writes:
On Wednesday, 22 January 2014 at 01:25:07 UTC, Manu wrote:

 On 22 January 2014 11:16, Walter Bright 
 <newshound2 digitalmars.com> wrote:


 On 1/21/2014 5:09 PM, Manu wrote:


 It's not so simple,  because VisualD attempts to override the 
 paths in
 the config

 files, it gets complicated and I have no clear view where the 
 paths used
 actually come from.


 VisualD cannot find files that are not there - so remove those 
 files, and
 then see what happens.


 I'm not sure what you mean... remove sc.ini?
 VisualD doesn't appear to be doing any magic (although it 
 should). It's
 just taking the usual paths from sc.ini verbatim. This would 
 seem to be the
 problem.


You can see all the environment changes and executed command in 
the cmd-file in the output directory (or just click the link to 
the log shown in the output window).

One problem might be that the C object files that are part of the 
phobos library are forcing the inclusion of the library "LIBCMT" 
(and "OLDNAMES"), and this probably doesn't mix very well with 
the debug version LIBCMTD.

Maybe you can add a command line option to ignore LIBCMT for 
debug builds with /NODEFAULTLIB:LIBCMT
Jan 22 2014
parent Manu <turkeyman gmail.com> writes:
On 23 January 2014 08:38, Rainer Schuetze <r.sagitario gmx.de> wrote:


 On Wednesday, 22 January 2014 at 01:25:07 UTC, Manu wrote:


 On 22 January 2014 11:16, Walter Bright <newshound2 digitalmars.com>
 wrote:

  On 1/21/2014 5:09 PM, Manu wrote:

  It's not so simple,  because VisualD attempts to override the paths in

 the config

 files, it gets complicated and I have no clear view where the paths used
 actually come from.


 VisualD cannot find files that are not there - so remove those files, and
 then see what happens.


 I'm not sure what you mean... remove sc.ini?
 VisualD doesn't appear to be doing any magic (although it should). It's
 just taking the usual paths from sc.ini verbatim. This would seem to be
 the
 problem.


 You can see all the environment changes and executed command in the
 cmd-file in the output directory (or just click the link to the log shown
 in the output window).


Okay, I can see this in the .linkarg file (is that the file you mean?), I
wonder if this is the source of the problem:

/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\\lib\amd64
*\n*C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64\"

2 absolute paths concatenated by \n supplied to /LIBPATH:... looks very
suspicious.

Note: this is under VS2010, I'd need to reconfigure for VS2012 to reproduce
the link errors again, but I bet the same concatenated paths with \n occur
there too, and the paths would be ignored... falling back to sc.ini?)


 One problem might be that the C object files that are part of the phobos

 library are forcing the inclusion of the library "LIBCMT" (and "OLDNAMES"),
 and this probably doesn't mix very well with the debug version LIBCMTD.

 Maybe you can add a command line option to ignore LIBCMT for debug builds
 with /NODEFAULTLIB:LIBCMT


That's definitely a potential problem. Any C files in phobos must be built
with /Zl (Omit Default Library Name) if being built with MSC.
If they're not built with MSC, I can't imagine they would have had the name
embedded like MSC does in the first place, so tha wouldn't be the problem
in that case...?
Jan 22 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
On 22 January 2014 11:16, Walter Bright <newshound2 digitalmars.com> wrote:


 On 1/21/2014 5:09 PM, Manu wrote:


 It's not so simple,  because VisualD attempts to override the paths in
 the config

 files, it gets complicated and I have no clear view where the paths used
 actually come from.


 VisualD cannot find files that are not there - so remove those files, and
 then see what happens.


Slightly OT, but while we're on VisualD, can you chime in on this:
https://d.puremagic.com/issues/show_bug.cgi?id=11902
It's really frustrating, on a minute-ly basis >_<
Jan 21 2014
prev sibling parent Manu <turkeyman gmail.com> writes:
On 22 January 2014 11:09, Manu <turkeyman gmail.com> wrote:


 ...yes, seems to be the case. I amended my sc.ini file to point to the
 VS2012 stuff and it works much better. Only one link error:

 1>libcpmtd.lib(stdthrow.obj) : error LNK2019: unresolved external symbol
 _CrtDbgReportW referenced in function "void __cdecl
 std::_Debug_message(wchar_t const *,wchar_t const *,unsigned int)"
 (?_Debug_message std  YAXPEB_W0I Z)

 Strange.. I wonder where that's supposed to come from :/


This final link error appears to be a CRT mismatch. The C++ code is built
against the debug CRT, but I think DMD/VisualD (because VD handles the link
step manually?) is trying to link the non-debug lib.
How can I control which CRT DMD/VisualD will link against?
I can't see any options for DMD, and VisualD doesn't seem to expose any
option either. Passing /MTd to the linker doesn't have any effect, it's an
MSC compiler option, not a linker option.
Jan 21 2014