From: Roger Pau Monne <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Christoph Egger <Christoph.Egger@amd.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2 3/4] python: set absolute path to libxl.h on _pyxl_types.c
Date: Thu, 17 May 2012 16:10:52 +0100 [thread overview]
Message-ID: <4FB514FC.5040807@citrix.com> (raw)
In-Reply-To: <1337265498.7781.95.camel@zakaz.uk.xensource.com>
Ian Campbell wrote:
> On Thu, 2012-05-17 at 15:02 +0100, Roger Pau Monne wrote:
>> Ian Campbell wrote:
>>> On Thu, 2012-05-17 at 13:16 +0100, Roger Pau Monne wrote:
>>>> genwrap.py generates _pyxl_types.c, which includes libxl.h, but if
>>>> libxl.h is already present in the include search path, the old one was
>>>> included instead of the new one, giving compilation errors. Since
>>>> _pyxl_types.c is generated at compilation time, we can safely set
>>>> the path to libxl.h include.
>>>>
>>>> I've only experienced this problem when compiling Xen on NetBSD with
>>>> old header files in the include path, Linux seems to not have this
>>>> problem.
>>> Should this be include<> and not "", since libxl.h isn't in the current
>>> dir in this case?
>>>
>>> Is the right fix to make sure that the in-tree -I lines come first?
>>> Ian.
>> Actually I'm not sure if it's possible to make sure the in-tree -I lines
>> come first, because the gcc options are automatically generated by
>> python build tools (distutils& friends...), so we cannot touch much of
>> this (I've looked at distutils.core options, and it seems to be no way
>> of setting an order on compiler options, but I'm no expert on python C
>> extensions building), so unless we craft our own makefile to build this
>> python stuff I think we are stuck with something like this.
>
> Surely distutils puts user supplied options first before system options?
> My /usr/lib/python2.5/distutils/command/build_ext.py says:
>
> # Put the Python "system" include dir at the end, so that
> # any local include dirs take precedence.
> self.include_dirs.append(py_include)
> if plat_py_include != py_include:
> self.include_dirs.append(plat_py_include)
>
> So it seems like this is the intention.
>
> Are you sure this isn't just a bug in your version of distutils or
> something like that?
>
> My python xl builds end up as:
> building 'xl' extension
> gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
> -Wstrict-prototypes -O1 -fno-omit-frame-pointer -m32 -march=i686
> -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
> -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.d
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -fno-optimize-sibling-calls
> -mno-tls-direct-seg-refs -fPIC -I../../tools/include
> -I../../tools/libxl -I../../tools/libxc -Ixen/lowlevel/xl
> -I/usr/include/python2.6 -c xen/lowlevel/xl/xl.c -o
> build/temp.linux-i686-2.6/xen/lowlevel/xl/xl.o
> -fno-strict-aliasing -Werror
>
> Which has our local -I options before all the others -- which is
> sensible. What do you see with your system?
This is what I see:
CC="gcc" CFLAGS="-O1 -fno-omit-frame-pointer -m64 -g
-fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.d
-fno-optimize-sibling-calls" python2.7 setup.py build
running build
running build_py
running build_ext
building 'xl' extension
gcc -DNDEBUG -O2 -DHAVE_DB_185_H -I/usr/include -I/usr/pkg/include -O1
-fno-omit-frame-pointer -m64 -g -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD
-MF .build.d -fno-optimize-sibling-calls -fPIC -I../../tools/include
-I../../tools/libxl -I../../tools/libxc -Ixen/lowlevel/xl
-I/usr/pkg/include/python2.7 -c xen/lowlevel/xl/_pyxl_types.c -o
build/temp.netbsd-6.0_BETA-amd64-2.7/xen/lowlevel/xl/_pyxl_types.o
-fno-strict-aliasing -Werror
xen/lowlevel/xl/_pyxl_types.c: In function 'genwrap__init':
xen/lowlevel/xl/_pyxl_types.c:4346:78: error:
'LIBXL_EVENT_TYPE_DOMAIN_CREATE_CONSOLE_AVAILABLE' undeclared (first use
in this function)
xen/lowlevel/xl/_pyxl_types.c:4346:78: note: each undeclared identifier
is reported only once for each function it appears in
error: command 'gcc' failed with exit status 1
gmake: *** [build] Error 1
gmake: Leaving directory `/root/xen/xen-netbsd/tools/python'
So this part "-DNDEBUG -O2 -DHAVE_DB_185_H -I/usr/include
-I/usr/pkg/include" comes even before our passed CFLAGS.
My /usr/pkg/lib/python2.7/distutils/command/build_ext.py:
# Put the Python "system" include dir at the end, so that
# any local include dirs take precedence.
self.include_dirs.append(py_include)
if plat_py_include != py_include:
self.include_dirs.append(plat_py_include)
[...]
# Finally add the user include and library directories if requested
if self.user:
user_include = os.path.join(USER_BASE, "include")
user_lib = os.path.join(USER_BASE, "lib")
if os.path.isdir(user_include):
self.include_dirs.append(user_include)
if os.path.isdir(user_lib):
self.library_dirs.append(user_lib)
self.rpath.append(user_lib)
So it says it puts them at the end, but it doesn't do so. I've looked at
Python 2.7 original source, and this is not a NetBSD port specific bug.
> Ian.
>
next prev parent reply other threads:[~2012-05-17 15:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 12:16 [PATCH v2 1/4] build/tools: disable libvchan build on NetBSD Roger Pau Monne
2012-05-17 12:16 ` [PATCH v2 2/4] autoconf: correctly parse *_INCLUDES and *_LIB env vars Roger Pau Monne
2012-05-17 12:16 ` [PATCH v2 3/4] python: set absolute path to libxl.h on _pyxl_types.c Roger Pau Monne
2012-05-17 13:25 ` Ian Campbell
2012-05-17 14:02 ` Roger Pau Monne
2012-05-17 14:38 ` Ian Campbell
2012-05-17 15:10 ` Roger Pau Monne [this message]
2012-05-17 15:14 ` Ian Campbell
2012-05-18 8:37 ` Christoph Egger
2012-05-18 8:41 ` Ian Campbell
2012-05-18 8:44 ` Roger Pau Monne
2012-05-18 8:41 ` Roger Pau Monne
2012-05-18 8:52 ` Ian Campbell
2012-05-18 9:14 ` Roger Pau Monne
2012-05-18 9:25 ` Ian Campbell
2012-05-18 11:13 ` Ian Jackson
2012-05-18 11:17 ` Roger Pau Monne
2012-05-17 12:16 ` [PATCH v2 4/4] tools/build: change order of config/Tools.mk inclusion Roger Pau Monne
2012-05-18 11:17 ` Ian Jackson
2012-05-18 11:29 ` Roger Pau Monne
2012-05-18 11:46 ` Ian Jackson
2012-05-18 11:52 ` Christoph Egger
2012-05-18 11:59 ` Roger Pau Monne
2012-05-18 13:30 ` Ian Jackson
2012-05-18 14:08 ` Christoph Egger
2012-05-22 14:48 ` Roger Pau Monne
2012-05-17 13:22 ` [PATCH v2 1/4] build/tools: disable libvchan build on NetBSD Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FB514FC.5040807@citrix.com \
--to=roger.pau@citrix.com \
--cc=Christoph.Egger@amd.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).