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: 28 Jul 2003 21:26:23 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Gcl-devel mailing list
> >>address@hidden
> >>http://mail.gnu.org/mailman/listinfo/gcl-devel
> >>
> >>
> >>
> >
> 
> 
> -- 
>       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]