[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: gcl-2.6.8
From: |
Gabriel Dos Reis |
Subject: |
Re: [Gcl-devel] Re: gcl-2.6.8 |
Date: |
Mon, 09 Aug 2010 00:04:01 -0500 |
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
- [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/03
- Re: [Gcl-devel] Re: gcl-2.6.8, Donald Winiecki, 2010/08/03
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/04
- Re: [Gcl-devel] Re: gcl-2.6.8, Donald Winiecki, 2010/08/04
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/06
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/08
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/08
- Re: [Gcl-devel] Re: gcl-2.6.8,
Gabriel Dos Reis <=
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/13
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/17
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/13
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Donald Winiecki, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/13
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/05
- Re: [Gcl-devel] Re: gcl-2.6.8, Gabriel Dos Reis, 2010/08/08
- Re: [Gcl-devel] Re: gcl-2.6.8, Camm Maguire, 2010/08/08