From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18277 invoked by alias); 4 Dec 2006 20:37:09 -0000 Received: (qmail 18263 invoked by uid 22791); 4 Dec 2006 20:37:07 -0000 X-Spam-Check-By: sourceware.org Received: from mail.zeugmasystems.com (HELO zeugmasystems.com) (192.139.122.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Dec 2006 20:36:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GDB 6.5.90 available for testing (GDB 6.6 pre-release) Date: Mon, 04 Dec 2006 20:37:00 -0000 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D4B607D@exchange.ZeugmaSystems.local> From: "Kaz Kylheku" To: "Joel Brobecker" , "Marc Kleine-Budde" Cc: X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00027.txt.bz2 Joel Brobecker wrote:=20 > > The problem with libtermcap resp. libncurses in a non=20 > default location=20 > > still exists. See PR2175, PR2176 and=20 > > http://sources.redhat.com/ml/gdb/2006-10/msg00234.html > >=20 > > This is a combined version of Kaz and my patch. Please=20 > consider applying=20 > > or has the Makefile.tpl to be modified? >=20 > Thanks for the feedback. Unfortunately, there is not enough context in > what you provided to understand what happened. It looks like=20 > your patch > was never reviewed (only from the pieces I have, but I may be wrong). > My suggestion, if you'd like this to be included, is to post again > the patch on gdb-patches, and ask for review. Use the patch tracker > if necessary to make sure it doesn't get overlooked (but this does > NOT guaranty fast review). >=20 > Once it is head, then we can discuss whether we want this patch > in the branch or not. >=20 > --=20 > Joel I no longer care about the patch, because I solved the problem differently, for other reasons. I still think that if GDB's has the apparent suport locating libraries in non-default locations, then that support should work. Or else it should be dropped. I.e. don't allow a variable to be configured in the top level configure, if the lower levels are going to ignore it. The original problem was that I was installing libraries such as ncurses into their own directories, so that I could easily make binary packages, without having to extract the installed materials from the cross-compiling toolchain sysroot. I quickly found out that gdb couldn't be configured to find ncurses in a nonstandard location and developed a patch, which turned out to be nearly the same as Marc's. But having libraries in nonstandard locations will cause problems in general. Every time you build anything which depends on them, it will have to be configured to find them, which means figuring out /how/ to configure it to find them, and debugging it when that doesn't work. The solution, for me, is to install ncurses (and indeed all libraries) into two places: install it into the a directory from which a package is made, /and/ also install it into the cross-compiling toolchain's sysroot. (I don't do this second step with a ``make install'' but rather by selective recursive copying from the temporary install dir). And so, I backed out my patch. Note that I'm also preparing a prebuilt toolchain distribution with all the libraries, header files and documentation. So when a library package is built and installed, a packaging step builds tarballs from the install directory, and a toolchain install step copies materials into the toolchain sysroot, making that library available for linking. In this toolchain, I don't want to expose people to problems of locating libraries. Linking ncurses should just be ``arch-prefix-gcc ... objects ... -lncurses''. But I still want a binary package of ncurses to install on the target without having to extract the pieces from the toolchain sysroot.=20