Greetings! Gabriel Dos Reis <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel