Re: static musl-based gdb and -fPIC

[John Spencer <maillist-musl@barfooze.de>]

Zvi Gilboa wrote:
> On 04/30/2014 12:07 AM, Rich Felker wrote:
>> 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,

correct.

> and from --disable-tui it looks 
> like they encountered a similar problem with ncurses.  The version of 

no, --disable-tui was added so we don't have 2 nearly identical huge gdb 
binaries in /bin.
in fact we do not even link against ncurses, as gdb can be built against 
the much smaller termcap library.
(however ncurses will be picked up automatically if it was installed 
before building gdb, no problems there either.)

> 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

also for the record, the problem you encountered with -fPIC was due to a 
.so built unconditionally during gdbserver compilation, and if you have 
-static in your LDFLAGS, the buildsystem will try to create the .so with 
  both -shared and -static, instead of stripping the -static off for 
that step.
--disable-inprocess-agent can be used to get gdbserver without building 
that dso, which seems rather useless anyway.

--JS