GPM make error.

Ken Moffat ken at
Tue Dec 5 04:57:00 PST 2006

On Tue, Dec 05, 2006 at 12:51:47PM +0530, jignesh gangani wrote:
> First of All, Thank you Dan and Ken,
> Now,
>  | I have no use for, nor interest in, gpm so I don't know what the
> >
> >fix is, but I'm sure some people build it on x86_64.  The original
> >post mentioned both 1.19 and 1.20 for libgpm, I assume that was a
> >typo ?
> No Ken, It is not a typo. I have double checked it.
 Sorry, that was my mistake - I skimmed your original mail, now I
see that 1.19.0 the name of the shared library target.
> Jignesh, you should have a  I've seen situations
> >where I tried to apply the LFS instructions for libncursesw on clfs
> >and screwed up mightily - have you perhaps tried to do that?  (I'm
> >preparing a hint for clfs, but it isn't ready yet).
> I haven't installed anything after building my CLFS system. GPM is the first
> package. I have a working ncurses as I can see ncurses UI when I built my
> Kernel with "make menuconfig"

 I'll assume you followed CLFS, and therefore your ncurses should be
correctly installed without wide character support.  What I was
trying to say is that there are several different libraries within
the ncurses package, and accidental breakage [ caused by installing
differently ] can take a long while to show up.
> If you do have a usable, look at the configure output
> >from gpm (hopefully, it will be in config.log) to see if it tried to
> >use, and what sort of error message it got.
> ./configure --prefix=/usr
> Here are the snippets of config.log
> configure:1355:checking for ncurses.h
> configure:1365:gcc -E conftest.c >/dev/null 2>conftest.out
> configure:1355:checking for ncurses/curses.h
> configure:1365:gcc -E conftest.c >/dev/null 2>conftest.out
> configure:1361:28:error: ncurses/curses.h: No such file or directory
> configure:failed program was:
> #lline 1360 "configure"
> #include "confdefs.h"
> #include <ncurses/curses.h>
 That is expected, we don't put the headers in an ncurses/
> configure:1355:checking for curses.h
> configure:1365:gcc -E conftest.c >/dev/null 2>conftest.out
> (No Error)
 Also ok.
> ...
> configure:1829:checking for tputs in -ltinfo
> configure:1848:gcc -o conftest -g -O2 conftest.c -ltinfo 1>&5
> /usr/bin/ld: cannot find -ltinfo
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 1837 "configure"
> #include "confdefs.h"
> /* Override any gcc2 internal prototype to avoid an error. */
> /* We use char because int might match the return type of a gcc2 builtin and
> then its argument prototype would still apply. */
> char tputs();
> int main() {
> tputs()
> ; return 0; }
 OK, we don't have libtinfo.
> configure:1829: checking for tputs in -lncurses
> configure:1848: gcc -o conftest -g -O2 conftest.c -lncurses 1>&5
> configure:1901:gcc -o conftest -g -O2 conftest.c -lncurses -lncurses 1>&5
> (No Error)
 You have some sort of libncurses (either .a or .so - hopefully, ld
will try to use .so first but I'm unsure about how that happens, I
only know that I see all manner of messages about incompatible
libraries being ignored on multilib).
> As with all attempts to use an extra package on an architecture
> >where nobody has provided a solution, first look at your local gentoo
> >mirror to see if there is anything interesting in their ebuild or
> >patches, and if that fails look at fedora (I think you are on pure64
> >and fedora only do multilib, but x86_64 fixes might still apply) -
> >you'll need an rpm2cpio script and cpio to discover what is in an
> >srpm, which is why I'm pointing you to gentoo first - you can (mostly)
> >make sense of what is going on in an ebuild by reading it in your
> >browser.
> >
> I have seen gpm package for x86_64 on gentoo mirror site. But it is in
> ebuild format and
> I do not know how to build such package.
 I don't intend you to run ebuild.  I'm looking at the gpm ebuild at
the moment (and to be honest I don't see anything relevant to your
problem) - think of these ebuilds as a fairly high-level script, and
pay particular attention to anything in the comments.  In this case,
I can see things like econf using --libdir and --sysconfdir (options
to pass to configure - libdir is for multilib).  After that, in this
example it becomes harder to follow - dosym obviously creates
symbolic links, gen_usr_ldscript is harder to grok.  Sometimes,
gentoo have patches which help on exotic architectures, sometimes
they use a sed command to fix something.  In this case, nothing
looks relevant.

 From memory, you are on pure64 ?  I've just fired up my pure64
amd64 and gpm-1.20.1 builds for me with the clfs patches and
instructions.  That system is clfs-1.0.0 with ncursesw.

 I'm beginning to think that something within your ncurses
installation is wrong (¡expletive! - that would mean Dan was right
and it is a clfs problem).  Please take a look at all the ncurses
files in /lib and /usr/lib (the date and time should help you identify
them), things like libform, libmenu, libncurses, libpanel, libmenu,
and libcurses.  Normally, each of these should have one static (.a)
archive in /usr/lib and a series of shared objects (.so*) which
ultimately point to a binary.  In a straight clfs install, the
pointing is all done by symlinks, so should be the
binary, and it should be in /lib.  All the libcurses and libncurses
shared objects in /usr/lib should link to this through a series of

 For each of the libraries I listed, first verify that there is a
binary .so.5.5 in /usr/lib with a size in the tens or hundreds of
kilobytes (instead of a file with only a few bytes containing a link
instruction), then verify that each of the other .so* variants in /lib
and /usr/lib has an unbroken chain of symbolic links to get to the

das eine Mal als Tragödie, das andere Mal als Farce

More information about the blfs-support mailing list