From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3157 invoked by alias); 22 Nov 2001 12:32:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 3058 invoked from network); 22 Nov 2001 12:32:12 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sourceware.cygnus.com with SMTP; 22 Nov 2001 12:32:12 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id NAA27373; Thu, 22 Nov 2001 13:31:47 +0100 Message-Id: <4.2.0.58.20011122133115.01a3e7f8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 09 Nov 2001 23:40:00 -0000 To: tromey@redhat.com, Elena Zannoni , Christopher Faylor From: Pierre Muller Subject: Re: PATCH: --args => build failure Cc: gdb-patches@sources.redhat.com In-Reply-To: <4.2.0.58.20011122123701.01d55a20@ics.u-strasbg.fr> References: <4.2.0.58.20011122121440.01d54488@ics.u-strasbg.fr> <87r8qrhg57.fsf@creche.redhat.com> <873d3mcpcu.fsf@creche.redhat.com> <3BED93E7.9000104@cygnus.com> <87snbmb9nm.fsf@creche.redhat.com> <15356.10158.489653.156184@krustylu.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2001-11/txt/msg00194.txt.bz2 At 12:39 22/11/2001 , Pierre Muller a écrit: >At 12:17 22/11/2001 , Pierre Muller a écrit: >>At 00:13 22/11/2001 , Tom Tromey a écrit: >>> >>>>> "Elena" == Elena Zannoni writes: >>> >>>Elena> main.c changes are ok. >>> >>>Thanks! I think that's the last approval I need. I'll check the >>>patch in this evening. >>> >>>I assume I should close the corresponding PRs. What is the gdb >>>process for this? Do I simply close them? Put them in `feedback'? >>>Or what? >> >> Your patch does create a build failure for cygwin target. >> >> This target apparently does not use fork-child.c >>(at least it is not included into the libgdb.a) >>and thus I get the following error when I try to build the current main >>CVS tree: >> >>$ make >>rm -f gdb.exe >>gcc -g -O2 -o gdb.exe \ >>main.o libgdb.a cli-decode.o cli-script.o cli-cmds.o cli-setshow.o >>cli-utils.o m >>i-out.o mi-console.o mi-cmds.o mi-cmd-var.o mi-cmd-break.o mi-cmd-stack.o >>mi-cmd >>-disas.o mi-main.o mi-parse.o mi-getopt.o ../bfd/libbfd.a >>../readline/libread >>line.a ../opcodes/libopcodes.a ./../intl/libintl.a >>../libiberty/libiberty.a `if >>test -r ../libtermcap/libtermcap.a; then echo ../libtermcap/libtermcap.a; >>else e >>cho -ltermcap; fi` -lm ../libiberty/libiberty.a -luser32 -limagehlp\ >> >>libgdb.a(gdbarch.o): In function `gdbarch_alloc': >>/home/muller/gdb/build/gdb/../../src/gdb/gdbarch.c:509: undefined >>reference to ` >>construct_inferior_arguments' >>/home/muller/gdb/build/gdb/../../src/gdb/gdbarch.c:482: undefined >>reference to ` >>construct_inferior_arguments' >>collect2: ld returned 1 exit status >>make: *** [gdb.exe] Error 1 > > For you info: >compiling fork-child.o by calling >make fork-child.o >adding fork-child.o to libgdb.a with >ar t libgdb.a fork-child.o >and running make again >seems to be enough to get a new gdb executable. > >But I have no real idea where dependency of fork-child file must be added. Maybe the best solution would be to move this command into a file that is loaded for all targets, what about infrun.c ? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99