GPM make error.

Ken Moffat ken at linuxfromscratch.org
Sun Dec 3 14:07:07 PST 2006


On Sun, Dec 03, 2006 at 11:12:37AM -0800, Dan Nicholson wrote:
> On 12/2/06, jignesh gangani <jgangani at gmail.com> wrote:
> >/usr/bin/ld:
> >/usr/lib/gcc/x86_64-unknown-linux-gnu/4.1.1/../../../../lib/libncurses.a(
> >lib-getch.o): relocation R_X86_64_32 against 'a local symbol' can not be
> >used when making a shared object; recompile with -fPIC
[...]
> Sorry, this is a CLFS question. It looks like ncurses needs to be
> built with -fPIC. x86_64 is sensitive to PIC while it's not fatal on
> x86. You've gotta find out over there how to get ncurses built the
> right way.
> 
> >Then I tried to recompile it with the following command
> >LDFLAGS="-lm -fPIC" make
> >But I get the same error.
> 
> Right. The problem is with the libncurses library. It's not gonna get
> fixed in gpm.
> 
 I beg to differ (in detail) - the problem is strictly from trying to
use libncurses.a on x86_64 in a shared object.  That can't be done,
but clfs DOES build the shared libraries.  The more general case on
x86_64 is a package needing -fPIC forced ao it can build.  For that,
CFLAGS _might_ work, but often it's easier to sed them into the
Makefile (the affected packages are usually idiosyncratic about how
they set themselves up).  But, LDFLAGS is usually used for other
things - if gpm already puts -lm into LDFLAGS, I guess that just
shows how unusual it is. 

 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 ?

 Jignesh, you should have a libncurses.so.  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).

 If you do have a usable libncurses.so, look at the configure output
from gpm (hopefully, it will be in config.log) to see if it tried to
use libncurses.so, and what sort of error message it got.

 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.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the blfs-support mailing list