This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: unable to compile gdb 6.0 as a cross gdb; no termcap library found; and plain gcc is still called
- From: "Wolcott, Ken (MED, Compuware)" <Ken dot Wolcott at med dot ge dot com>
- To: Dan Kegel <dank at kegel dot com>
- Cc: kleine-budde at gmx dot de, crossgcc at sources dot redhat dot com, gdb mailing list <gdb at sources dot redhat dot com>
- Date: Tue, 28 Oct 2003 15:29:56 -0600
- Subject: Re: unable to compile gdb 6.0 as a cross gdb; no termcap library found; and plain gcc is still called
- Organization: GEMS-IT
- References: <200310271747.52297.ken.wolcott@med.ge.com> <200310281320.07996.ken.wolcott@med.ge.com> <3F9EC941.3010007@kegel.com>
- Reply-to: "Wolcott, Ken (MED, Compuware)" <ken dot wolcott at med dot ge dot com>
Hi Dan;
I think your assessment is correct, I really need to immerse myself in
crosstool and even in Linux itself. I thought I knew so much :-)
I did not build the arm9 cross with --builduserland
but I am now :-)
I will also follow your other suggestions.
Thanks,
Ken
On Tuesday 28 October 2003 13:53, Dan Kegel wrote:
> Hi Ken,
> hmm. Methinks you could use a Linux expert to sit down with you
> and guide you through this stuff. Failing that, you need
> to become an expert. The learning curve is steep, so put on
> your crampons and grab an ice axe!
>
> /etc should not be in PATH; that's a red herring.
>
> More likely, the "no termcap library found" error means
> you haven't build a termcap for your target yet.
> crosstool-0.24 will install termcap.h and libncurses.so (which
> implements the termcap functions) if you pass the --builduserland
> option to all.sh. Did you?
>
> When you run into a configure failure like this one, the thing
> to do is to edit the configure script in question, locate the
> section that is failing, look backwards towards the top of
> the file a bit until you find the beginning of the test,
> and add a
> set -x
> statement, then run the configure again, redirecting the output
> of configure to a file. This produces reams of output which
> you then compare with the configure script to see what it was
> testing for, and what failed.
>
> In other words: you have to actually *read* and *understand*
> parts of the configure script, not just run it.
> It's much easier to do if you also read the configure.in or configure.ac
> script, which is what configure is expanded from.
>
> This will cause your head to explode if you do it without first
> learning a bit about autoconf. I'd suggest working through one
> of the autoconf tutorials I link to at
> http://www.kegel.com/academy/opensource.html#autotools
> and writing a trivial configure.ac to make sure you understand
> how they work. (e.g. write a C program that includes the file
> <snorglepuss.h> only if it exists; use autoconf's AC_CHECK_HEADERS
> macro to check for the existence of <snorglepuss.h>. This will take
> several hours the first time you do it, but it's well worth the effort.)
> Think of it as one more little step on the way to becoming a Linux expert.
> - Dan
>