VisualD and VS2012

Manu turkeyman at gmail.com
Wed Jan 22 15:47:49 PST 2014


On 23 January 2014 08:38, Rainer Schuetze <r.sagitario at gmx.de> wrote:

> On Wednesday, 22 January 2014 at 01:25:07 UTC, Manu wrote:
>
>> On 22 January 2014 11:16, Walter Bright <newshound2 at 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...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140123/3d7943d3/attachment.html>


More information about the Digitalmars-d mailing list