[Top][All Lists]

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

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

From: Vanuxem Gregory
Subject: RE: [Gcl-devel] Re: Dynamic Library Linking (arbitray float)
Date: Fri, 6 May 2005 04:45:38 +0200

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
3) 'Fraction Integer' with gmp (GMP)                                            
'GMP (realized)'
      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.



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


"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
> pair as shown here:
> 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
> 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
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]