NMake can't create the project solution for jpeg

[Strelok]

DISCLAIMER: I'm using bugged cutting edge software Windows 10 techical preview x64 + SFML master + CMake Nightly + Visual Studio 14 CTP 4

Visual studio 14 CTP seems to be working well with CMake nightlies but it looks like freetype and image need to be recompiled E.G:

7>jpeg.lib(jerror.obj) : error LNK2019: unresolved external symbol fprintf referenced in function output_message
7>jpeg.lib(jerror.obj) : error LNK2019: unresolved external symbol __iob_func referenced in function output_message

I've managed to rebuild freetype succesfully (thanks to CMake), but NMake gives me this error when I try to build the project for image.

C:\jpeg-6b>nmake /f makefile.vc

Microsoft (R) Program Maintenance Utility Version 14.00.22129.1
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1073: don't know how to make 'jconfig.h'
Stop.

This is what MSDN says  .
This might have a solution but I can't understand what has been written  .
I'm assuming Laurent (or whoever compiled the extlibs for windows) has a solution for my problem, unless my working environment is missing something.

EDIT: Apparently I had been using the wrong version of the sources. After updating from 6b to 9a nmake /f makefile.vc setup-v10 seems to be working.
EDIT 2: I still have linker issues about runtime libraries, can anyone confirm that I need to specify /MD on both the freetype and jpeg library?

[eXpl0it3r]

I think there are better communities (e.g. the Microsoft one or StackOverflow) for none SFML issues like that.
jpeg and freetype are C libraries, they don't need rebuilding with newer compiler versions.
If theg suddenly can't find "standard" symbols then it's a pure compiler issue.

[Strelok]

I think there are better communities (e.g. the Microsoft one or StackOverflow) for none SFML issues like that.
jpeg and freetype are C libraries, they don't need rebuilding with newer compiler versions.

I posted here because I know the team might have been encounter similar issues when building those libraries. The non (although questionably so) SFML related problem had already been resolved when you posted so I don't see how your point would apply to this issue.

If they suddenly can't find "standard" symbols then it's a pure compiler issue.

This answer still refers to the old issue.

[eXpl0it3r]

Then adjust your post accordingly because I've no idea what the new issue is....

Also in my humble opinion if you're using experimental software you should also be able to resolve some simple linker issues on your own.