From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9854 invoked by alias); 5 Jul 2011 13:57:59 -0000 Received: (qmail 9844 invoked by uid 22791); 5 Jul 2011 13:57:58 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from ausxippc101.us.dell.com (HELO ausxippc101.us.dell.com) (143.166.85.207) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Jul 2011 13:57:44 +0000 X-Loopcount0: from 10.152.240.141 Subject: Re: Undefined symbol while executing Python Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: <20110702020837.GG2421@adacore.com> Date: Tue, 05 Jul 2011 13:57:00 -0000 Cc: Content-Transfer-Encoding: quoted-printable Message-Id: References: <674EAAD3-EF0C-451B-BC73-5D39F33E6780@dell.com> <00001CBF-4AB1-41C4-988A-4D817CA8ED73@dell.com> <20110702020837.GG2421@adacore.com> To: Joel Brobecker X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00016.txt.bz2 On Jul 1, 2011, at 10:08 PM, Joel Brobecker wrote: >>> (gdb) python import itertools >>> Traceback (most recent call last): >>> File "", line 1, in ? >>> ImportError: /usr/lib/python2.4/lib-dynload/itertoolsmodule.so: undefin= ed symbol: PyObject_SelfIter >>> Error while executing Python code. > [...] >> More... The symbol is defined in libpython2.4.so. The native 7.0.1 >> gdb has that library in its required libraries list. The cross 7.2 >> gdb I built does not. That makes sense, it alllows that gdb to be >> executed on another machine that might not have the same python >> installed.=20=20 >=20 > Is GDB linked against the shared libpython? From what you are saying, > it seems like it is. But I know that there are problems when linking > against the static version of libpython. I have the following change > in python-config.py to deal with the same sort of issue after I linked > GDB with the static libpython. >=20 > + if platform.system() =3D=3D 'Linux': > + # Make sure that the loader can resolve symbols from > + # the libpython archive when loading modules impleme= nted > + # as DSOs (Eg: "import time"). This is to work arou= nd > + # a side-effect of linking against the static version > + # of libpython. > + libs.insert(0, '-Xlinker -export-dynamic') Thanks, that cured the problem (once I figured out where to insert it). It= turns out that, while there is a /usr/lib/libpython2.4, the gdb link is do= ne against /usr/lib/python2.4/config/libpython2.4.a. I'm not sure why. It= 's probably actually a good thing because that binary is being built for a = group of people, some of whom have a different version of python installed. Anyway, it would be good if gdb built correctly (i.e., with that switch) ou= t of the box rather than requiring manual non-obvious hacking. paul