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

[Camm Maguire]

Greetings!

root <address@hidden> writes:

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

OK, will try this when I get a chance -- thanks!

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

Haven't really used dlopen too much, but to my understanding, one
file-id is used while the code in the .o file is mmapped and made
available to the running program.  Lisp, again to my knowledge, has no
'unload' command -- i.e. once code is loaded it is expected to be
available for the rest of the session -- and in any case axiom nor any
other program I've used attempts such an 'unload' to my knowledge.  So
basically yes, a lisp load implemented with dlopen will fail after
1024 loads, unless we can do something that I'm not seeing at the
moment.  One such (heavyweight) idea would be to keep a list of
dlopened files, and at some interval make a gcc system call to
concatenate these .o files into one .so, close the existing id's and
open one to the new object.  Not sure if it will work, but sounds
feasible. 

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

Possibly.  I haven't yet investigated, and in any case, the machine is
currently unavailable.

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

Great!  Should be actually quite more stable than 2.5.2.

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

Will look into fixing these.  Must confess, never used them myself,
but they seem to have potential.

gclcvs also has the gtk library hooks checked in, but nothing has been
done with them yet.

Take care,

> Tim
> 
> 
> _______________________________________________
> 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