[PATCH 0/3] Minor fixes to the build system for NetBSD

[PATCH 0/3] Minor fixes to the build system for NetBSD

[Roger Pau Monne]

Small fixes to the build system to build out of the box on NetBSD.

One patch has already been sent to the qemu-devel ml, to allow qemu 
upstream to build correctly on NetBSD.

[PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix

[Roger Pau Monne]

NetBSD `python-conf --ldflags` doesn't return the library dir, so we
have to add it to LDFLAGS based on the prefix returned by `python-conf
--prefix`. Also the include dir has been added to CFLAGS using the
same technique.

If not passed the configure script fails on NetBSD, complaining it
cannot find lpythonx.x library during the python_dev test phase.

This is currently done on all OSes, since I think it's harmless to do
this on other systems also.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/m4/python_devel.m4 |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/m4/python_devel.m4 b/tools/m4/python_devel.m4
index 0a2202c..61326df 100644
--- a/tools/m4/python_devel.m4
+++ b/tools/m4/python_devel.m4
@@ -23,8 +23,9 @@ AS_IF([test x"$pyconfig" == x"no"], [
         print distutils.sysconfig.get_config_var("LDFLAGS")'`"
 ], [
     dnl If python-config is found use it
-    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
-    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
+    ac_python_prefix=`$PYTHON-config --prefix`
+    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include"
+    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib"
 ])
 
 AC_CHECK_HEADER([Python.h], [],
-- 
1.7.7.5 (Apple Git-26)

Re: [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix

[Ian Jackson]

Roger Pau Monne writes ("[Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix"):
> NetBSD `python-conf --ldflags` doesn't return the library dir, so we
> have to add it to LDFLAGS based on the prefix returned by `python-conf
> --prefix`. Also the include dir has been added to CFLAGS using the
> same technique.
...
>      dnl If python-config is found use it
> -    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
> -    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
> +    ac_python_prefix=`$PYTHON-config --prefix`
> +    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include"
> +    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib"

Shouldn't the -I and particulary the -L come first ?  TBH I'm
surprised that this works since it looks like it ought to generate
   -lpython2.6 -L/usr/blah/lib/bleh/python2.6
or something, which I wouldn't expect to work.

Ian.

Re: [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix

[Roger Pau Monne]

Ian Jackson escribió:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix"):
>> NetBSD `python-conf --ldflags` doesn't return the library dir, so we
>> have to add it to LDFLAGS based on the prefix returned by `python-conf
>> --prefix`. Also the include dir has been added to CFLAGS using the
>> same technique.
> ...
>>       dnl If python-config is found use it
>> -    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags`"
>> -    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags`"
>> +    ac_python_prefix=`$PYTHON-config --prefix`
>> +    CPPFLAGS="$CFLAGS `$PYTHON-config --cflags` -I$ac_python_prefix/include"
>> +    LDFLAGS="$LDFLAGS `$PYTHON-config --ldflags` -L$ac_python_prefix/lib"
>
> Shouldn't the -I and particulary the -L come first ?

According to man ld (from Debian):

"All -L options apply to all -l options, regardless of the order in 
which the options appear."

So it should be ok to specify -L after -l.

> TBH I'm
> surprised that this works since it looks like it ought to generate
>     -lpython2.6 -L/usr/blah/lib/bleh/python2.6
> or something, which I wouldn't expect to work.

python-config --prefix on the systems I've tested (that's NetBSD and 
Debian) returns the prefix path used for install, that's /usr on Debian 
and /usr/pkg on NetBSD.

Anyway, forget about this patch, a latter patch 3/3, fixes the library 
path search, so it's just easier to pass APPEND_LIB=/usr/pkg/lib to 
configure rather than touching the python_dev code.

Re: [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix

[Ian Jackson]

Roger Pau Monne writes ("Re: [Xen-devel] [PATCH 1/3] autoconf/python_dev: pass include and library dir based on prefix"):
> According to man ld (from Debian):
> 
> "All -L options apply to all -l options, regardless of the order in 
> which the options appear."

I think this is a special feature of GNU binutils.  (And a surprising
one to me at least!)

> So it should be ok to specify -L after -l.

No.  I asked a friend who had access to (for example) the Solaris ld
manpage and got this quote:

    -L path [...] This option is useful only if the option 
    precedes the -l options to which the -L option applies.

Ian.

[PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Roger Pau Monne]

NetBSD doesn't have a gntdev, so libvchan is unable to build due to
the lack of the header files gntalloc.h.

This is the error:

gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-D__XEN_TOOLS__ -MMD -MF .init.o.d -fno-optimize-sibling-calls
-I../include -I.
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/xenstore
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/include
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/libxc
-I/root/xen/xen-netbsd/tools/libvchan/../../tools/include  -c -o
init.o init.c
init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or
directory
compilation terminated.
gmake[3]: *** [init.opic] Error 1
gmake[3]: *** Waiting for unfinished jobs....
init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or
directory
compilation terminated.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tools/Makefile b/tools/Makefile
index a74df2f..18a58e8 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -30,7 +30,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2
 SUBDIRS-$(CONFIG_NetBSD) += xenbackendd
 SUBDIRS-y += libfsimage
 SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen
-SUBDIRS-y += libvchan
+SUBDIRS-$(CONFIG_Linux) += libvchan
 
 # do not recurse in to a dir we are about to delete
 ifneq "$(MAKECMDGOALS)" "distclean"
-- 
1.7.7.5 (Apple Git-26)

Re: [PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Christoph Egger]

On 05/11/12 16:13, Roger Pau Monne wrote:

> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
> the lack of the header files gntalloc.h.
> 
> This is the error:
> 
> gcc  -O1 -fno-omit-frame-pointer -m64 -g -fno-strict-aliasing
> -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
> -D__XEN_TOOLS__ -MMD -MF .init.o.d -fno-optimize-sibling-calls
> -I../include -I.
> -I/root/xen/xen-netbsd/tools/libvchan/../../tools/xenstore
> -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include
> -I/root/xen/xen-netbsd/tools/libvchan/../../tools/libxc
> -I/root/xen/xen-netbsd/tools/libvchan/../../tools/include  -c -o
> init.o init.c
> init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or
> directory
> compilation terminated.
> gmake[3]: *** [init.opic] Error 1
> gmake[3]: *** Waiting for unfinished jobs....
> init.c:45:30: fatal error: xen/sys/gntalloc.h: No such file or
> directory
> compilation terminated.
> 
> Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>

  Acked-by: Christoph Egger <Christoph.Egger@amd.com>

> ---
>  tools/Makefile |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index a74df2f..18a58e8 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -30,7 +30,7 @@ SUBDIRS-$(CONFIG_NetBSD) += blktap2
>  SUBDIRS-$(CONFIG_NetBSD) += xenbackendd
>  SUBDIRS-y += libfsimage
>  SUBDIRS-$(LIBXENAPI_BINDINGS) += libxen
> -SUBDIRS-y += libvchan
> +SUBDIRS-$(CONFIG_Linux) += libvchan
>  
>  # do not recurse in to a dir we are about to delete
>  ifneq "$(MAKECMDGOALS)" "distclean"



-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Ian Jackson]

Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
> On 05/11/12 16:13, Roger Pau Monne wrote:
> > NetBSD doesn't have a gntdev, so libvchan is unable to build due to
> > the lack of the header files gntalloc.h.

>   Acked-by: Christoph Egger <Christoph.Egger@amd.com>

Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>

Re: [PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Roger Pau Monne]

Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>> the lack of the header files gntalloc.h.
>
>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>
> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>

I'm not sure this has been committed, could you please check it Ian?

Thanks, Roger.

Re: [PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Christoph Egger]

On 06/18/12 12:08, Roger Pau Monne wrote:

> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools:
>> disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>
>>>    Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
> 
> I'm not sure this has been committed, could you please check it Ian?


It has. See c/s 25472:1e4561d216db.

Christoph


-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85689 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH 2/3] build/tools: disable libvchan build on NetBSD

[Roger Pau Monne]

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Christoph Egger writes ("Re: [Xen-devel] [PATCH 2/3] build/tools: disable libvchan build on NetBSD"):
>>> On 05/11/12 16:13, Roger Pau Monne wrote:
>>>> NetBSD doesn't have a gntdev, so libvchan is unable to build due to
>>>> the lack of the header files gntalloc.h.
>>>     Acked-by: Christoph Egger<Christoph.Egger@amd.com>
>> Committed-by: Ian Jackson<ian.jackson@eu.citrix.com>
>
> I'm not sure this has been committed, could you please check it Ian?

Sorry for the fuss, I've found this one on staging.

Roger.

[PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars

[Roger Pau Monne]

Parse those options correctly, since the "+=" operator is not valid.
Also added CPPFLAGS, so headers checks don't give strange results.

Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
---
 tools/m4/set_cflags_ldflags.m4 |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/m4/set_cflags_ldflags.m4 b/tools/m4/set_cflags_ldflags.m4
index 7e357ba..631e81c 100644
--- a/tools/m4/set_cflags_ldflags.m4
+++ b/tools/m4/set_cflags_ldflags.m4
@@ -1,20 +1,21 @@
 AC_DEFUN([AX_SET_FLAGS],
 [for cflag in $PREPEND_INCLUDES
 do
-    PREPEND_CFLAGS+=" -I$cflag"
+    PREPEND_CFLAGS="$PREPEND_CFLAGS -I$cflag"
 done
 for ldflag in $PREPEND_LIB
 do
-    PREPEND_LDFLAGS+=" -L$ldflag"
+    PREPEND_LDFLAGS="$PREPEND_LDFLAGS -L$ldflag"
 done
 for cflag in $APPEND_INCLUDES
 do
-    APPEND_CFLAGS+=" -I$cflag"
+    APPEND_CFLAGS="$APPEND_CFLAGS -I$cflag"
 done
 for ldflag in $APPEND_LIB
 do
-    APPEND_LDFLAGS+=" -L$ldflag"
+    APPEND_LDFLAGS="$APPEND_LDFLAGS -L$ldflag"
 done
 CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
+CPPFLAGS="$CFLAGS"
 LDFLAGS="$PREPEND_LDFLAGS $LDFLAGS $APPEND_LDFLAGS"])
 
-- 
1.7.7.5 (Apple Git-26)

Re: [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars

[Ian Jackson]

Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
> Parse those options correctly, since the "+=" operator is not valid.
> Also added CPPFLAGS, so headers checks don't give strange results.
...
>  CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
> +CPPFLAGS="$CFLAGS"

Surely that can't be right.

Ian.

Re: [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars

[Roger Pau Monne]

Ian Jackson wrote:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>> Parse those options correctly, since the "+=" operator is not valid.
>> Also added CPPFLAGS, so headers checks don't give strange results.
> ...
>>   CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>> +CPPFLAGS="$CFLAGS"

Without this I get the following (harmless but noisy) error:

checking yajl/yajl_version.h usability... yes
checking yajl/yajl_version.h presence... no
configure: WARNING: yajl/yajl_version.h: accepted by the compiler, 
rejected by the preprocessor!
configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's 
result

> Surely that can't be right.

 From http://www.edwardrosten.com/code/autoconf/:

"Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C 
preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and 
LIBS (for the linker)."

It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so 
we have to set both.

Re: [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars

[Roger Pau Monne]

Roger Pau Monne wrote:
> Ian Jackson wrote:
>> Roger Pau Monne writes ("[Xen-devel] [PATCH 3/3] autoconf: correctly parse *_INCLUDES and *_LIB env vars"):
>>> Parse those options correctly, since the "+=" operator is not valid.
>>> Also added CPPFLAGS, so headers checks don't give strange results.
>> ...
>>>    CFLAGS="$PREPEND_CFLAGS $CFLAGS $APPEND_CFLAGS"
>>> +CPPFLAGS="$CFLAGS"
>
> Without this I get the following (harmless but noisy) error:
>
> checking yajl/yajl_version.h usability... yes
> checking yajl/yajl_version.h presence... no
> configure: WARNING: yajl/yajl_version.h: accepted by the compiler,
> rejected by the preprocessor!
> configure: WARNING: yajl/yajl_version.h: proceeding with the compiler's
> result
>
>> Surely that can't be right.
>
>    From http://www.edwardrosten.com/code/autoconf/:
>
> "Just append stuff to CFLAGS (for the C compiler), CPPFLAGS (for the C
> preprocessor, C and C++ compilers), CXXFLAGS (for the C++ compiler) and
> LIBS (for the linker)."
>
> It seems like the preprocessor check uses CPPFLAGS instead of CFLAGS, so
> we have to set both.

Any news on this one?

Thanks, Roger.