Re: [Gcl-devel] Maxima GCL buld trouble

[Vadim V. Zhytnikov]

Some results:

(1) to build GCL statically it is necessary
   (a) add -static switch to LDCC in h/linux.defs
   (b) replace $(CC) -> $(LDCC) in the raw_gcl build
       rule in unixport/makefile.

(2) even with (1) build fails to me on raw_gcl link
stage due to unresolved symbols. But this is another
story already - configure fails to add libtinfo
to the link command. libtinfo is a new library
which appeared in recent libncurses incarnations.
I modified configure adding libtinfo to
the ncurses check.

(3) with (1) and (2) static GCL builds.

(4) but when I try to build Maxima on the top
of this static gcl I got yet another trouble.
Process stops very early during compile of the
6th file commac.lisp:

Compiling /home/vadim/RPM/BUILD/maxima/src/commac.lisp.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling binary-gcl/commac.o.

;      - Loading binary file "binary-gcl/commac.o"
Loading binary-gcl/commac.o

Error: Undefined symbol
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by FUNCALL.
Broken at LOAD.  Type :H for Help.

I verified that commac.o and all previously compiled
5 files (sloop.0, lmdcls.o, letmac.o, kclmac.o, clmacs.o)
are byte to byte identical with ones created during
successfully maxima build with _dynamically_ linked GCL.
Nevertheless if I do
  (load "maxima-package.lisp")
  (load "sloop.o")
  (load "lmdcls.o")
  (load "letmac.o")
  (load "kclmac.o")
  (load "clmacs.o")
  (load "commac.o")
with dynamic GCL - everything is fine.
With static GCL
  Error: Undefined symbol
on (load "commac.o") load call.


Camm Maguire ?????:
> Hi Vadim!  If you want to try a static libc, which should fix this, do
> this in linux.defs:
>
> # under redhat 6.1 and slackware 7.0 we needed to have this
> # link be static, but should be ok with the fix to unixport/rsym_elf.c
> LDCC=${CC} -static
> ######  comment this out for static libc link ###### LDCC=${CC}
>
> ldd on the binary should indicate that all libs are statically linked
> in. 
>
> I'd be interested to know of the details of your experience here.  We
> will doubtlessly have to bring this up with the emacs people.
>
> I'm assuming you are doing the 'traditional' maxima gcl build,
> i.e. doing the save-system after the .o files have been loaded.  This
> should be fine given your description of the problem.  But just to let
> you know, there is an --enable-gcl-altlink option to the maxima
> configure, which will effectively use ld to link in the .o files into
> raw_maxima via compiler::link, and then run the interpreted maxima
> init code, and save the system at this later stage.  This is required
> on machines where GCL currently cannot relocate .o files into the
> running image (mips(el), hppa, ia64, and alpha), but can be run
> anywhere.  Doesn't sound like you need this though.
>
> Take care,
>
> "Vadim V. Zhytnikov" <address@hidden> writes:
>
>
> > I'm trying to build Maxima with GCL 2.5.3 in such a way
> > to make it work on any rpm-based linux distro with
> > i586 cpu or greater. Unfortunately I hit the problem
> > which Camm described recently - resulting Maxima binaries
> > segfaults if I run them  on the system with glibc version
> > different from build host glibc. Strange thing is that
> > GCL itself works fine, but Maxima build on the top of
> > this GCL crashes.
> >
> > What might be the cure?  Will static GCL build help?
> > I already linked all other libraries (libreadline, libncurses)
> > statically but I don't know how to build GCL
> > statically with glibc.
> >
> > Any help is greatly appreciated.  I wrote the paper about
> > Maxima for Russian computer journal and this binaries
> > are intended to be included on the attached CD-ROM.
> > I have to produce them in two days :(
> >
> > I also noticed that if I configure GCL with
> > given --build=... --host=... and --enable-locbfd
> > then gmp subconfigure respects the --host but
> > libbfd ignores it. Is this correct?
> >
> > --
> >      Vadim V. Zhytnikov
> >
> >       <address@hidden>
> >      <address@hidden>
> >
> >
> >
> >
> > _______________________________________________
> > Gcl-devel mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/gcl-devel


--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>