Re: [Gcl-devel] Maxima GCL buld trouble

[Vadim V. Zhytnikov]

Hi Camm!

Here is the summary of problems I encountered
to build GCL and subsequently Maxima statically.
In general if we don't use dynamic system libgpm
and dynamic libbfd GCL depends on glibc and
readline/ncurses.

So I've tried two options:

(1) Build GCL with static readline/ncurses but
dynamic glibc.

(2) Build GCL with static readline/ncurses/glibc.

Both GCL (1) and (2) works fine on several Linux
installation I've tried (glibc 2.2.5 and 2.2.6,
readline 4.3, 4.2a ...).

Next I've tried to build Maxima with this two GCL
versions and standard Maxima build procedure.

Purely static GCL (2) failed to build Maxima
due to unresolved symbols (see my previous post).

GCL (1) (dynamic glibc, static readline)
successfully builds Maxima image and this image
works fine on the machine where it was build.
But if I try in any slightly different environment:
in particular - the same glibc version 2.2.6
just different glibc releases (say 2.2.6-alt6
vs 2.2.6-alt3) - then Maxima segfaults immediately
after start.

On the other hand if I build GCL with dynamic
glibc and readline or dynamic glibc and no readline
support then everything seems to be OK - Maxima
works fine on glibc 2.2.6 and 2.2.5.

And finally about alternative Maxima build method
enabled by --enable-gcl-alt-link.  It doesn't work
to me. The procedure fails on linking maxima
stage:

;  - Providing system maxima
gcl -batch -eval (let ((argv '())) (declare (ignorable argv)) (progn 
(compiler::link (list  "/home/vadim/RPM/BUILD/maxima/src/file" 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/sloop.o" 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/lmdcls.o"
<snip>
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/hyp.o" 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/todd-coxeter.o" 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/mactex.o" 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/plot.o" 
"/home/vadim/RPM/BUILD/maxima/src/file" 
"/home/vadim/RPM/BUILD/maxima/src/file" 
"/home/vadim/RPM/BUILD/maxima/src/file" 
"/home/vadim/RPM/BUILD/maxima/src/file") 
"/home/vadim/RPM/BUILD/maxima/src/binary-gcl/maxima" "(provide 
\"maxima\")" "" t)) (values))
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/lmdcls.o(.text+0x550): In 
function `init_code':
: multiple definition of `init_code'
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/sloop.o(.text+0x9de0): first 
defined here
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/letmac.o(.text+0xf40): In 
function `init_code':
: multiple definition of `init_code'
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/sloop.o(.text+0x9de0): first 
defined here
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/kclmac.o(.text+0x290): In 
function `init_code':
<snip>
: multiple definition of `init_code'
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/sloop.o(.text+0x9de0): first 
defined here
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/plot.o(.text+0x0): In 
function `init_code':
: multiple definition of `init_code'
/home/vadim/RPM/BUILD/maxima/src/binary-gcl/sloop.o(.text+0x9de0): first 
defined here
user-init.o(.text+0x5e): In function `user_init':
: undefined reference to `init_lmdcls'
user-init.o(.text+0x73): In function `user_init':
: undefined reference to `init_letmac'
user-init.o(.text+0x88): In function `user_init':
: undefined reference to `init_kclmac'
user-init.o(.text+0x9d): In function `user_init':
: undefined reference to `init_clmacs'
<snip>
user-init.o(.text+0x13f4): In function `user_init':
: undefined reference to `init_hyp'
user-init.o(.text+0x1409): In function `user_init':
: undefined reference to `init_todd_coxeter'
user-init.o(.text+0x141e): In function `user_init':
: undefined reference to `init_mactex'
user-init.o(.text+0x1433): In function `user_init':
: undefined reference to `init_plot'
user-init.o(.data+0x4688): undefined reference to `init_lmdcls'
user-init.o(.data+0x4690): undefined reference to `init_letmac'
user-init.o(.data+0x4698): undefined reference to `init_kclmac'
user-init.o(.data+0x46a0): undefined reference to `init_clmacs'
<snip>
user-init.o(.data+0x4db8): undefined reference to `init_desoln'
user-init.o(.data+0x4dc0): undefined reference to `init_elim'
user-init.o(.data+0x4dc8): undefined reference to `init_trgsmp'
user-init.o(.data+0x4dd0): undefined reference to `init_ode2'
user-init.o(.data+0x4dd8): undefined reference to `init_invert'
user-init.o(.data+0x4de0): undefined reference to `init_hypgeo'
user-init.o(.data+0x4de8): undefined reference to `init_hyp'
user-init.o(.data+0x4df0): undefined reference to `init_todd_coxeter'
user-init.o(.data+0x4df8): undefined reference to `init_mactex'
user-init.o(.data+0x4e00): undefined reference to `init_plot'
collect2: ld returned 1 exit status
sh: line 1: ./raw_maxima: No such file or directory

I don't konow is this GCL or Maxima problem.
Probably latter.



Camm Maguire:
> Hi Vadim!
>
> "Vadim V. Zhytnikov" <address@hidden> writes:
>
>
> > 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.
>
>
> OK, if we can't figure out the unexec, will try to make these a
> configure option.  Would prefer the former of course!
>
>
> > (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.
>
>
> OK, I know you are under time pressure, so here are what I feel your
> fastest options are in order 
>
> 1) depend on a specific libc, or ship 2 binaries against the two most
>    popular versions.
>
> 2) Use your static build in gcl with the --enable-gcl-altlink maxima
>    build option.  this will bypass the fasloading code for the .o
>    files.
>
> 3) Build your gcl with --enable-debug, run under gdb the command
>    maxima is trying to run in its build process, break at this message
>    in fasload in sfaslbfd.c, find the symbol name in the q[u]
>    structure, then run gdb on raw_gcl in the unixport directory, break
>    at build_symbol_table_bfd, and find out how this symbol appears in
>    that (raw_gcl) image.  I think the symbol names are different in
>    recent dynamic libc vs. static libc.
>
> Take care,
>
>
>
> > 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>