Re: Subversion configure script broken for serf if sysroot path contains "-D"

On 15/05/15 14:21, Branko Èibej wrote:
On 15.05.2015 13:38, Bruce Bye wrote:
Hi,

If you attempt to cross-compile subversion with a sysroot path containing "-D", blame.c will fail to compile, failing to find serf.h.

The root cause is this line in serf.m4:
          SVN_SERF_INCLUDES=[`$PKG_CONFIG $serf_major --cflags | $SED -e 's/-D[^ ]*//g'`]

I assume the intention is simply to strip any pre-compile defines from the cflags returned by pkg-config, but the regex is too aggressive.

This was observed in subversion 1.8.9, doing a Yocto build on Linux, but a code inspection of 1.8.13 suggests the issue is still there and it doesn't look especially platform sensitive.

Repro steps:
Set-up a Yocto environment in a path such as '/home/user/Dev-Demo'. Then run "bitbake subversion-native".

I'm pretty sure no-one wants to set up a Yocto environment just to reproduce this failure. :)
Somewhat understandable, but this just a succinct description of how I actually came across the issue. In practice any cross-compile environment whose sysroot path is as described should repro. Conversely, if anyone already has a Yocto environment, it would be a very simple matter to run the setup script to create a parallel build tree that trips over the bug.

There's really no completely safe way to rewrite that regular expression. But I think you can avoid even invoking it by passing --with-serf=/path/to/serf/prefix to configure; if the Serf path is provided, we won't invoke pkg-config.
Of course - a completely safe fix would have to do something rather different from a simple regex to ensure it wasn't catching something it didn't intend to, and may not be worth the effort. I would think that adding a space in the regex before the hyphen might be sufficient, but I don't know if you need to worry about a -D option at the very start of the cflags string. Adding the space into the regex is how I'm working around the issue for now.

But then, since what the code is actually trying to get is the include path and not the full cflags, perhaps it could instead request --variable=includedir from pkg-config, and not need to munge the string at all.
Can you give that a try, please, and report the result?
Unfortunately, adding configure options is a bit of a pain for me because of all the Yocto wrapping, and wouldn't be a workaround anyway - in practice I'm writing a job to run on Jenkins so the full path is going to be generated automatically. pkg-config means I don't have to worry about that, so really is the most sensible way.

It does look like that work-around would be fine in an isolated context, though.

Bruce
Received on 2015-05-15 16:59:08 CEST