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.

Attachment: cmakepdbfix34.patch
Description: Binary data

Reply via email to