[Top][All Lists]
[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