[Gcl-devel] Re: [fricas-devel] Re: next version

[Camm Maguire]

Greetings!

Waldek Hebisch <address@hidden> writes:

> Camm Maguire wrote:
> > Waldek Hebisch <address@hidden> writes:
> > > It is should be relatively easy to switch to 'compiler::link'.
> > > However, IIRC the problem was that 'compiler::link' does not
> > > really work on Windows.  Namely, on Windows 'compiler::link'
> > > is unable to link Lisp files -- it can only handle binaries.
> > 
> > Odd, we should chase this down.  What happens when this is attempted? 
> >
> 
> This was reoprted in June:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2007-06/msg00393.html
>  
> In particlular:
> 
> > Here is the function in question:
> >
> > object
> > find_init_name1(char *s,unsigned len) {
> > #ifdef _WIN32
> >  FEerror("Not supported on Windows",0);
> > #else
> 
> I have looked at this function and my impression is that
> is should work fine on MinGW.  OTOH I do not understand

Have you tried commenting out the ifdef perchance?

> why this function is used on platforms supporting native
> relocations: IIUC in order to load a file native reloc
> code has to find the name of init function.  So, the same
> code which is used for loading could be used for linking.
> 

Well, the point of compiler::link is to support cases when one does
not have native object relocation.  Otherwise, just load and save.  So
compiler::link cannot rely on bfd machinery or equivalent, as this is
not available when the function is needed.

> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

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