I don't believe we can do libxml2 until the release of 1.7.0, the supporting logic that Nick committed is sitting in trunk/2.0 - It's not on my agenda today, but after 1.6.1/1.6.3, sure.
Back to the subject at hand, I tested using the expat and expat_static projects, making libexpat.dll/.lib and libexpatMD.lib respectively. That is what is recognized by the Makefile.win file right now. Building expat's cmake flavor doesn't appear to result in shared+static, which is a little unusual. So forcing a -D BUILD_shared=OFF in the cmake invocation delivers the classic XML_STATIC libs. with the expat.lib name. Here, building apr with XML_PARSER=expat does deliver the expected results, and is what httpd would want for all of the support/* tools which we compile statically against apr.lib. On Wed, Sep 27, 2017 at 2:12 PM, Steffen <i...@apachelounge.com> wrote: > Yes, 1.6.1 for next httpd 2.4.28. > > I want to go now for libxml2 and forget expat. We have already libxml2.dll > in the distro. > > We need also changes in the httpd dsp/mak/dsw/win files ? > > > Op 27 sep. 2017 om 20:58 heeft Gregg Smith <g...@gknw.net> het volgende > geschreven: > > I think I'd rather have apu 1.6.1 now without this (since we need it now) > and we can do this for 1.6.2 which will allow us to get any kinks out (if > any) while not under the gun. What do you think Steffen? > > Also, if we're going in this direction (which I want to) is to just get > what's in trunk working in 1.6 with it's choice of expat or libxml2 which > includes two additional files, one for using expat and one for using > libxml2, which I thought was the intent for 1.6 in the first place IIRC, it > just never happened. > > > On 9/27/2017 11:01 AM, William A Rowe Jr wrote: > > This is now committed. > > Would like to verify that this is working for our own win32 devs' build > > preferences of expat 2.2.4, and glean any other feedback or suggestions > > for improvement. I'm on to the cmake-side of the world for the moment, > > I expect that won't be too rough, already collected suggestions for > > compiling against expat.. > > On Wed, Sep 27, 2017 at 12:10 PM, William A Rowe Jr <wr...@rowe-clan.net> > wrote: > > After deeper consideration, this was fundamentally wrong. > > > For those less familiar with the Win32 build, we failed to decouple > > a "project" called "xml" which was, in fact, our idea of how expat > > should be built. > > > That's unacceptable, as this missing file demonstrated. It shows > > a lack of diligence in running tests (rather impossible to mix and > > match between tests built on expat and those with httpd), It opens > > us up to criticism for whatever "foolish" build flags we use versus > > the recommended flags by the expat maintainers. > > > Already, apr-util has crypto libs, dbm providers, dbd providers, all > > but one are external libraries maintained by external groups with > > their own recommended build mechansims. > > > I will solve for visual studio Makefile.win builds with this; > > > # Provide the XML_PARSER argument after configuring LIB and INCLUDE with > > # the expat path of the corresponding xml parser, e.g. libexpatMT to choose > > # static, or libexpat (default) to choose the dynamic library for > aprutil-1.dll > > # (Static libaprutil-1.lib always presumes libexpatMT with XML_STATIC flag.) > > # > > # XML_PARSER="libexpat" > > # > > > This will toggle the lib and the correct XML_STATIC setting. My theory > > is as follows; libexpat.dll gets security updates. We shouldn't generally > > be compiling it into a system like httpd. For a command line tool, e.g. > > when libaprutil-1.lib (static) is used, libexpatMT is a fine choice, and > > the user will have to compile that in as well. Wherever aprutil-1.dll is > > being used, the libexpat.dll is the obvious right choice. > > > Anyone who knows Nick's efforts knows where this is leading, some time > > in the future XML_PARSER=libxml2 can become a possibility. > > > Somehow we've all grown accustomed to trusting all the rest of these > > third party projects and know how to set up LIB and INCLUDE search > > paths, so this is simply not a hardship. Our custom build tooling for expat > > must be jettisoned, we do so nowhere else. Unix can cope, so must Win32. > > > Cheers, > > > Bill > > > > > > > On Tue, Sep 26, 2017 at 6:17 PM, Gregg Smith <g...@gknw.net> wrote: > > Feel free to do whatever you please with the cmake build. I just added the > > new loadlibrary.c file to it is all so technically it is ready to go and apu > > can be tagged. > > > > On 9/26/2017 10:29 AM, William A Rowe Jr wrote: > > > This doesn't make sense to me; in unbundling, and providing a modern build > > system, why are these sources mentioned? > > > Expat 2.2.x has it's own build schema, any attempt to replace expat's with > > APR's seems misguided. Happy to stay mostly hands-off the mak/dsp as > > this legacy tangle that users continue to consume, but the cmake was done > > to turn windows builds into a conventional solution. The right fix there > > is to > > just switch compiling sources for linking to a library, and let that > > library > > maintainer do their thing. > > > So +1 to the dsp/mak change, but alternate CMakeFiles.txt feedback > > to follow... > > > > On Tue, Sep 26, 2017 at 10:13 AM, Gregg Smith <g...@gknw.net> wrote: > > > cmake should be as well. http://svn.apache.org/r1805330 > > > > On 9/26/2017 7:12 AM, William A Rowe Jr wrote: > > > > Proceeding with the understanding that mak, and dsp files are OK on > > -dev, > > thank > > you for the review in your schema, Steffen! > > > Cheers, > > > Bill > > > On Tue, Sep 26, 2017 at 4:00 AM, Steffen <i...@apachelounge.com> wrote: > > > > No issues seen with building and running httpd with apr 1.6.3 and > > apr-util > > 1.6.1 > > > > On Monday 25/09/2017 at 21:34, Steffen wrote: > > > No, used 1.6.2/1.6.0. > > > Tomorrow (already late here) I can try 1.6.3-dev and 1.6.1-dev. > > > > Op 25 sep. 2017 om 20:52 heeft William A Rowe Jr <wr...@rowe-clan.net> > > het > > volgende geschreven: > > > Hi Steffen, > > > were you testing 1.6.x branches of apr (1.6.3-dev) and apr-util > > (1.6.1-dev)? > > Or the last released 1.6.2/1.6.0 flavors? > > > I'm reviewing here to avoid tagging something that won't build, if you > > had already > > done so for Windows, it would speed things up here. > > > Cheers, > > > Bill > > > On Mon, Sep 25, 2017 at 12:11 PM, Steffen <i...@apachelounge.com> > > wrote: > > On Windows it does not build out of the box. > > > Missing modules/core include for mod_watchdog.h in > > mod_proxy_balancer.dsp/mak and libhttp.dsp/mak . Did not checked cmake. > > > Steffen > > > On Monday 25/09/2017 at 14:13, Jim Jagielski wrote: > > > The pre-release test tarballs for Apache httpd > > version 2.4.28 can be found at the usual place: > > > http://httpd.apache.org/dev/dist/ > > > I'm calling a VOTE on releasing these as Apache httpd 2.4.28 GA. > > > [ ] +1: Good to go > > [ ] +0: meh > > [ ] -1: Danger Will Robinson. And why. > > > Vote will last the normal 72 hrs. > > > NOTE: The *-deps are only there for convenience. > > > Thx! > > > > > > >
