[Gcl-devel] Re: Axiom/GCL on Windows

[Camm Maguire]

Greetings!

Gabriel Dos Reis <address@hidden> writes:

> Hi Camm,
> 
>  I'm making slow progress in building build-improvements on windows
> using mingw/sys).  From the outset I should say that I'm not a Windows
> programmer.
> 
> The blocking problem for me at this moment has to do with Windows DLL
> and GCL.  As youy know, we use currently this Make rule:
> 
> $(OUT)/lisp$(EXEEXT): $(GCL)
>       echo '(compiler::link nil "${OUT}/lisp" ' \
>               ' (format nil "(progn (let ((*load-path* (cons ~S 
> *load-path*))'\
>                                         ' (si::*load-types* ~S))' \
>                                        ' (compiler::emit-fn t))' \
>                                   ' (when (fboundp (quote si::sgc-on))' \
>                                         ' (si::sgc-on t))' \
>                                   ' (setq compiler::*default-system-p* t))"' \
>                       ' si::*system-directory* (quote (list ".lsp")))' \
>                ' "$(build_libdir)/cfuns-c.o' \
>                '  $(build_libdir)/sockio-c.o' \
>                '  $(build_libdir)/libspad.a")' \
>             | $(GCL)
> 
> to save an image appropriate to bootstrap the system.
> 
> This works fine on many Unix-variant systems.  I'm sure it can be
> improved.
> 
> The object sockio-c.o contains codes that link AXIOMsys with the OS
> sockets.  On windows, sockets are available only through a DLL
> (WinSock) and many of the POSIX interface are defined in terms of that
> DLL.  So, in the end when we come to save the image, the linker is
> unhappy because it cannot satisfy the symbols that are provided by the
> Windows.  
> 

I'm inferring that you have symbol conflicts between the dll and
sockio-c.o?  There is a linker flag which we use in cvs head to handle
the static linking case, where such a conflict exists between gcl's
malloc and that in libc.a.  On the gcc command line, it is
-Wl,-zmuldefs.  I believe this resolves the symbols in first come
first serve manner in the order in which the files appear on the
linker command line, but you might want to double check this.  You can
add this flag to the gcc command line used within gcl by

(setq compiler::*cc* (concatenate 'string compiler::*cc* " -Wl,-zmuldefs"))

But beyond this, you will have to ifdef the code in sockio-c.c to work
with windows, which is not strictly posix compatable, to my
understanding.  

I would recommend instead using gcl sockets, which are already ported,
at least as of my last checking.  Then you don't even need the extra
sockio-c.c.  Examples of the interface can be found in an earlier
thread on a mini native webserver within axiom as a gui option using
an external browser.  I can provide explicit examples should this be
needed.   The info pages should also be helpful here.  If this sounds
like something worth pursuing, and everyone is happy with the idea,
please let me know and I will provide more details.

Take care,

> Do you have a suggestion about how to convince compiler::link to
> tell the linker that some symbols are to be found in the winsock dll?
> 
> Thanks,
> 
> -- Gaby
> 
> 
> 
> 

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