Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9F31717978 for ; Fri, 15 May 2015 14:59:03 +0000 (UTC) Received: (qmail 56475 invoked by uid 500); 15 May 2015 14:59:03 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 56431 invoked by uid 500); 15 May 2015 14:59:03 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 56419 invoked by uid 99); 15 May 2015 14:59:02 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 May 2015 14:59:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 5FDF118283E for ; Fri, 15 May 2015 14:59:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.989 X-Spam-Level: ** X-Spam-Status: No, score=2.989 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 0r5QSerDi1N2 for ; Fri, 15 May 2015 14:59:00 +0000 (UTC) Received: from SP39.realvnc.ltd (mx.realvnc.com [212.69.41.4]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 32A5E20D7D for ; Fri, 15 May 2015 14:59:00 +0000 (UTC) Received: from SP39.realvnc.ltd (10.10.99.12) by SP39.realvnc.ltd (10.10.99.12) with Microsoft SMTP Server (TLS) id 15.0.775.38; Fri, 15 May 2015 15:56:33 +0100 Received: from SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b]) by SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b%13]) with mapi id 15.00.0775.031; Fri, 15 May 2015 15:56:33 +0100 From: Bruce Bye To: =?iso-8859-2?Q?Branko_=C8ibej?= CC: "dev@subversion.apache.org" Subject: Re: Subversion configure script broken for serf if sysroot path contains "-D" Thread-Topic: Subversion configure script broken for serf if sysroot path contains "-D" Thread-Index: AQHQjx9UrtOq+YG530iBC1g5Obaebg== Date: Fri, 15 May 2015 14:56:32 +0000 Message-ID: <72b68e9be40146aeabb649f7d2fd8ce7@SP39.realvnc.ltd> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.30.102] Content-Type: multipart/alternative; boundary="_000_72b68e9be40146aeabb649f7d2fd8ce7SP39realvncltd_" MIME-Version: 1.0 --_000_72b68e9be40146aeabb649f7d2fd8ce7SP39realvncltd_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable On 15/05/15 14:21, Branko =C8ibej 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=3D[`$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 ru= n "bitbake subversion-native". I'm pretty sure no-one wants to set up a Yocto environment just to reproduc= e this failure. :) Somewhat understandable, but this just a succinct description of how I actu= ally 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. B= ut I think you can avoid even invoking it by passing --with-serf=3D/path/to= /serf/prefix to configure; if the Serf path is provided, we won't invoke pk= g-config. Of course - a completely safe fix would have to do something rather differe= nt from a simple regex to ensure it wasn't catching something it didn't int= end 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. A= dding 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=3Dinc= ludedir 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 o= f 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 genera= ted automatically. pkg-config means I don't have to worry about that, so r= eally is the most sensible way. It does look like that work-around would be fine in an isolated context, th= ough. Bruce --_000_72b68e9be40146aeabb649f7d2fd8ce7SP39realvncltd_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable


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

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

The root cause is this line in serf.m4:
          SVN_SERF_INCLUDES=3D[`$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, b= ut a code inspection of 1.8.13 suggests the issue is still there and it doe= sn't look especially platform sensitive.

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

I'm pretty sure no-one wants to set up a Yocto environment just to reproduc= e this failure. :)
Somewhat understandable, but this just a succinct description of how I actu= ally came across the issue. In practice any cross-compile environment whose= sysroot path is as described should repro.  Conversely, if anyone alr= eady 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. B= ut I think you can avoid even invoking it by passing --with-serf=3D/path/to= /serf/prefix to configure; if the Serf path is provided, we won't invoke pk= g-config.
Of course - a completely safe fix would have to do something rather differe= nt from a simple regex to ensure it wasn't catching something it didn't int= end 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=3Dinc= ludedir from pkg-config, and not need to munge the string at all.
Can yo= u give that a try, please, and report the result?
Unfortunately, adding configure options is a bit of a pain for me because o= f 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 genera= ted 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, th= ough.

Bruce
--_000_72b68e9be40146aeabb649f7d2fd8ce7SP39realvncltd_--