RE: [Gcl-devel] RE: On statically linked Axiom

[Page, Bill]

Camm,

Thanks for the describing the debugging approach.
I do not (yet) feel familiar enough with these tools
to do what you suggest. As time permits, I may be able
to attempt this. I am not really sure how important this
is to the Axiom project as such, unless it should turn
out that static builds really can be run on a large
number of platforms without re-building... I consider
the current attempt as simply an experiment. Perhaps
Tim can comment further.

Anyway, last night I ran yet another clean re-build with
up to date Axiom sources and the --enable-static option
on GCL. As before, it ran all the way through until the
final make-databases step, but then after doing the
autoloads I got the following messages:

  ...
  Loading /home/bpage/axiom-new/mnt/linux/autoload/br-saturn.

Unrecoverable error: mark botch.
make [3]: *** [db] Error 134
make [3]: Leaving directory '/home/bpage/axiom-new/src/algebra'

...

Now a quick search of the Axiom and GCL source reveals that
the error message 'mark botch' comes from either

  o/gbc.c

or

  o/sgbc.c

in GCL. I presume that this is telling me something about
a garbage collection error?

I guess that this might explain why this error message is
different than the behaviour I saw yesterday but occurs at
roughly the same point in the Axiom build.

The only thing that I did different in this most recent
build was to remove the --enable-vssize --enable-maxpage
and --enable-statsysfd from the .configure. In fact the
configure statement is just

  ./configure --enable-static

So far as I can tell, the other options specified in the
current Axiom lsp/Makefile.pamphlet are either unnecessary
or defaults. I would expect a more explicit message from
GCL if we reached any of these limits or had a conflicting
choice of options. But I am rather unclear about this, so
of course let me know if I am wrong ...

So, were too from here? I feel even less certain about
debugging GCL garbage collection then I do about hunting
for undefined symbols. <grin>

Regards,
Bill Page.

> -----Original Message-----
> From: Camm Maguire [mailto:address@hidden
> Sent: Wednesday, October 29, 2003 7:43 AM
> To: Page, Bill
> Cc: address@hidden; 'address@hidden'; address@hidden
> Subject: Re: [Gcl-devel] RE: On statically linked Axiom
> 
> 
> Greetings!
> 
> Well, while I can't imagine anything in the loader which
> would infinite loop, this is the only place in the gcl code
> relevant to the experience you report below (sfaslbfd.c).
> 
> Neither 2.7.0 nor other gcc version is likely to help.  The
> debugging steps are to run a 'nm' on the object file failing to
> load, an nm on the image failing to do the loading, and to make
> sure no unknown symbol was written into the .o.  Then run in
> gdb, with the build having the --enable-debug flag set, and
> step through the loop in fasload where the
> bfd_relocate_section_contents call is made to see
> what's happening.
> 
> From what you report, I'd expect a simple fix to present itself
> readily, like the recent patch from -15 to -16.  As to my earlier
> comment regarding the gcc linker warnings in writing raw_gcl,
> I believe these refer to a few C library routines used by gcl
> which do the equivalent of a dlopen anyway -- I imagine they are
> rarely used, and we could in principle disable them if needed
> (for extra safety) when the --enable-static option is selected.
> So in principle there should be nothing which would absolutely
> stand in the way of a static build if/when desired. 
> 
> If this is important to axiom, please let me know, and I'll
> try to debug the build myself.
>