[Gcl-devel] Re: Latest Debian package (-11)

[root]

> 1) With 2.6.1-18 and later, the ia64 problem, in which shared
>    libraries at runtime had to exactly match those present at compile
>    time, has been eliminated.  Just tested the latest ia64 axiom build
>    against multiple versions of the same shared libs, and all is
>    stable.(!)

cool. I'll try this on the TestDrive machines as soon as I get the chance.

> 
> 2) I lost contact with my arm machine during the build, but it looks
>    as though at most there might be problems compiling one or two
>    algebra files.  The build will take days to complete on this arch,
>    but apparently this will give us axiom on a pda.  (Will anyone use
>    axiom there?)

I'll certainly use it there. It may take longer than you think to build.
I've had a build going for 3 days (so far) on a 166Mhz pentium. 

It would be best to start by copying an already built src and int
directories, (tar them from a working system and untar them to the new
system) creating a blank obj and mnt directories, and then typing
make. The int directory should contain only machine-generated,
machine-independent files and it caches a lot of work (like generating
the lisp code from the spad files and the spad code from the pamphlet
files as well as the doc files).

The obj directory is machine-generated, machine-specific files (e.g.
C compiles, lisp to .o files, etc) will be regenerated as will the 
mnt directory. 

If this doesn't work somewhere please send me the tail of the console
output and I'll fix it. As Axiom continues to grow it is important
to keep this functionality stable.

> 
> 3) Systems using dlopen (alpha, mips(el), hppa, and ia64) still cannot
>    build the databases, only (apparently) due to the limit on the
>    number of simultaneously opened (and dlopened) files (1024).  The
>    patch I've temporarily put in to copy prebuilt databases from i386
>    on these platforms allows the current build to complete on these
>    arches.  

I'm puzzled by this dlopen issue. Axiom doesn't keep files open during
database builds. It loads the files but I believe they are closed
after loading. Will dlopen fail after 1024 files have been used?  I
thought that file ids were reused.

> 
> 4) Building the package takes a long time on some systems, but ppc,
>    alpha, and ia64 have recently successfully completed my latest
>    upload.  Given earlier results, I don't expect any difficulties
>    from mips(el), hppa, sparc, and s390 (thanks Gerhard for clearing
>    the gcc compiler bug here!)  In principle, arm and m68k should be
>    fine too, but as these machines are rather slow and less exercised
>    in the areas we're using, may give us a few surprises.

You mentioned that two algebra files failed to compile. That's strange
as all of the files compile here. Is there some resource limit that
gets hit?

> 
> 5) In researching some of the latest GCL changes, I feel that it may
>    be quite straightforward to eliminate the need for dlopen on the 5
>    platforms mentioned above by making use of an alternate relocation
>    pathway through the bfd library.  Don't know how important it is,
>    but unless someone indicates they really need it, I'm going to
>    focus on clearing up more ansi issues first.

I'm expecting the build to complete on this slow pentium. Then I'm going
to upgrade the machine to yarrow (the latest fedora ISOs).

GCL 2.5.2 is no longer in the axiom zips directory as the 2.6.1 build
appears stable.

I tried using the tk::tkconnect function and it appears to work.
I then tried to use the latest tools widget demo and it fails
because the file contains commas outside of backquotes. Once these
are removed the file still contains dots. I've backed off this effort
for the moment and am applying all effort to getting the graphics alive.

Tim