[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: [fricas-devel] Re: next version
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: [fricas-devel] Re: next version |
Date: |
29 Jan 2008 22:05:17 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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