From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4995 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: static musl-based gdb and -fPIC Date: Wed, 30 Apr 2014 00:07:58 -0400 Message-ID: <20140430040758.GG26358@brightrain.aerifal.cx> References: <5353FDD0.6090903@midipix.org> <20140420203140.GA26358@brightrain.aerifal.cx> <53601C36.7050601@midipix.org> <20140430025752.GE26358@brightrain.aerifal.cx> <53606D80.4070803@midipix.org> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1398830897 2319 80.91.229.3 (30 Apr 2014 04:08:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Apr 2014 04:08:17 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4999-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 30 06:08:12 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WfLoa-0005B6-6O for gllmg-musl@plane.gmane.org; Wed, 30 Apr 2014 06:08:12 +0200 Original-Received: (qmail 24116 invoked by uid 550); 30 Apr 2014 04:08:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24108 invoked from network); 30 Apr 2014 04:08:10 -0000 Content-Disposition: inline In-Reply-To: <53606D80.4070803@midipix.org> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:4995 Archived-At: 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. > >>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