RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)

[Vanuxem Gregory]

Serious question about GCL,

I've lost your mail about (arbitrary float),
But how do yo think peopole can implement arbitrary float in gcl; whith MPFR
?
With class or directly in num_arith... ?

Camm... one Idea....?

Actually AXIOM doesn't compile with ANSI version ...
I know that you work on tcl/tk, documentation and graphics , doesn't forget
the concept of 'notebook'
(literate programming and other things...).


Generally I work on UNIX* (linux and BSD*) but actually ((numerical stuff to
implemenent: transcendental function for matrix (see Higham
(http://www.ma.man.ac.uk/~higham/ and gang) with linear algebra (atlas, blas
and lapack ...))
I' am on Windows(R) (thanks M.Thomas ...).
I think in AXIOM five things has to be seriously be enhanced (for future
library use...):

1) 'Integer' in arbitrary integer:                                              
        'GMP (realized)'
2) 'Floating number' in arbitrary float (cf: Monagan, Michael (1990)):  'ADD
MPFR'
3) 'Fraction Integer' with gmp (GMP)                                            
'GMP (realized)'
        (cf:
(http://page.axiom-developer.org/zope/mathaction/EnhancedFractionDomain),
      I will update and explain this when time permits.
4) C (or fortran) Dynamic library linkink in GCL. '...' Idea Maguire ?
5) Documentation about what I say.

Cheers,

Greg

-----Message d'origine-----
De : address@hidden
[mailto:address@hidden la part de
Camm Maguire
Envoye : jeudi 5 mai 2005 21:02
A : Mike Thomas
Cc : address@hidden
Objet : [Gcl-devel] Re: Dynamic Library Linking


Greetings!

"Mike Thomas" <address@hidden> writes:

> Hi Camm.
>
> | This is indeed the short answer -- you can link in any new symbols you
> | want that are not present in the original image via compiler::link.
> | See the documentation for this function in gcl-si.{texi,info}.  What
> | this essentially does is build a new gcl image using a fresh call to
> | the system linker ld to modify the image symbol table with whatever
> | new code or libraries you specify.  It has the disadvantage that the
> | image is 'fresh' -- i.e. any work you may have done in the running
> | image before compiling compiler::link is lost.  Such work can be
> | respecified to run by hand in the fresh new image through one of
> | compiler::link's arguments, but this is a bit awkward to use.
> |7
> | What I'd like to do in 2.7.0 is to allow the user to link in new
> | dynamic libraries at runtime, modify the running image's symbol table,
> | and allow this work to be preserved across image saves via
> | si::save-system.  What this essentially means is that unexec needs to
> | add a little section to the end of the dumped image containing
> | relocation records for the new symbols for use by the system's dynamic
> | linker (ld.so on Linux), i.e. a GOT (Global Access Table).
>
> If I understand you correctly, on Windows one could store the name of the
> symbol and the name of the DLL from whence it came, then while resolving
> references at ru(i)ntime to call LoadLibrary() and GetProcAddress() for
each
> pair as shown here:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/
> base/using_run_time_dynamic_linking.asp
>
> I believe that PE-COFF executables actually have a section for external
> library references (ie references to DLL's) into which unexec might put
this
> kind of information so that the OS could automatically do the external
> relocation work at image load time (though probably only for those
> relocation records in the text sections I guess) .  This is all pretty
hairy
> though, especially as Windows moves towards 64 bits and whatever system
> changes might come with that.
>

This is exactly the idea.  When we have time :-).

Take care,


> | A kludgy way of doing this without any special executable format
> | knowledge might be to expand the explicit C plt table (mplt in plt.c)
> | with a bunch of dummy entries referring to unused symbols in external
> | shared libs, one of which we might provide for this purpose.  Then
> | when new symbols are needed, these symbols could be changed.  This
> | would still require us to be able to find the symbol in the image's
> | symbol table, but at least we would not have to add any new sections,
> | etc.  Of course this approach is rather awkward and limited too.
>
> It all sounds awkward to me as I'm pretty vague on all of this.
>
> Cheers
>
> Mike Thomas.
>
>
>
>
>

--
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah


_______________________________________________
Gcl-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gcl-devel