On Sat, Dec 24, 2016 at 1:23 AM, Ivan Zhakov <i...@visualsvn.com> wrote:
> > Regarding my current problem: I'm getting the following when I attempt > to build expat: > [[[ > runtestspp.obj : error LNK2019: unresolved external symbol > _align_limit_to_full_utf8_characters referenced in function "void > __cdecl test_utf8_auto_align(void)" (?test_utf8_auto_align@@YAXXZ) > [D:\Ivan\SVN\expat-cmake\runtestspp.vcxproj] > ]]] That's a problem, yes. It looks like a possible expat build issue. Seems to apply to the expat test suite. You can toggle building tests in expat and obtain the necessary libs separately. I have no such issues; building expat 2.2.0 my working expat is; cmake -G "NMake Makefiles" -D CMAKE_INSTALL_PREFIX=..\thirdparty \ -D BUILD_SHARED_LIBS=ON -D CMAKE_BUILD_TYPE=RelWithDebInfo \ -D CMAKE_COLOR_MAKEFILE=OFF . nmake all install I apply one patch to cmake to compile and link RelWithDebInfo correctly to emit .pdb's (It hadn't behaved as documented). This all is working under both Studio 2010 and 2015. FWIW - libxml2 is both a supported substitute for expat in apr-2, as well as a requirement for mod_proxy_html, which is why I'm leaning toward ignoring expat in the future and having both rely exclusively on libxml2. > Agreed. But three years down the road, after the expert who hand-crafted a > > custom .mak solution has moved on to better things and we're on Visual > > Studio vNext, I'm guessing you'll find the same thing will happen there > too > > -- unless you have a plan in mind to avoid it? > > > Well, Visual Studio vNext is going to support CMake builds out of the > box and it sounds very promising. But I cannot get it work for APR yet > :( Do you have a similar apr example, or is it simply that you got jammed in expat and couldn't move forwards? I also have this which illustrates windows builds; https://wiki.apache.org/httpd/WindowsTrunkCompilation Hope that proves interesting/useful.
cmakepdbfix34.patch
Description: Binary data