Re: [Gcl-devel] Re: gcl-2.6.8

[Gabriel Dos Reis]

Hi Camm,

Camm Maguire <address@hidden> writes:

[...]

| > | Finally, your axiom configure does not propagate the CC setting, so
| > | bsdsignal etc are compiled as elf by the normal system gcc.
| >
| > That is odd.  I'll look into that and update you.  I believe it is just
| > a cross-compilation issue.  Apparently the current build assumes a
| > native build, whereas when you use wine you are doing a cross-compilation.
| > It should not be hard to fix that -- I know OpenAxiom's build system was
| > originally designed to support cross-compilation; so I think this should
| > be easy to fix.
| 
| OK.  gcl builds natively as a mingw binary under wine, and is not
| cross-compiled.  mingw binaries need to run as part of the build
| process.  I just set CC and PATH, enable wine binaries as valid
| binfmts on my Debian linux system, do ./configure --host=mingw32, and
| everything in gcl works as if I was on windows, sans the
| no-wait-on-system() issue. 

OK.

| With the same system settings, but without
| the --host command to axiom's configure, open-axiom picked up the
| native gcc to compile the system extras linked in via compiler::link.
| (I think).

Ah, this explanation clarifies your previous report.  Yes, in this
scenario --host is necessary so that OpenAxiom's configure can select
'the right' compiler. 

[...]

| > Warning: SYSTEM is being redefined.d=`echo "(format nil \"~a\" 
si::*system-directory*)" | gcl | grep "/gcl.*/" | sed -e "s,\",,g"`; cp 
$d/rsym.exe .
| > echo '(let* ((sys-cc compiler::*cc*) ' \
| >          '      (sys-ld compiler::*ld*) ' \
| >          '      (compiler::*cc* (concatenate (quote string) ' \
| >          '                                   ""    ' \
| >          '                                   sys-cc))       ' \
| >          '      (compiler::*ld* (concatenate (quote string) ' \
| >          '                                   ""    ' \
| >          '                                   sys-ld)))       ' \
| >              '(compiler::link (quote ("core.lisp")) "lisp.exe" ' \
| >              ' (format nil "(progn (let ((*load-path* (cons ~S 
*load-path*))'\
| >                                         ' (si::*load-types* ~S)))' \
| >                                   ' (when (fboundp (quote si::sgc-on))' \
| >                                         ' (si::sgc-on nil))' \
| >                               ' (setq si::*top-level-hook* 
(read-from-string \"|AxiomCore|::|topLevel|\")))"' \
| >                       ' si::*system-directory* (quote (list ".lsp")))' \
| >                '  "./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o 
./../../src/lib/sockio-c.o -lwsock32 -lm"))' \
| >             | ./base-lisp.exe
| > GCL (GNU Common Lisp)  2.6.8 CLtL1    Aug  6 2010 11:40:11
| > 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 ../../build/i686-pc-mingw32/
| >
| > AxiomCore>
| >   1> (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe 
-fno-zero-initialized-in-bss -mms-bitfields -march=i386  
-IC:/msys/1.0/local/lib/gcl-2.6.8/unixport/../h  -O3  -c -w \"./user-init.c\" 
-o \"./user-init.o\"")
| >   <1 (SYSTEM 0 0)
| >   1> (SYSTEM "gcc  -o  raw_lisp.exe ./user-init.o  
-LC:/msys/1.0/local/lib/gcl-2.6.8/unixport/ -Wl,-Map raw_lisp_map.exe  
C:/msys/1.0/local/lib/gcl-2.6.8/unixport/../o/firstfile.o  -lgcl -lm -lmingwex  
-lwsock32  -lgclp C:/msys/1.0/local/lib/gcl-2.6.8/unixport/../o/lastfile.o 
./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o 
./../../src/lib/sockio-c.o -lwsock32 -lm")
| 
| I think the issue is here.  firstfile.o has to be first, and
| lastfile.o last on the link line.

Aha, I'll try to put the extra libs earlier in the list.  I did this based on
the existing documentation of compiler::link:

 -- Function: LINK (files image &optional post extra-libs
          (run-user-init t) &aux raw init)
     Package:LISP

     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.

     After compiling source files into objects, LINK can be called with
     a list of binary and source FILES which would otherwise normally be
     loaded in sequence before saving the image to IMAGE.  LINK will use
     the system C linker to link the binary files thus supplied with
     GCL's objects, using EXTRA-LIBS as well if provided, and producing
     a raw_IMAGE executable. This executable is then run to initialize
     first GCL's objects, followed by the supplied files, in order, if
     RUN-USER-INIT is set.  In such a case, source files are loaded at
     their position in the sequence.  Any optional code which should be
     run after file initialization can be supplied in the POST
     variable.  The image is then saved using save-system to IMAGE.

     This method of creating lisp images may also have the advantage
     that all new object files are kept out of the lisp core and placed
     instead in the final image's .text section.  This should in
     principle reduce the core size, speed up garbage collection, and
     forego any performance penalty induced by data cache flushing on
     some machines.

     In both the RAW and SAVED image, any calls to LOAD binary object
     files which have been specified in this list will bypass the
     normal load procedure, and simply initialize the already linked in
     module.  One can rely on this feature by disabling RUN-USER-INIT,
     and instead passing the normal build commands in POST.  In the
     course of executing this code, binary modules previously linked
     into the .text section of the executable will be initialized at
     the same point at which they would have normally been loaded into
     the lisp core, in the executable's .data section.  In this way,
     the user can choose to take advantage of the aforementioned
     possible benefits of this linking method in a relatively
     transparent way.

     All binary objects specified in FILES must have been compiled with
     :SYSTEM-P set to T.

which led me to think that the files appearing on the first argument to
LINK must have been compiled by GCL (as opposed to being 'ordinary' C
program fragment.)  Is that still the case?  If yes, then I am a bit
confused about how to specify the 'ordinary' C object files to LINK, and
yet get firstfile.o first and lastfile.o last.

|  You can try this by hand and see if
| it works if you like.  compiler::link will need to rewrite the link
| command if so.  Again, a simple fix, if it works for you.
| 
| Has this ever been tested on mingw before?

Yes, this has been the way we built OpenAxiom (and FriCAS I think, for
it all derives from the axiom.build-improvements branch) since at least
2006.   In the makefile, I wrote this comment at the time:

   ## Again, ideally, we would like GCL to link with the compiled Lisp
   ## code from core.lisp.  However, the general interface compiler::link
   ## that GCL provides for that task is unsupported on Windows platforms.
   ## So, we instruct GCL so load the source file instead.


I'll try to rearrange the order in which the object files are specified
and see if it makes a difference.

Thanks!

-- Gaby