You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Bert Huijben <be...@qqmail.nl> on 2017/10/04 15:23:36 UTC
[PATCH] Building apr-util with recent libexpat2 using CMake
Hi,
Building apr-util with a recent libexpat2 (2.2.4) requires referencing an
additional .c file on Windows. The attached patch fixes the CMake build.
Perhaps somebody more experienced with CMake can create a patch that would
be compatible with older and newer versions.
Note that including this file on other platforms is safe. It will just be an
almost empty file on those platforms.
Bert
--
Inline version:
Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revision 1811061)
+++ CMakeLists.txt (working copy)
@@ -221,6 +221,7 @@
xml/expat/lib/xmlrole.c
xml/expat/lib/xmltok.c
xml/expat/lib/xmlparse.c
+ xml/expat/lib/loadlibrary.c
)
SET(install_targets)
Re: [PATCH] Building apr-util with recent libexpat2 using CMake
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Oct 5, 2017 at 5:09 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Both Serf and Subversion default to using the shared library version of
> apr, but have a flag to switch to using the static library version.
>
>
>
> Subversion uses the expat apis directly, and both serf and subversion
> hardcode ‘xml.lib’ in their buildscripts. Subversion has a hack to also
> support libexpat.lib for some other builds (probably recently added for
> somebody using the makefile build). We define ‘XML_STATIC’ in both shared
> and static library cases.
>
The only risk to this is data pointers, which aren't handled as PIC, so
they may
not be relocatable, and the text page has historically not been fixed up,
leading
to segfaults in certain circumstances. The converse, omitting XML_STATIC
may lead to "Exported symbols imported" in the static case, which indicates
that pic relocation table was used when not needed. The later is preferable
to the former.
Cleaning up inappropriate references to XML_STATIC would be a good idea
for the dynamic lib, that is a very unwise declaration.
When it is using a shared lib of apr by default, the shared libexpat.lib
and .dll
is certainly preferable, simpler to substitute a fixed version of a
vulnerable so.
And to avoid linking static expat to libapr, then libapr + static expat
into svn
components.
RE: [PATCH] Building apr-util with recent libexpat2 using CMake
Posted by Bert Huijben <be...@qqmail.nl>.
Both Serf and Subversion default to using the shared library version of apr, but have a flag to switch to using the static library version.
Subversion uses the expat apis directly, and both serf and subversion hardcode ‘xml.lib’ in their buildscripts. Subversion has a hack to also support libexpat.lib for some other builds (probably recently added for somebody using the makefile build). We define ‘XML_STATIC’ in both shared and static library cases.
Bert
From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
Sent: woensdag 4 oktober 2017 19:21
To: Bert Huijben <be...@qqmail.nl>
Cc: APR Developer List <de...@apr.apache.org>
Subject: RE: [PATCH] Building apr-util with recent libexpat2 using CMake
Question,
Is their default build using libapr-1.lib or apr-1.lib for svn and for serf?
I'm trying to wire in a choice for expat.lib (ambiguous) vs libexpat.lib (always dynamic) vs libexpatMT.lib (clearly static.)
Expat.lib is ambiguous because of the way their experimental cmake build is structured. I'll be raising a ticket about this. We want to decipher whether the XML_STATIC is needed. If I understood right, svn is going to directly access expat APIs? So it would need similar surety about the cpp flags.
The project policy change in 1.6.0 set this all in motion, unfortunately the cmakefiles.txt and xml.dsp masked the issue. Like on Unix, this necessitates some build changes by consuming projects. My goal is to minimize these changes.
On Oct 4, 2017 12:07, "Bert Huijben" <bert@qqmail.nl <ma...@qqmail.nl> > wrote:
> -----Original Message-----
> From: William A Rowe Jr [mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net> ]
> Sent: woensdag 4 oktober 2017 18:14
> To: Bert Huijben <bert@qqmail.nl <ma...@qqmail.nl> >
> Cc: APR Developer List <dev@apr.apache.org <ma...@apr.apache.org> >
> Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
>
> On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <bert@qqmail.nl <ma...@qqmail.nl> > wrote:
> > Hi,
> >
> > Building apr-util with a recent libexpat2 (2.2.4) requires referencing
> > an additional .c file on Windows. The attached patch fixes the CMake build.
> > Perhaps somebody more experienced with CMake can create a patch that
> > would be compatible with older and newer versions.
> >
> > Note that including this file on other platforms is safe. It will just
> > be an almost empty file on those platforms.
>
> Actually, this goes the other way. CMakeLists.txt should only reference the
> desired libexpat[MT].lib, not source files in expat. It's up to the expat
> maintainers to describe the Windows build, which they've been doing well
> since the late 1.9x flavors.
>
> See the "expat removed" thread. Please check out 1.6.x branch of apr-util for
> the currently proposed solution I intend to tag, once I've resolved all of
> Steffen's issues (some offlist, since his connectivity was limited over the
> weekend.)
Currently the cmake file on trunk directly references these files from the main apr project, so this code is currently broken in the same way.
Currently both Apache Subversion and Apache Serf rely on finding the xml library produced by the apr-util (or apr 2.0) build in their build scripts for Windows on all maintenance branches... without code in these scripts to override this.
Bert
RE: [PATCH] Building apr-util with recent libexpat2 using CMake
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Question,
Is their default build using libapr-1.lib or apr-1.lib for svn and for serf?
I'm trying to wire in a choice for expat.lib (ambiguous) vs libexpat.lib
(always dynamic) vs libexpatMT.lib (clearly static.)
Expat.lib is ambiguous because of the way their experimental cmake build is
structured. I'll be raising a ticket about this. We want to decipher
whether the XML_STATIC is needed. If I understood right, svn is going to
directly access expat APIs? So it would need similar surety about the cpp
flags.
The project policy change in 1.6.0 set this all in motion, unfortunately
the cmakefiles.txt and xml.dsp masked the issue. Like on Unix, this
necessitates some build changes by consuming projects. My goal is to
minimize these changes.
On Oct 4, 2017 12:07, "Bert Huijben" <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
> > Sent: woensdag 4 oktober 2017 18:14
> > To: Bert Huijben <be...@qqmail.nl>
> > Cc: APR Developer List <de...@apr.apache.org>
> > Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
> >
> > On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > > Hi,
> > >
> > > Building apr-util with a recent libexpat2 (2.2.4) requires referencing
> > > an additional .c file on Windows. The attached patch fixes the CMake
> build.
> > > Perhaps somebody more experienced with CMake can create a patch that
> > > would be compatible with older and newer versions.
> > >
> > > Note that including this file on other platforms is safe. It will just
> > > be an almost empty file on those platforms.
> >
> > Actually, this goes the other way. CMakeLists.txt should only reference
> the
> > desired libexpat[MT].lib, not source files in expat. It's up to the expat
> > maintainers to describe the Windows build, which they've been doing well
> > since the late 1.9x flavors.
> >
> > See the "expat removed" thread. Please check out 1.6.x branch of
> apr-util for
> > the currently proposed solution I intend to tag, once I've resolved all
> of
> > Steffen's issues (some offlist, since his connectivity was limited over
> the
> > weekend.)
>
> Currently the cmake file on trunk directly references these files from the
> main apr project, so this code is currently broken in the same way.
>
> Currently both Apache Subversion and Apache Serf rely on finding the xml
> library produced by the apr-util (or apr 2.0) build in their build scripts
> for Windows on all maintenance branches... without code in these scripts to
> override this.
>
> Bert
>
>
RE: [PATCH] Building apr-util with recent libexpat2 using CMake
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
> Sent: woensdag 4 oktober 2017 18:14
> To: Bert Huijben <be...@qqmail.nl>
> Cc: APR Developer List <de...@apr.apache.org>
> Subject: Re: [PATCH] Building apr-util with recent libexpat2 using CMake
>
> On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <be...@qqmail.nl> wrote:
> > Hi,
> >
> > Building apr-util with a recent libexpat2 (2.2.4) requires referencing
> > an additional .c file on Windows. The attached patch fixes the CMake build.
> > Perhaps somebody more experienced with CMake can create a patch that
> > would be compatible with older and newer versions.
> >
> > Note that including this file on other platforms is safe. It will just
> > be an almost empty file on those platforms.
>
> Actually, this goes the other way. CMakeLists.txt should only reference the
> desired libexpat[MT].lib, not source files in expat. It's up to the expat
> maintainers to describe the Windows build, which they've been doing well
> since the late 1.9x flavors.
>
> See the "expat removed" thread. Please check out 1.6.x branch of apr-util for
> the currently proposed solution I intend to tag, once I've resolved all of
> Steffen's issues (some offlist, since his connectivity was limited over the
> weekend.)
Currently the cmake file on trunk directly references these files from the main apr project, so this code is currently broken in the same way.
Currently both Apache Subversion and Apache Serf rely on finding the xml library produced by the apr-util (or apr 2.0) build in their build scripts for Windows on all maintenance branches... without code in these scripts to override this.
Bert
Re: [PATCH] Building apr-util with recent libexpat2 using CMake
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Oct 4, 2017 at 10:23 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi,
>
> Building apr-util with a recent libexpat2 (2.2.4) requires referencing an
> additional .c file on Windows. The attached patch fixes the CMake build.
> Perhaps somebody more experienced with CMake can create a patch that would
> be compatible with older and newer versions.
>
> Note that including this file on other platforms is safe. It will just be an
> almost empty file on those platforms.
Actually, this goes the other way. CMakeLists.txt should only reference the
desired libexpat[MT].lib, not source files in expat. It's up to the
expat maintainers
to describe the Windows build, which they've been doing well since the late 1.9x
flavors.
See the "expat removed" thread. Please check out 1.6.x branch of apr-util for
the currently proposed solution I intend to tag, once I've resolved
all of Steffen's
issues (some offlist, since his connectivity was limited over the weekend.)