axiom-developer
[Top][All Lists]
Advanced

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

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


From: Camm Maguire
Subject: [Axiom-developer] Re: [Gcl-devel] RE: On statically linked Axiom
Date: 29 Oct 2003 07:43:25 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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.

Take care,

"Page, Bill" <address@hidden> writes:

> Camm, et al.
> 
> Well I guess I was too optimistic about building
> Axiom with GCL --enable-static. After a day of
> running the cpu around the whole build cycle
> several times and in several different ways, I am
> still not (quite) able to complete a build of Axiom
> using the .configure --enable-static option. I am
> working with gcc 3.3.2 on Linux 8.0 and GCL-2.6.1-16.
> 
> In fact, the Axiom build proceeds to very near
> completion. Having added three missing files to
> the build since my last successful attempt, the
> Axiom build now stalls during the make-databases
> stage - the very last stage before finishing normally.
> This seems quite odd to me since at the time the
> build goes into an infinite loop, it is just loading
> NRLIB/code - not compiling. I tried doubling the
> vssize and maxpage parameters but that seemed to
> have no effect.
> 
> It turns out that I *can* manually canel and override
> this last step and simply copy the old databases files
> into the new run-time and all seems to work well and the
> resulting Axiom system even runs all of it's regression
> tests in the same way as the non-static build (though
> it is still not be able to re-build it's own databases).
> 
> I am now certain that the problem is related to the
> --enable-static option since I am able to repeatably
> remove this option and have the build complete entirely
> normally. Whether I then update the databases to the
> newly built ones or not, as soon as I return to
> --enable-static, a re-build of Axiom will again fail
> at the same point (loading BBTREE.NRLIB/code).
> 
> So I am about to give on this for now. But I do have
> one or two final quesitions:
> 
> 1) Do you think that it would it be worthwhile to
> attempt this using the unstable development branch
> version GCL 2.7.1? Are there changes in 2.7.1 that
> might have subtle effects on a static GCL?
> 
> 2) What about the choice of versions of gcc? Was
> my approach to upgrade to the most recent gcc 3.3.2
> a good decision or is there an earlier gcc version
> that might be happier building static binaries? Are
> there libraries besides the ones in gcc that should
> also be upgraded?
> 
> 3) And this more to the Axiom developers: Do you
> think there would be any point in my uploading the
> binary part of the static build even though the database
> build did not complete normally? The possible advantage
> (maybe) would be that we might have a chance to see
> if this approach of a static build will provide a
> single binary that could be run on a larger number of
> linux platforms.
> 
> Cheers,
> Bill Page.
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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