gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Maxima GCL buld trouble


From: Camm Maguire
Subject: Re: [Gcl-devel] Maxima GCL buld trouble
Date: 30 Jul 2003 11:48:25 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Hi Vadim!

"Vadim V. Zhytnikov" <address@hidden> writes:

> 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).

OK, we can fix this if needed, but as far as I can tell from what you
write below, there is no need for static libc.  It is certainly not
desirable if not needed.

> 
> 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.
> 

If you have a reproducible test environment in which we might chase
this down, then it would be useful to compile the gcl with
--enable-debug, and run maxima under gdb, and find the location of the
fault.  Please let me know if you would like to do this, and need
assistance with gdb.

Back when Dr. Schelter was alive, and I was putting together the first
Debian maxima package, we had segfaults whenever the binary was run on
a different machine.  I managed to correlate it exactly with
differences in the addresses at which the dynamic libs were mapped,
as reported in the /proc filesystem for the process.  I believe at
that time, the problem was that in the saved image, the stdin and
stdout file structures were not correctly initialized when the
libraries mapped to different addresses.  Dr. Schelter fixed it with
this addidion to linux.h:

#define INIT_CORE_END terminal_io->sm.sm_object0->sm.sm_fp = 
stdin;terminal_io->sm.sm_object1->sm.sm_fp = stdout;


In any case, my understanding of this is that our unexec process is
saving some memory location of some item in the external libs in the
image, and expects to find it again at this place on startup.  If we
can determine what the structure is, we can apply a similar fix to the
above. 



> 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.
> 

So are you telling me that static readline is the only problem?  This
would then vary with what I was seeing, which occurred with dynamic
libc and readline linkage, and showed up in gcl proper.  

Are you good to go now with your cd?


> 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
> 

Is this the released 5.9.0, or a maxima cvs image?  In any case, the
problem is that one or more maxima modules have not been compiled with
the ':system-p t'  flag.  Here is what I have in the (Debian package,
5.9.0 release) lisp-utils/defsystem.lisp:

(defun compile-file-operation (component force)
....
                          :output-file
                          output-file
                          #+gcl :system-p #+gcl t
                          #+CMU :error-file
                          #+CMU (and *cmu-errors-to-file*
                                     (component-full-pathname component
....

You can also set compiler::*default-system-p* to t at the beginning if
you want.

Please let me know if problems remain, as we need this mode to ship
maxima on 5 platforms.

Take care,

> 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>
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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