From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17844 invoked by alias); 20 Jul 2008 23:47:49 -0000 Received: (qmail 17833 invoked by uid 22791); 20 Jul 2008 23:47:48 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 20 Jul 2008 23:47:04 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KKicF-0001LS-Hh for gdb-patches@sources.redhat.com; Sun, 20 Jul 2008 23:46:59 +0000 Received: from 201.82.124.180 ([201.82.124.180]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Jul 2008 23:46:59 +0000 Received: from bauerman by 201.82.124.180 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 20 Jul 2008 23:46:59 +0000 To: gdb-patches@sources.redhat.com From: Thiago Jung Bauermann Subject: Re: [RFA] iRe: [RFC][patch 1/9] initial Python support Date: Sun, 20 Jul 2008 23:47:00 -0000 Message-ID: References: <20080429155212.444237503@br.ibm.com> <20080429155304.288626880@br.ibm.com> <20080528205921.GA2969@caradoc.them.org> <20080615181833.uxmo25mg0kko40kw@imap.linux.ibm.com> <1216107418.14956.27.camel@localhost.localdomain> <1216245620.12209.18.camel@localhost.localdomain> <20080718195010.GA14356@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00386.txt.bz2 Thiago Jung Bauermann wrote: > Daniel Jacobowitz wrote: >> On Wed, Jul 16, 2008 at 07:00:20PM -0300, Thiago Jung Bauermann wrote: >>> @@ -1283,7 +1303,11 @@ test-cp-name-parser$(EXEEXT): >>> test-cp-name-parser.o $(LIBIBERTY) >>> # duplicates. Files in the gdb/ directory can end up appearing in >>> # COMMON_OBS (as a .o file) and CONFIG_SRCS (as a .c file). >>> >>> -INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS) >>> +# NOTE: bauermann/2008-06-15: python.c needs to be explicitly included >>> +# because the generation of init.c does not work for .c files which >>> +# result in differently named objects (i.e., python/python -> >>> python.o). + >>> +INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS) python/python.c >> >> This comment doesn't make sense. python/python.c is already included >> in INIT_FILES, because of CONFIG_SRCS. > > Indeed. I just tried saving face by reproducing the problem which prompted > me to add python/python.c there in the first place, but couldn't. I don't > remember why I needed it at the time. Actually, I just found the problem. If Python support is not being compiled in, python/python.c will not be included in INIT_FILES. And the fact that python.o is in COMMON_OBS will not help because of the reason outlined in my comment. That's why I added python/python.c explicitly in INIT_FILES. Another way to solve the problem, which I am using this time, is to add the following else clause to configure.ac: if test "${have_libpython}" = yes; then AC_DEFINE(HAVE_PYTHON, 1, [Define if Python interpreter is being linked in.]) CONFIG_OBS="$CONFIG_OBS \$(SUBDIR_PYTHON_OBS)" CONFIG_DEPS="$CONFIG_DEPS \$(SUBDIR_PYTHON_DEPS)" CONFIG_SRCS="$CONFIG_SRCS \$(SUBDIR_PYTHON_SRCS)" CONFIG_INITS="$CONFIG_INITS \$(SUBDIR_PYTHON_INITS)" ENABLE_CFLAGS="$ENABLE_CFLAGS \$(SUBDIR_PYTHON_CFLAGS)" else # Even if Python support is not compiled in, we need to have python/python.c # included, in order to recognize the python command. Even though python.o is # in Makefile.in's COMMON_OBS, the code generating init.c won't include a # call to _initialize_python unless python/python.c is explicitly added to # INIT_FILES. CONFIG_SRCS="$CONFIG_SRCS python/python.c" fi -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center