[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] RE: [Gcl-devel] RE: On statically linked Axiom
From: |
Page, Bill |
Subject: |
[Axiom-developer] RE: [Gcl-devel] RE: On statically linked Axiom |
Date: |
Wed, 29 Oct 2003 13:16:18 -0500 |
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.
>
- [Axiom-developer] RE: [Gcl-devel] RE: On statically linked Axiom,
Page, Bill <=