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.

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

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...?