Re: static musl-based gdb and -fPIC

[Zvi Gilboa <zg7s@eservices.virginia.edu>]

On 04/30/2014 12:07 AM, Rich Felker wrote:
> On Tue, Apr 29, 2014 at 11:26:56PM -0400, writeonce@midipix.org wrote:
>> On 04/29/2014 10:57 PM, Rich Felker wrote:
>>> On Tue, Apr 29, 2014 at 05:40:06PM -0400, writeonce@midipix.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