From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12040 invoked by alias); 15 Apr 2002 17:06:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11997 invoked from network); 15 Apr 2002 17:06:31 -0000 Received: from unknown (HELO d12lmsgate-3.de.ibm.com) (195.212.91.201) by sources.redhat.com with SMTP; 15 Apr 2002 17:06:31 -0000 Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id TAA173842; Mon, 15 Apr 2002 19:06:18 +0200 Received: from d12ml033.de.ibm.com (d12ml033_cs0 [9.165.223.11]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3FH6Ie31658; Mon, 15 Apr 2002 19:06:18 +0200 Received: from kontiki ([9.164.165.87]) by d12ml033.de.ibm.com (Lotus Domino Release 5.0.9a) with SMTP id 2002041519061582:1443 ; Mon, 15 Apr 2002 19:06:15 +0200 From: "Dr. Jochen =?iso-8859-1?Q?R=F6hrig?=" Organization: IBM Deutschland Entwicklung GmbH To: gdb@sources.redhat.com Subject: Re: S/390 Linux doesn't link on trunk Date: Mon, 15 Apr 2002 10:06:00 -0000 References: <20020407173859.A31836@nevyn.them.org> In-Reply-To: <20020407173859.A31836@nevyn.them.org> Cc: Daniel Jacobowitz , msnyder@redhat.com MIME-Version: 1.0 Message-Id: <02041519022500.02708@kontiki> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-04/txt/msg00255.txt.bz2 On Sunday, 7. April 2002 23:38, you wrote: > Just FYI; I didn't try the branch. The error is: > > gcc -O2 -g -Wl,-rpath,/usr/lib -o gdb \ > main.o libgdb.a cli-dump.o cli-decode.o cli-script.o cli-cmds.o > cli-setshow.o cli-utils.o mi-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 tui-file.o tui.o tuiData.o tuiSource.o tuiStack.o tuiIO.o > tuiGeneralWin.o tuiLayout.o tuiWin.o tuiCommand.o tuiDisassem.o > tuiSourceWin.o tuiRegs.o tuiDataWin.o tui-out.o tui-hooks.o=20=20=20 > ../bfd/libbfd.a -lreadline ../opcodes/libopcodes.a=20 > ../libiberty/libiberty.a -lncurses -lm ../libiberty/libiberty.a \ -l= dl > -rdynamic > libgdb.a(inftarg.o): In function `init_child_ops': > /home/buildd/build/gdb-5.2.cvs20020401/objdir/gdb/../../gdb/inftarg.c:754: > undefined reference to `child_pid_to_exec_file' collect2: ld returned 1 The problem can be circumvented by adding a #undef CHILD_PID_TO_EXEC_FILE after the "#include "config/nm-linux.h"-line in config/s390/nm-linux.h (at= =20 least the current Debian gdb-source package version 5.2.cvs20020401-3 build= s=20 after this modification and gbd seems to work). The problem arises from the unconditional definition of=20 CHILD_PID_TO_EXEC_FILE at the end of config/nm-linux.h. According to the=20 CVS-log this was added in Revision 1.11 of config/nm-linux.h on January, 8t= h.=20 There were also changes made in config//linux.mh for some architectur= es=20 (linking with linux-proc.o), which, as far as I can judge it, avoid the abo= ve=20 described problem on theses architectures. However s390 (and, as it seems,= =20 some other architectures), doesn't have a config//linux.mh so no=20 modifications were made for s390. My question now: are we missing something for s390 because we don't have th= e=20 config/s390/linux.mh-file or are the changes to config/s390/nm-linux.h that= I=20 described above a correct solution for the problem? Or would it instead be = a=20 better solution to add a "NATDEPFILES +=3D linux-proc.o" to config/s390/s39= 0.mh? Jochen --=20 Dr. Jochen R=F6hrig Linux for eServer Development IBM Deutschland Entwicklung GmbH, Sch=F6naicher Str. 220, 71032 B=F6blingen roehrig@de.ibm.com