Greetings!
Gabriel Dos Reis <g...@cs.tamu.edu> writes:
> Hi Camm,
>
> Camm Maguire <c...@maguirefamily.org> 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.
This of course should not be your responsibility ultimately -- just to
test the hunch.
In any case, I've committed same or equivalent, and I get a working
link image now. Hope you do too.
Take care,
>
> Thanks!
>
> -- Gaby
>
>
>
>
--
Camm Maguire c...@maguirefamily.org
==========================================================================
"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
