[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <537E5A8D.8090701@barfooze.de>
Date: Thu, 22 May 2014 22:14:05 +0200
From: John Spencer <maillist-musl@...fooze.de>
To: musl@...ts.openwall.com
CC: zg7s@...rvices.virginia.edu
Subject: Re: static musl-based gdb and -fPIC
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
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.
