[Gcl-devel] Re: problem compiling wh-sandbox revision 571 on Windows

[Camm Maguire]

Greetings!  And thanks for finding this bug.  compiler::link did once
work on Windows -- apparently subsequent development coupled with our
current lack of a Windows maintainer has resulted in this temporary
breakage.


Here is the function in question:

object
find_init_name1(char *s,unsigned len) {
#ifdef _WIN32
  FEerror("Not supported on Windows",0);
#else    
  struct stat ss;
  char *tmp,*q;
  FILE *f;

  if (len) {
    tmp=alloca(len+1);
    memcpy(tmp,s,len);
    tmp[len]=0;
  } else
    tmp=s;
  if (stat(tmp,&ss))
    FEerror("File ~a does not exist",1,make_simple_string(tmp));
  if (!(f=fopen(tmp,"rb")))
    FEerror("Cannot open ~a for binary reading",1,make_simple_string(tmp));
  tmp=alloca(ss.st_size+1);
  if (fread(tmp,1,ss.st_size,f)!=ss.st_size)
    FEerror("Error reading binary file",0);
  fclose(f);
  for (s=tmp;s<tmp+ss.st_size && strncmp(s,"init_",5);q=strstr(s+1,"init_"),s=q 
? q : s+strlen(s)+1);
  if (strncmp(s,"init_",5))
    FEerror("Init name not found",0);
  return make_simple_string(s);
#endif  

}

Admittedly this is a rather stupid function.  Traditionally, GCL uses
"init_code" as the name of the initializing function for compiled
source, except when the :system-p flag is set (i.e. for linking with
ld), in which case the name is "init_filename" to prevent multiple
symbol errors from ld.  compiler::link needs to have the name to
properly write user_init.  Before find_init_name was written, we used
some even more fragile heuristic.

Surely something like the above can be made to work on Windows.  Or a
piped call to nm?  I'd be most appreciative for a suggested patch,
which should be rather simple.

Take care,


Waldek Hebisch <address@hidden> writes:

> CC-ing Camm, as the problem depends on very specific GCL behavoiur.
> 
> Bill Page wrote:
> > Waldek,
> > 
> > The following change in revsion 571:
> > 
> > http://axiom.svn.sourceforge.net/viewvc/axiom/branches/wh-sandbox/src/lisp/Makefile.pamphlet?view=diff&r1=570&r2=571
> > 
> > seems to cause problems building wh-sandbox on Windows:
> > 
> > ...
> > Finished compiling axiom-lisp.lisp.
> > #p"axiom-lisp.o"
> > 
> > >echo '(compiler::link (quote ("axiom-package.lisp" "axiom-lisp.o")) "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")))' \
> >                '
> > "C:/msys/1.0/home/Administrator/axiom-sandbox/src/lisp/../.././src/lib/bsdsignal.o
> > C:/msys/1.0/home/Administrator/axiom-sandbox/src/lisp/../.././src/lib/cfuns-c.o
> > C:/msys/1.0/home/Administrator/axiom-sandbox/src/lisp/../.././src/lib/sockio-c.o
> > -lwsock32")' \
> >             | /usr/local/bin/gcl
> > GCL (GNU Common Lisp)  2.6.8 CLtL1    Apr 16 2007 00:20:36
> > Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> > Binary License:  GPL due to GPL'ed components: (UNEXEC)
> > Modifications of this banner must retain notice of a compatible license
> > Dedicated to the memory of W. Schelter
> > 
> > Use (help) to get some basic information on how to use GCL.
> > Temporary directory for compiler files set to
> > C:/msys/1.0/home/Administrator/axiom-sandbox/build/i686-pc-mingw32/
> > 
> > >
> > Error: Unsupported on Windows platforms
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by SYSTEM:FIND-INIT-NAME.
> > Broken at SYSTEM:FIND-INIT-NAME.  Type :H for Help.
> > >>/bin/install -c lisp.exe
> > /home/Administrator/axiom-sandbox/build/i686-pc-mingw32/bin
> > /bin/install: cannot stat `lisp.exe': No such file or directory
> > make[2]: *** [do_it.gcl] Error 1
> > make[2]: Leaving directory `/home/Administrator/axiom-sandbox/src/lisp'
> > make[1]: *** [all-lisp] Error 2
> > make[1]: Leaving directory `/home/Administrator/axiom-sandbox/src'
> > make: *** [all-src] Error 2
> > 
> > ---------
> > 
> > Apparently GCL is complaining about "axiom-lisp.o". The following
> > patch allowed the build to proceed further:
> > 
> > --- src/lisp/Makefile.pamphlet  (revision 613)
> > +++ src/lisp/Makefile.pamphlet  (working copy)
> > @@ -81,7 +81,7 @@
> >         echo '(load "axiom-package.lisp")' \
> >              '(setq compiler::*default-system-p* t)' \
> >              '(compile-file "axiom-lisp.lisp")' | $(AXIOM_LISP)
> > -       echo '(compiler::link (quote ("axiom-package.lisp"
> > "axiom-lisp.$(OBJEXT)")) "lisp" ' \
> > +       echo '(compiler::link (quote ("axiom-package.lisp"
> > "axiom-lisp.lisp")) "lisp" ' \
> >                ' (format nil "(progn (let ((*load-path* (cons ~S 
> > *load-path*))'\
> >                                          ' (si::*load-types* ~S))' \
> >                                         ' (compiler::emit-fn t))' \
> > 
> > -----------
> > 
> 
> Using 'axiom-lisp.lisp' is certainly wrong: 'axiom-lisp.lisp' contains
> 'clines' constuct which to work must be compiled.  I think that the
> following procedure should work:
> 
> - first produce an auxilary image linking in the compiled C files, but no
>   Lisp files (essentially what revisions earlier than 571 did).
> - than start this image, load lisp files and use save-system to
>   dump proper image.
> 
> Question to Camm:  I want to make an executable image which contains
> a package and a few functions in this package.  Some functions call
> extra C code.  What is the proper way to make such an executable?
> In particular, how to do this in a way that works on all systems
> supported by GCL?
> 
> My impression was that COMPILER:LINK was the way.  Namely, compile.texi
> says:
> 
> On systems where dlopen is used for relocations, one cannot make custom
> images containing loaded binary object files simply by loading the files
> and executing save-system.  This function is provided for such cases.
> 
> IIUC save-system will not work if I want to load compiled Lisp code
> and the platform uses dlopen.  However, messages in source code seem
> to say that COMPILER:LINK does not really work on Windows -- namely
> that it can not link Lisp code.
> 
> 
> Bill, you may try the following. Camm, is this correct?
> 
> diff -u wh-sandbox.bb2/src/lisp/Makefile.pamphlet 
> wh-sandbox/src/lisp/Makefile.pamphlet
> --- wh-sandbox.bb2/src/lisp/Makefile.pamphlet 2007-06-18 21:47:51.000000000 
> +0200
> +++ wh-sandbox/src/lisp/Makefile.pamphlet     2007-06-18 22:03:50.000000000 
> +0200
> @@ -81,7 +81,7 @@
>       echo '(load "axiom-package.lisp")' \
>            '(setq compiler::*default-system-p* t)' \
>            '(compile-file "axiom-lisp.lisp")' | $(AXIOM_LISP)
> -     echo '(compiler::link (quote ("axiom-package.lisp" 
> "axiom-lisp.$(OBJEXT)")) "lisp" ' \
> +     echo '(compiler::link nil "prelisp" ' \
>                ' (format nil "(progn (let ((*load-path* (cons ~S 
> *load-path*))'\
>                                          ' (si::*load-types* ~S))' \
>                                         ' (compiler::emit-fn t))' \
> @@ -91,6 +91,9 @@
>                        ' si::*system-directory* (quote (list ".lsp")))' \
>                 '  "$(lisp_c_objects) @axiom_c_runtime_extra@")' \
>              | $(AXIOM_LISP)
> +     echo '(load "axiom-package.lisp") (load "axiom-lisp.$(OBJEXT)")' \
> +          '(in-package "AXIOM-LISP") (save-core "lisp$(EXEEXT)")' \
> +         | ./prelisp$(EXEEXT)
>       $(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
>       $(STAMP) $@
>  
> 
> 
> -- 
>                               Waldek Hebisch
> address@hidden 
> 
> 
> 

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