I put in under the xml folder. To get libexpat.lib double click the included lib/expat.vcxproj and convert it.
Build expat The .dll and lib is created in expat/win32/bin To reduce the size of the libexpat.dll set in properties/linker/debugging/generate debug info to No. For the C99 issue with VC11, see www.apachelounge.com/viewtopic.php?t=7777 Found glitches in the libaprutil.dsp - Missing in line LINK the path to libexpat.dll: /libpath:"..\..\srclib\apr-util\xml\expat/lib - With converting the libaprutil.dsp to a .vcxproj the $(XML_PARSER) is not filled in: ....<AdditionalDependencies>$(XML_PARSER).lib;ws2_32.lib;mswsock.lib;........ Adding XML_PARSER=libexpat to the .dsp does not help, so replaced $(XML_PARSER) with libexpat. Only solution I see, is to add to apr cvtdsp.pl the parser to be used by replacing $(XML_PARSER). Did not build with cmake and .mak files. For the time being I stick with the former xml build, I see no advantage. > Op 18 okt. 2017 om 23:13 heeft Gregg Smith <g...@gknw.net> het volgende > geschreven: > >> On 10/18/2017 7:58 AM, William A Rowe Jr wrote: >> Please cast your votes on the following candidate packages; > > I'm not there to vote yet, my question is how did you expect us to build APU > with a precompiled lib and this lib put where? > > Looking at both makafile.win and libaprutil.mak I see not much for pointers > here. I see an include of ./xml/expat/lib in libaprutil.mak so do I really > have to put expat in the xml folder? Seem it should be outside the apr-util > folder so the include would be like /I ../expat/lib > > Further, no /libpath: pointing to where libexpat.lib is grabbed from at apu's > linking. I don't remember vc ever being that smart to just find it, it knew > it was in ./xml/libR because that's where it put xml.lib, which we don't have > anymore. > > cmake -G "NMake Makefiles" -DCMAKE_BUILD_TYPE=Release -DBUILD_shared=OFF > gives me an expat.lib, not libexpat.lib, so unless I'm missing something > really obvious that's right under my nose, I don't get it :) >
