[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140430040758.GG26358@brightrain.aerifal.cx>
Date: Wed, 30 Apr 2014 00:07:58 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: static musl-based gdb and -fPIC
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.
> >>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
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.
