From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7973 invoked by alias); 20 Jan 2014 18:49:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 7948 invoked by uid 89); 20 Jan 2014 18:49:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Jan 2014 18:49:55 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0KInsCT024807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 20 Jan 2014 13:49:54 -0500 Received: from barimba.redhat.com (ovpn-113-85.phx2.redhat.com [10.3.113.85]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s0KIns50016576 for ; Mon, 20 Jan 2014 13:49:54 -0500 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [RFC 0/2] let gdbserver use libiberty Date: Mon, 20 Jan 2014 18:49:00 -0000 Message-Id: <1390243792-31176-1-git-send-email-tromey@redhat.com> X-SW-Source: 2014-01/txt/msg00743.txt.bz2 This series changes gdbserver to build its own copy of libiberty (using ACX_CONFIGURE_DIR) and then link against it. I've needed this at least once (for a cloexec patch) and I've seen other situations where it would have been useful. This is of course not the ideal way to depend on libiberty -- better would be to use the same build that gdb uses. However, due to the requirement that gdbserver be separately configurable, this is the best that can be done immediately. FWIW I do have a branch to move common, gnulib, and gdbserver to top-level. However, that branch still has some issues to be sorted out (namely, what to rename "common", and how to compute the definition of CORE_ADDR); and in any case a patch like this one would be required at some point in the process -- and it seems useful to have it sooner rather than later. Built and regtested on x86-64 Fedora 18. Tom