bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

installing GNUstep on YDL 4.0


From: Gary Byers
Subject: installing GNUstep on YDL 4.0
Date: Sun, 3 Apr 2005 14:46:05 -0600 (MDT)

I had some problems trying to install GNUstep on Yellow Dog Linux 4.0
(a PPC Linux distribution derived from Fedora Core 2).  I tried using
GNUstep startup (including version 0.10.0) and tried building and
installing the packages individually, with the same results.  (I also
tried - and got the same results with - the RPM packages that were
built for YDL 3.0).

In all cases, the problems had to do with the fact that the
gnustep-base libarary wound up with external references to symbols (a
handful of things from libc, IIRC) that used direct PC-relative
("R_PPC_REL24") relocation.  Programs linked against this library
would fail to run (perhaps either because the symbols in question were
too far away from their referents in memory or because the dynamic
linker thought that the whole idea of this type of external reference
was kind of suspicious.  I'm not entirely sure why this worked in YDL
3.0, but changes in memory layout and changes in policy both seem to
provide plausible explanations.)

The offending references all came from code from statically-linked
versions of the ffcall libraries.  After trying a few other approaches,
I was able to get things to seemingly work by:

  a) ensuring that no other versions of the ffcall libraries were
     publicly installed
  b) adding "--enable-shared --disable-static" to the options that
     InstallGNUstep uses to configure ffcall, e.g.:

--- InstallGNUstep~     2005-04-01 08:49:24.000000000 -0700
+++ InstallGNUstep      2005-04-03 10:59:22.238812667 -0600
@@ -559,7 +559,8 @@
 PKG_DISPLAY="ffcall"
 PKG_CONFIG="--prefix=$gs_install_prefix$GNUSTEP_SYSTEM_ROOT \
    --libdir=$gs_install_prefix$GNUSTEP_SYSTEM_ROOT/Library/Libraries \
-   --includedir=$gs_install_prefix$GNUSTEP_SYSTEM_ROOT/Library/Headers"
+   --includedir=$gs_install_prefix$GNUSTEP_SYSTEM_ROOT/Library/Headers\
+   --enable-shared --disable-static"
 PKG_INSTALL=
 PKG_PATCHES=
 gsexitstatus=0


This persuaded ffcall to build shared versions of at least -some- of
its libraries, and GNUstep libraries linked against those shared ffcall
libraries had reasonable relocations (and the build process completed
successfully.)

I'm not sure what a better, long-term fix would involve.  (I tried
building and installing a current CVS version of ffcall, but there
seem to have been some API changes which caused compilation of
GSFFCallInvocation.m to fail.)  Seemingly, it'd be necessary to not
trust or use any installed static ffcall libraries, at least on the
ppc, as a first step.

I compiled and installed 'gnustep-examples' and things seem to be
working.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]