[cmucl-help] CMUCL 18c building on tru64 5.1
Fausto Saporito
fausto.saporito at gmail.com
Tue Sep 2 23:53:58 UTC 2014
Hello Raymond,
thanks for these hints about cross.lisp
I put in the proper section the unwanted feature.
So, if I force the redefinition of those symbols at the end of
alpha-cross compiling phase, alpha-target starts but I noticed this
error among the others:
; File: /home/fausap/CMUCL/git-ver/cmucl/src/code/lispinit.lisp
; In: DEFUN SLEEP
; (ERROR 'SIMPLE-TYPE-ERROR
; :FORMAT-CONTROL "Invalid argument to SLEEP: ~S.~%~
; Must be a non-negative, non-complex number."
; :FORMAT-ARGUMENTS ...)
; Note: Deleting unreachable code.
;
DOUBLE-DOUBLE-FLOAT fell through ECASE expression.
Wanted one of (REAL FLOAT OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL INTEGER).
it's very strange... I disabled double-double... why I have this error ?
This is my features list in cross.lisp (I removed extern-alien-name,
fixup, etc... I don't know what they are doing... so maybe I can put
back later)
;;; Cross-compile script to build a alpha core using x86 as the
;;; compiling system. This needs work!
(in-package :cl-user)
;;; Rename the X86 package and backend so that new-backend does the
;;; right thing.
(rename-package "X86" "OLD-X86" '("OLD-VM"))
(setf (c:backend-name c:*native-backend*) "OLD-X86")
(c::new-backend "ALPHA"
;; Features to add here
'(:alpha
:relative-package-names ; Relative package names from Allegro
:conservative-float-type
:hash-new
:random-mt19937 ; MT-19937 generator
:cmu ; Announce this is CMUCL
:cmu20 :cmu20b ; Current version identifier
:osf1
:bsd
:unix
)
;; Features to remove from current *features* here
'(:sparc-v8 :sparc-v7 :sparc-v9 :sparc
;; Other architectures we aren't using. Particularly important
;; to get rid of sse2 and x87 so we don't accidentally try to
;; compile the x87/sse2 float support on sparc, which won't work.
:x86 :x86-bootstrap :sse2 :x87 :i486
:mips :complex-fp-vops
;; Really old stuff that should have been removed long ago.
:propagate-fun-type :propagate-float-type :constrain-float-type
:double-double
:linkage-table
:stack-checking ; Throw error if we run out of stack
:heap-overflow-check ; Throw error if we run out of
; heap (This requires gencgc!)
:gencgc ; Generational GC
:modular-arith ; Modular arithmetic
:executable
;; Other OSes were not using
:openbsd :freebsd :glibc2 :linux :mach-o :darwin :sunos :svr4
:solaris :sun4
:pentium
:long-float
:new-random
:small
:mp))
And about the "CLASS" error:
I have in the log:
; File: /home/fausap/CMUCL/git-ver/cmucl/src/code/error.lisp
Execution of a form compiled with errors:
(SETF (INFO :SOURCE-LOCATION :CLASS NAME) SOURCE-LOCATION)
; Error in function C::TYPE-INFO-OR-LOSE: "CLASS" is not a defined info type.
then
Start time: Wednesday, 9/3/14 01:45:29 am [-2], compiling target:code/type.
Error in function C::%%DEFCONSTANT: Constant FLOAT-FORMATS being redefined.
Aborting...
2014-09-03 0:51 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
> In case you haven't already, you probably don't want these features set for
> alpha:
>
> :complex-fp-vops
> :linkage-table
> :stack-checking
> :heap-overflow-check
> :gencgc
> :modular-arith
> :executable
>
> Check that extern-alien-name, fixup-code-object, and sanctify-for-execution
> are correct for alpha. Not sure if these are needed or not. Not all of them
> are defined for sparc in the cross-x86-sparc.lisp file.
>
>
>
> On Sun, Aug 31, 2014 at 11:14 PM, Fausto Saporito
> <fausto.saporito at gmail.com> wrote:
>>
>> Hello Ray,
>>
>> yes, I'm using 20d to cross-build 20d.
>> I read at the top of the sparc cross.lisp file, it should be broken :-)
>>
>> Attached there're all the log files and the script.
>>
>> I read some errors about external symbols that are not external in
>> ALPHA package, maybe this is related to some definitions in
>> cross.lisp, but I'm not sure about it.
>>
>> thanks for you help
>> Fausto
>>
>>
>> 2014-09-01 5:11 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>> >
>> >
>> >
>> > On Sun, Aug 31, 2014 at 1:13 PM, Fausto Saporito
>> > <fausto.saporito at gmail.com>
>> > wrote:
>> >>
>> >> Hello all,
>> >>
>> >> I'm trying to do cross-platform cross-compilation for Alpha _OSF1.
>> >> I'm starting with NetBSD amd64 with cmucl 20d.
>> >>
>> >> so I did:
>> >>
>> >> 1) bin/create-target.sh alpha-cross alpha_osf1 alpha_osf1
>> >> 2) bin/create-target.sh alpha-target alpha_osf1 alpha_osf1
>> >> 3) created cross.lisp file using x86->sparc cross-compiling as example.
>> >> 4) bin/cross-build-world.sh alpha-target alpha-cross cross.lisp
>> >
>> >
>> > This all looks right. But if you are trying to build 20d for alpha, you
>> > have to be sure to check out the 20d sources.
>> >
>> >>
>> >>
>> >> but I have errors either in alpha-cross either in alpha-target.
>> >> I noticed even if I specified to exclude sse2 (for example) it tries
>> >> to compile it (???).
>> >>
>> >> I'm quite sure my cross.lisp is wrong, but really I don't know how to
>> >> modify it.
>> >
>> >
>> > It's possible the x86->sparc script is wrong. I haven't done such a
>> > cross-compile in quite a while.
>> >
>> > Can you post the cross script you're using? And also the error messages
>> > that
>> > you see?
>> >
>> > Ray
>> >
>> >>
>> >>
>> >> regards,
>> >> Fausto
>> >>
>> >> 2014-08-31 19:34 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
>> >> > Hello Raymond,
>> >> >
>> >> > so, if I understood well, you mean using 20d (under Linux, for
>> >> > example) and cross compile 18b for alpha ?
>> >> >
>> >> > regards,
>> >> > Fausto
>> >> >
>> >> >
>> >> > 2014-08-31 19:00 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sat, Aug 30, 2014 at 2:57 PM, Fausto Saporito
>> >> >> <fausto.saporito at gmail.com>
>> >> >> wrote:
>> >> >>>
>> >> >>> Hello,
>> >> >>>
>> >> >>> ok. I built 18a with 18a.
>> >> >>> Now, if I understood well the process to compile 18b is quite
>> >> >>> different... correct ?
>> >> >>> So, how can i crosscompile ?
>> >> >>
>> >> >>
>> >> >> I did a little digging and it seems there's not a lot of information
>> >> >> about
>> >> >> how to go from 18a to 18b. I can't even find any release notes on
>> >> >> this.
>> >> >>
>> >> >> As for cross-compilation, the current notes are at
>> >> >> http://trac.common-lisp.net/cmucl/wiki/BuildingCmucl. These are for
>> >> >> more
>> >> >> recent versions, so I don't know how they would apply to 18b. The
>> >> >> general
>> >> >> approach hasn't really changed, but the scripts themselves didn't
>> >> >> exist
>> >> >> in
>> >> >> 18b. On the other hand, the scripts just encapsulate what people
>> >> >> were
>> >> >> doing
>> >> >> by hand in an ad hoc way anyway.
>> >> >>
>> >> >> If you can, it might be easier to try to cross-compile from the 20d
>> >> >> release.
>> >> >> That is the last version that supported 8-bit (non-unicode) chars.
>> >> >> 20e
>> >> >> and
>> >> >> later require unicode which you'd probably have to update the
>> >> >> backend
>> >> >> to
>> >> >> support 16-bit chars.
>> >> >>
>> >> >> Good luck. Let us know how it goes.
>> >> >>
>> >> >>>
>> >> >>>
>> >> >>> thanks,
>> >> >>> Fausto
>> >> >>>
>> >> >>>
>> >> >>> 2014-08-30 23:07 GMT+02:00 Fausto Saporito
>> >> >>> <fausto.saporito at gmail.com>:
>> >> >>> > Hello Carl,
>> >> >>> >
>> >> >>> > I didn't check about 18a with 18a.
>> >> >>> > So I'll start with this and I hope it will be ok.
>> >> >>> >
>> >> >>> > thanks,
>> >> >>> > Fausto
>> >> >>> >
>> >> >>> >
>> >> >>> > 2014-08-30 23:02 GMT+02:00 Carl Shapiro <carl.shapiro at gmail.com>:
>> >> >>> >> Glad to hear that you have gotten past the assembler issues.
>> >> >>> >> Have
>> >> >>> >> you
>> >> >>> >> verified that you can compile an 18a with 18a in your
>> >> >>> >> environment?
>> >> >>> >> From
>> >> >>> >> there, to compile an 18c from 18a is straight forward but it
>> >> >>> >> will
>> >> >>> >> take
>> >> >>> >> a
>> >> >>> >> couple of extra steps. Most likely, you might have to go from
>> >> >>> >> 18a
>> >> >>> >> ->
>> >> >>> >> 18b ->
>> >> >>> >> 18c by way of two cross compilations. If you can describe a
>> >> >>> >> little
>> >> >>> >> bit
>> >> >>> >> more
>> >> >>> >> about the process you are taking, I might be able to help you
>> >> >>> >> with
>> >> >>> >> this.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> On Sat, Aug 30, 2014 at 1:40 PM, Fausto Saporito
>> >> >>> >> <fausto.saporito at gmail.com>
>> >> >>> >> wrote:
>> >> >>> >>>
>> >> >>> >>> Sorry... I press too early the SEND button :)
>> >> >>> >>>
>> >> >>> >>> Now the problem is during the compile lisp phase.
>> >> >>> >>> I have some errors in
>> >> >>> >>>
>> >> >>> >>> 1) code/struct
>> >> >>> >>>
>> >> >>> >>> Error in function FIND-CLASS: Class not yet defined:
>> >> >>> >>> LISP-STREAM
>> >> >>> >>>
>> >> >>> >>> 2) code/error
>> >> >>> >>>
>> >> >>> >>> Error: (during macroexpansion)
>> >> >>> >>> Error in %COERCE-TO-FUNCTION: the function
>> >> >>> >>> ORDER-LAYOUT-INHERITS
>> >> >>> >>> is
>> >> >>> >>> undefined.
>> >> >>> >>>
>> >> >>> >>> 2) code/class
>> >> >>> >>>
>> >> >>> >>> Error in function EXPORT: Exporting these symbols from the
>> >> >>> >>> KERNEL
>> >> >>> >>> package:
>> >> >>> >>> (STD-COMPUTE-CLASS-PRECEDENCE-LIST)
>> >> >>> >>> results in name conflicts with these packages:
>> >> >>> >>> CONDITIONS
>> >> >>> >>>
>> >> >>> >>> 3) code/hash
>> >> >>> >>>
>> >> >>> >>> Error in function KERNEL::VALUES-SIMPLE-SUBTYPEP-TYPE-METHOD:
>> >> >>> >>> Subtypep is illegal on this type:
>> >> >>> >>> (VALUES BASE-STRING &REST T)
>> >> >>> >>>
>> >> >>> >>> and others...
>> >> >>> >>>
>> >> >>> >>> So maybe 18a is too old to compile 18c , or maybe I'm doing
>> >> >>> >>> something
>> >> >>> >>> wrong.
>> >> >>> >>>
>> >> >>> >>> PS
>> >> >>> >>> i'm using cmucl 18a (downloaded from the web site...
>> >> >>> >>> unfortunately
>> >> >>> >>> 18b
>> >> >>> >>> tar file is corrupted).
>> >> >>> >>>
>> >> >>> >>> 2014-08-30 22:31 GMT+02:00 Fausto Saporito
>> >> >>> >>> <fausto.saporito at gmail.com>:
>> >> >>> >>> > Hello Carl,
>> >> >>> >>> >
>> >> >>> >>> > I found a possible fix.
>> >> >>> >>> > The problem is in the ".end" statement.
>> >> >>> >>> >
>> >> >>> >>> > this is the code
>> >> >>> >>> >
>> >> >>> >>> > .text
>> >> >>> >>> > .globl undefined_tramp
>> >> >>> >>> > .ent undefined_tramp_offset
>> >> >>> >>> > undefined_tramp = /* ###
>> >> >>> >>> > undefined_tramp_offset-call_into_lisp_LRA*/
>> >> >>> >>> > 0x140+call_
>> >> >>> >>> > into_lisp_LRA_page
>> >> >>> >>> > undefined_tramp_offset:
>> >> >>> >>> > call_pal PAL_gentrap
>> >> >>> >>> > .long 10
>> >> >>> >>> > .byte 4
>> >> >>> >>> > .byte 23
>> >> >>> >>> > .byte 254
>> >> >>> >>> > .byte (0xe0 + sc_DescriptorReg)
>> >> >>> >>> > .byte 2
>> >> >>> >>> > .align 2
>> >> >>> >>> > .end undefined_tramp
>> >> >>> >>> >
>> >> >>> >>> > now changing into ".end undefined_tramp_offset" it's ok.
>> >> >>> >>> > I hope this is the correct fix.
>> >> >>> >>> >
>> >> >>> >>> >
>> >> >>> >>> > 2014-08-30 20:18 GMT+02:00 Carl Shapiro
>> >> >>> >>> > <carl.shapiro at gmail.com>:
>> >> >>> >>> >> It has been a while, but I suspect this can be made to work.
>> >> >>> >>> >>
>> >> >>> >>> >> Have you been able to isolate the specific lines of code
>> >> >>> >>> >> that
>> >> >>> >>> >> are
>> >> >>> >>> >> causing
>> >> >>> >>> >> the error? It looks like something is going wrong on the
>> >> >>> >>> >> last
>> >> >>> >>> >> lines of
>> >> >>> >>> >> the
>> >> >>> >>> >> undefined_tramp and closure_trap routines but one cannot be
>> >> >>> >>> >> certain
>> >> >>> >>> >> if
>> >> >>> >>> >> the
>> >> >>> >>> >> error is exactly there, or in lines above.
>> >> >>> >>> >>
>> >> >>> >>> >> I would try commenting out those two routines an seeing if
>> >> >>> >>> >> the
>> >> >>> >>> >> file
>> >> >>> >>> >> assembles. If that works, I would binary search for the
>> >> >>> >>> >> exact
>> >> >>> >>> >> source
>> >> >>> >>> >> line
>> >> >>> >>> >> of an error through one of those routines and then the
>> >> >>> >>> >> other.
>> >> >>> >>> >> You
>> >> >>> >>> >> could
>> >> >>> >>> >> also approach this in the other direction, commenting out
>> >> >>> >>> >> all
>> >> >>> >>> >> of
>> >> >>> >>> >> the
>> >> >>> >>> >> other
>> >> >>> >>> >> routines in the file and adding things back until you find
>> >> >>> >>> >> and
>> >> >>> >>> >> error.
>> >> >>> >>> >>
>> >> >>> >>> >> Also, this file make use of C pre-processor macros defined
>> >> >>> >>> >> by
>> >> >>> >>> >> internals.h.
>> >> >>> >>> >> Are you building with a valid internals.h?
>> >> >>> >>> >>
>> >> >>> >>> >>
>> >> >>> >>> >> On Sat, Aug 30, 2014 at 4:42 AM, Fausto Saporito
>> >> >>> >>> >> <fausto.saporito at gmail.com>
>> >> >>> >>> >> wrote:
>> >> >>> >>> >>>
>> >> >>> >>> >>> Hello all,
>> >> >>> >>> >>>
>> >> >>> >>> >>> i'm trying to build CMUCL 18c under Tru64 5.1 using Digital
>> >> >>> >>> >>> C
>> >> >>> >>> >>> compiler
>> >> >>> >>> >>> and assembler.
>> >> >>> >>> >>> I have this error compiling alpha-assem.s
>> >> >>> >>> >>>
>> >> >>> >>> >>> as -g -Dosf1 -Dalpha
>> >> >>> >>> >>> -I/usr/users/fausap/wrk/CMUCL/src/18c/lisp
>> >> >>> >>> >>> -o
>> >> >>> >>> >>> alpha-assem.o alpha-assem.s
>> >> >>> >>> >>> alpha-assem.s(242) : error : syntax error : last token was
>> >> >>> >>> >>> 'undefined_tramp'
>> >> >>> >>> >>> alpha-assem.s(256) : error : syntax error : last token was
>> >> >>> >>> >>> 'closure_tramp'
>> >> >>> >>> >>> gmake: *** [alpha-assem.o] Error 1
>> >> >>> >>> >>>
>> >> >>> >>> >>> I know this is quite old version and unsupported arch, but
>> >> >>> >>> >>> do
>> >> >>> >>> >>> you
>> >> >>> >>> >>> know
>> >> >>> >>> >>> is there's a patch to fix this error ?
>> >> >>> >>> >>>
>> >> >>> >>> >>> thanks a lot,
>> >> >>> >>> >>> Fausto
>> >> >>> >>> >>> _______________________________________________
>> >> >>> >>> >>> cmucl-help mailing list
>> >> >>> >>> >>> cmucl-help at cmucl.cons.org
>> >> >>> >>> >>> http://lists.zs64.net/mailman/listinfo/cmucl-help
>> >> >>> >>> >>
>> >> >>> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> _______________________________________________
>> >> >>> cmucl-help mailing list
>> >> >>> cmucl-help at cmucl.cons.org
>> >> >>> http://lists.zs64.net/mailman/listinfo/cmucl-help
>> >> >>
>> >> >>
>> >
>> >
>
>
More information about the cmucl-help
mailing list