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
