|
Message-ID: <53607C30.4010207@eservices.virginia.edu> Date: Wed, 30 Apr 2014 00:29:36 -0400 From: Zvi Gilboa <zg7s@...rvices.virginia.edu> To: <musl@...ts.openwall.com> Subject: Re: static musl-based gdb and -fPIC On 04/30/2014 12:07 AM, Rich Felker wrote: > On Tue, Apr 29, 2014 at 11:26:56PM -0400, writeonce@...ipix.org wrote: >> On 04/29/2014 10:57 PM, Rich Felker wrote: >>> On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@...ipix.org wrote: >>>> I built a static gdb (v7.7, passing --disable-gdbserver to >>>> configure) and _thought_ that everything was fine. Then I checked >>>> the build logs and saw that gdb refused to use the present libexpat, >>>> libncurses/tinfo, and libpython. In the case of expat, at least, >>>> the "solution" was easy, albeit unacceptable: temporarily break my >>>> local system by renaming libexpat.so (so that gdb cannot find it). >>>> But for ncurses and python that didn't work. >>>> >>>> It appears that expat is passed to the linker as a full path >>>> (/full/path/to/libexpat.so) rather than normally (-lexpat), which >>>> makes the whole thing break since there is no way to request a >>>> static expat instead. Note, however, that this problem is not >>>> musl-specific >>>> (https://sourceware.org/ml/crossgcc/2013-06/msg00003.html). >>> It's not clear at all to me from your email or from the linked thread >>> who the passer in "is passed" might be. Is this something broken in >>> gdb's build script, or expat's pkg-config or similar, or ct-ng, or >>> something else? >> Pardon. The expat pkg-config file (expat.pc) is fine. It is the >> gdb script that passes /full/path/to/libexpat.so to the linker, >> which then complains about an attempt to statically link a dynamic >> library. As far as I can tell the problem is somewhere in the >> configure script under the gdb sub-directory. > You might should check the patches used by sabotage or one of the > other dists using musl. They probably have dealt with the gdb bugs and > probably already have a good fix or workaround. Sabotage has several gdb patches, but none of them addresses this. From the [deps] section, it looks like sabotage does not aim to have the python functionality in its static gdb, and from --disable-tui it looks like they encountered a similar problem with ncurses. The version of gdb that I built is a bit newer than sabotage's (7.7 vs. 7.6/7.5), but I don't believe that matters. > >>>> At this point I am no longer seeking a solution (unless you have one >>>> ready), but thought I should share this for the record. As an >>>> aside, it looks like the static python interpreter is missing some >>>> modules as well (see, for instance, >>>> https://trac.torproject.org/projects/tor/ticket/7557). >>> Static python is not very useful since most important python >>> extensions are partly implemented as C code, which necessarily must be >>> dynamically loaded. >>> >> The purpose of building a static python was to make a static >> libpython.a available for gdb. Given the loss of functionality on >> both the python and gdb ends, it might be better to leave the two >> dynamically linked as they were meant to be... > I always just build gdb without python (I'm not much of a python fan). > The ideal solution would be separating python out to run as a separate > process communicating with gdb rather than actually embedding python > in gdb. I really doubt python is anything remotely clean for embedding > into other programs. > > Rich Thanks for the tip. My knowledge of python is actually rather limited; I just need it to work since many tests in llvm/clang depend on it... zg
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.