RE: GDB 6.5.90 available for testing (GDB 6.6 pre-release)

["Kaz Kylheku" <kaz at zeugmasystems dot com>]

Joel Brobecker wrote: 
> > The problem with libtermcap resp. libncurses in a non 
> default location 
> > still exists. See PR2175, PR2176 and 
> > http://sources.redhat.com/ml/gdb/2006-10/msg00234.html
> > 
> > This is a combined version of Kaz and my patch. Please 
> consider applying 
> > or has the Makefile.tpl to be modified?
> 
> Thanks for the feedback. Unfortunately, there is not enough context in
> what you provided to understand what happened. It looks like 
> 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).
> 
> Once it is head, then we can discuss whether we want this patch
> in the branch or not.
> 
> -- 
> 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.