[cmucl-help] CMUCL 18c building on tru64 5.1

Fausto Saporito fausto.saporito at gmail.com
Wed Sep 3 23:18:58 UTC 2014


Hello,

i checked funcall0 and it is ok ... initial_function is

(ladebug) p function
808011849

and in binary is : 110000001010010100100001001001

so the address is valid (least 3 bits are 001).


2014-09-04 0:42 GMT+02:00 Fausto Saporito <fausto.saporito at gmail.com>:
> Hello Raymond,
>
> I have a doubt... I tried to compile the lisp frontend with gcc (under
> Tru64)... I suppose the Config file has been made with gcc in mind...
> the -I- in the CPPFLAGS is gcc syntax...not DECC
> Also gmake doesn't complain about the depends generated by gcc.
>
> I have only gcc4.x at the moment, and maybe is too new...
>
> I have an error compiling src/lisp/interrupt.c at line 644:
>
>  ../../src/lisp/interrupt.c:644: error: lvalue required as left
> operand of assignment
>
> That line is :
>
> SC_NPC(context) = SC_PC(context) + 4;
>
> maybe it could be SC_PC(context) = SC_PC(context) + 4;
>
> this line interpreted only if not x86.
> SC_NPC is only used in that line... so it's quite strange.
>
> regards
> fausto
>
>
>
> 2014-09-03 22:13 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>>
>>
>>
>> On Wed, Sep 3, 2014 at 12:52 PM, Fausto Saporito <fausto.saporito at gmail.com>
>> wrote:
>>>
>>> Hello Ray,
>>>
>>> the sigsegv happens calling funcall0(initial_function)... at line 702
>>> in main function.
>>>
>>> ladebug under Tru64 is very cool ;-)
>>>
>>> now... what is the purpose of funcall0 ?
>>
>>
>> This is the difficult fun part.
>>
>> funcall0 is calling the Lisp function given in initial_function with 0
>> arguments. If it's actually crashing at that line, then does
>> initial_function look valid? It should be an address somewhere in the heap
>> and the least 3 bits should be 001.
>>
>> If this is not true, then either the creation of kernel.core is wrong or
>> loading the core is wrong. (The initial_function is in the core file.
>> Somewhere. I don't remember exactly.)
>>
>>
>>>
>>>
>>> regards,
>>> Fausto
>>>
>>>
>>>
>>> 2014-09-03 19:08 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>>> >
>>> >
>>> >
>>> > On Wed, Sep 3, 2014 at 9:29 AM, Fausto Saporito
>>> > <fausto.saporito at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hello Ray,
>>> >>
>>> >> in the alpha-cross and alpha-target log... there are no errors. it
>>> >> compiles like a knive in the butter :)
>>> >
>>> >
>>> > Cool!
>>> >
>>> >>
>>> >>
>>> >> But maybe "interrupt_handle_now" could refers to a feature we excluded
>>> >> from the build.
>>> >>
>>> >> this is the "back" output
>>> >>
>>> >> ldb> back
>>> >> Backtrace:
>>> >> <Frame 0x50000000 [interrupted], CODE: 0x3029472F, %INITIAL-FUNCTION,
>>> >> <no LRA>, PC: 0xcfd6b7b8>
>>> >
>>> >
>>> > Ok, that's not very helpful. You have to break out your debugger to
>>> > figure
>>> > out why you're getting signal 11. (segv?)
>>> >
>>> >>
>>> >>
>>> >> About 18c test, can I use the 19c binaries (on linux) to cross-compile
>>> >> a 18c, or do I have to install a 18c linux binaries ?
>>> >
>>> >
>>> > It's best to use the same version, so use 18c binaries.
>>> >
>>> > Good luck!
>>> > --
>>> > Ray
>>> >
>>> >>
>>> >>
>>> >> thanks,
>>> >> Fausto
>>> >>
>>> >> 2014-09-03 18:24 GMT+02:00 Raymond Toy <toy.raymond at gmail.com>:
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Wed, Sep 3, 2014 at 4:57 AM, Fausto Saporito
>>> >> > <fausto.saporito at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> ok.. I fixed the version problem: created a file, in
>>> >> >> alpha-target/lisp
>>> >> >> directory, "version" with "-1" in it.
>>> >> >> Now the version matches with kernel.core (version 0).
>>> >> >>
>>> >> >> But it seems a needed feature is missing:
>>> >> >>
>>> >> >> axpvm01.gitanes.taz> lisp -core kernel.core
>>> >> >> interrupt_handle_now: No handler for signal 11?
>>> >> >> LDB monitor
>>> >> >>
>>> >> >> ldb>
>>> >> >>
>>> >> >
>>> >> > This is really great! But now comes the hard part.
>>> >> >
>>> >> > First, I would check the logs for any errors and see if they're
>>> >> > relevant.
>>> >> > Post the errors here.
>>> >> >
>>> >> > Second, from ldb you can try "back" to get a backtrace. That might
>>> >> > have
>>> >> > pointers to what might have gone wrong.
>>> >> >
>>> >> > Third, if none of the above work, you'll have to get out your
>>> >> > debugger
>>> >> > and
>>> >> > see what is causing signal 11.  This is the hard part.
>>> >> >
>>> >> > Since it seems you can successfully cross-compile from 19c, perhaps
>>> >> > it
>>> >> > would
>>> >> > be easiest to go back farther and try again with 18c or something. It
>>> >> > might
>>> >> > be easier to get something going and then we can think about getting
>>> >> > alpha
>>> >> > running on a more up-to-date version of the code.
>>> >> >
>>> >> > Good luck!
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> 2014-09-03 13:39 GMT+02:00 Fausto Saporito
>>> >> >> <fausto.saporito at gmail.com>:
>>> >> >> > Hello all,
>>> >> >> >
>>> >> >> > ok... this is a real blocking error:
>>> >> >> >
>>> >> >> > axpvm01.gitanes.taz> alpha-target/lisp/lisp -core
>>> >> >> > alpha-target/lisp/kernel.core
>>> >> >> > WARNING: startup-code version (2) different from core version (0).
>>> >> >> > You may lose big.
>>> >> >> > interrupt_handle_now: No handler for signal 11?
>>> >> >> > LDB monitor
>>> >> >> > ldb> quit
>>> >> >> > Really quit? [y]
>>> >> >> >
>>> >> >> > and really I cannot understand the reason.
>>> >> >> > kernel.core has been generated with the same sources of the lisp
>>> >> >> > frontend! Why there's this version mismatch ?
>>> >> >> >
>>> >> >> > I changed internals.h cause it was totally wrong (feature list
>>> >> >> > section) and I copied them from internals.inc ... is it correct ?
>>> >> >> > But internals.inc has much more features than cross.lisp, maybe
>>> >> >> > this
>>> >> >> > could be the problem...
>>> >> >> >
>>> >> >> > FEATURE_CMU18E = 1
>>> >> >> > FEATURE_CMU18 = 1
>>> >> >> > FEATURE_BSD = 1
>>> >> >> > FEATURE_OSF1 = 1
>>> >> >> > FEATURE_ALPHA = 1
>>> >> >> > FEATURE_CMU = 1
>>> >> >> > FEATURE_IEEE_FLOATING_POINT = 1
>>> >> >> > FEATURE_ANSI_CL = 1
>>> >> >> > FEATURE_COMMON_LISP = 1
>>> >> >> > FEATURE_COMMON = 1
>>> >> >> > FEATURE_HASH_NEW = 1
>>> >> >> > FEATURE_RANDOM_MT19937 = 1
>>> >> >> > FEATURE_UNIX = 1
>>> >> >> > FEATURE_RELATIVE_PACKAGE_NAMES = 1
>>> >> >> > FEATURE_MODULAR_ARITH = 1
>>> >> >> > FEATURE_CONSERVATIVE_FLOAT_TYPE = 1
>>> >> >> > FEATURE_PYTHON = 1
>>> >> >> > FEATURE_CMU19C = 1
>>> >> >> > FEATURE_CMU19 = 1
>>> >> >> > FEATURE_PCL = 1
>>> >> >> > <-----
>>> >> >> > FEATURE_PORTABLE_COMMONLOOPS = 1
>>> >> >> > FEATURE_PCL_STRUCTURES = 1
>>> >> >> > FEATURE_GERDS_PCL = 1
>>> >> >> > FEATURE_BOOTSTRAP = 1
>>> >> >> > FEATURE_NO_PCL = 1
>>> >> >> > <-----
>>> >> >> > FEATURE_NO_CLX = 1
>>> >> >> > FEATURE_NO_CLM = 1
>>> >> >> > FEATURE_NO_HEMLOCK = 1
>>> >> >> > FEATURE_LITTLE_ENDIAN = 1
>>> >> >> >
>>> >> >> > Is it correct
>>> >> >> >
>>> >> >> > FEATURE_PCL = 1
>>> >> >> >
>>> >> >> > then
>>> >> >> >
>>> >> >> > FEATURE_NOPCL = 1
>>> >> >> >
>>> >> >> > ???
>>> >> >> >
>>> >> >> > regards,
>>> >> >> > Fausto
>>> >> >> >
>>> >> >> > 2014-09-03 13:13 GMT+02:00 Fausto Saporito
>>> >> >> > <fausto.saporito at gmail.com>:
>>> >> >> >> This is trivial .. I suppose.
>>> >> >> >> I'm using standard Tru64 5.1b C compiler, but it seems generates
>>> >> >> >> a
>>> >> >> >> Depend file gmake doesn't like too much :-)
>>> >> >> >> I'm using gmake 3.80, is there a mandatory version ?
>>> >> >> >>
>>> >> >> >> gmake: Entering directory
>>> >> >> >> `/usr/users/fausap/CMU/alpha-target/lisp'
>>> >> >> >> Depends:454: *** missing separator.  Stop.
>>> >> >> >> gmake: Leaving directory
>>> >> >> >> `/usr/users/fausap/CMU/alpha-target/lisp'
>>> >> >> >>
>>> >> >> >> this code starts at line 454
>>> >> >> >>
>>> >> >> >> struct array {
>>> >> >> >>     lispobj header;
>>> >> >> >>     lispobj fill_pointer;
>>> >> >> >>     lispobj fill_pointer_p;
>>> >> >> >>     lispobj elements;
>>> >> >> >>     lispobj data;
>>> >> >> >>     lispobj displacement;
>>> >> >> >>     lispobj displaced_p;
>>> >> >> >>     lispobj dimensions[1];
>>> >> >> >> };
>>> >> >> >>
>>> >> >> >> thanks,
>>> >> >> >> Fausto
>>> >> >> >>
>>> >> >> >> 2014-09-03 11:39 GMT+02:00 Fausto Saporito
>>> >> >> >> <fausto.saporito at gmail.com>:
>>> >> >> >>> Ohhhh ... BIG NeWS!
>>> >> >> >>>
>>> >> >> >>> 19c works! Cross compiling was fine.
>>> >> >> >>> Now if I understood well, I have to move all the alpha-target
>>> >> >> >>> directory in Tru64 and recompile... correct ?
>>> >> >> >>> Using src/tools/build-world.sh script ?
>>> >> >> >>>
>>> >> >> >>> thanks
>>> >> >> >>> Fausto
>>> >> >> >>>
>>> >> >> >>>
>>> >> >> >>> 2014-09-03 11:28 GMT+02:00 Fausto Saporito
>>> >> >> >>> <fausto.saporito at gmail.com>:
>>> >> >> >>>> Hello all,
>>> >> >> >>>>
>>> >> >> >>>> I saw there're some patches for 19c and 19d and I found how to
>>> >> >> >>>> apply
>>> >> >> >>>> them.
>>> >> >> >>>> The question is: how can I update the lisp.core ? Is it needed
>>> >> >> >>>> ?
>>> >> >> >>>> Or
>>> >> >> >>>> do
>>> >> >> >>>> I have to load each time those patches ?
>>> >> >> >>>>
>>> >> >> >>>> thanks,
>>> >> >> >>>> Fausto
>>> >> >> >>>>
>>> >> >> >>>>
>>> >> >> >>>> 2014-09-03 8:41 GMT+02:00 Fausto Saporito
>>> >> >> >>>> <fausto.saporito at gmail.com>:
>>> >> >> >>>>> Hello Ray,
>>> >> >> >>>>>
>>> >> >> >>>>> no luck with 19d. But maybe it has the double-double support
>>> >> >> >>>>> too...
>>> >> >> >>>>>
>>> >> >> >>>>> I have the same errors, but instead of sigsegv at the end, I
>>> >> >> >>>>> got
>>> >> >> >>>>> a
>>> >> >> >>>>> stack overflow:
>>> >> >> >>>>>
>>> >> >> >>>>> Control stack overflow
>>> >> >> >>>>>    [Condition of type STACK-OVERFLOW]
>>> >> >> >>>>>
>>> >> >> >>>>> Restarts:
>>> >> >> >>>>>   0: [CONTINUE] Blow this file
>>> >> >> >>>>>   1:            Return NIL from load of
>>> >> >> >>>>> "target:tools/worldcom".
>>> >> >> >>>>>   2: [ABORT   ] Return to Top-Level.
>>> >> >> >>>>>
>>> >> >> >>>>> Debug  (type H for help)
>>> >> >> >>>>>
>>> >> >> >>>>> (YELLOW-ZONE-HIT)
>>> >> >> >>>>> Source:
>>> >> >> >>>>> ; File: target:code/interr.lisp
>>> >> >> >>>>> (ERROR 'STACK-OVERFLOW)
>>> >> >> >>>>>
>>> >> >> >>>>> and in compile-compiler.log I found again a DOUBLE-DOUBLE
>>> >> >> >>>>> reference:
>>> >> >> >>>>>
>>> >> >> >>>>> ; Comment: $Header:
>>> >> >> >>>>> /project/cmucl/cvsroot/src/compiler/new-assem.lisp,v 1.34
>>> >> >> >>>>> 2004/08/02
>>> >> >> >>>>> 16:04:42 cwang Exp $
>>> >> >> >>>>>
>>> >> >> >>>>> ; Compiling DEFUN SEGMENT-MAP-OUTPUT:
>>> >> >> >>>>>
>>> >> >> >>>>> Bound is not *, a DOUBLE-DOUBLE-FLOAT or a list of a
>>> >> >> >>>>> DOUBLE-DOUBLE-FLOAT: 0
>>> >> >> >>>>>
>>> >> >> >>>>> Aborting...
>>> >> >> >>>>>
>>> >> >> >>>>> I'll try with 19c
>>> >> >> >>>>>
>>> >> >> >>>>> 2014-09-03 8:29 GMT+02:00 Fausto Saporito
>>> >> >> >>>>> <fausto.saporito at gmail.com>:
>>> >> >> >>>>>> Hello Ray,
>>> >> >> >>>>>>
>>> >> >> >>>>>> I started with 19d, but I have this strange error:
>>> >> >> >>>>>>
>>> >> >> >>>>>> ; Error: (during macroexpansion)
>>> >> >> >>>>>> ;
>>> >> >> >>>>>> ; Error in function META-SC-OR-LOSE:
>>> >> >> >>>>>> ;    DOUBLE-DOUBLE-REG is not a defined storage class.
>>> >> >> >>>>>> ; ;
>>> >> >> >>>>>>
>>> >> >> >>>>>> ; Error: (during macroexpansion)
>>> >> >> >>>>>> ;
>>> >> >> >>>>>> ; Error in function META-SC-OR-LOSE:
>>> >> >> >>>>>> ;    COMPLEX-DOUBLE-DOUBLE-REG is not a defined storage
>>> >> >> >>>>>> class.
>>> >> >> >>>>>>
>>> >> >> >>>>>> but in 19d there shouldn't be support for DOUBLE-DOUBLE ...
>>> >> >> >>>>>> correct
>>> >> >> >>>>>> ?
>>> >> >> >>>>>>
>>> >> >> >>>>>> I'm using 19d binaries to cross-build 19d
>>> >> >> >>>>>>
>>> >> >> >>>>>> 2014-09-03 4:17 GMT+02:00 Raymond Toy
>>> >> >> >>>>>> <toy.raymond at gmail.com>:
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> On Tue, Sep 2, 2014 at 4:53 PM, Fausto Saporito
>>> >> >> >>>>>>> <fausto.saporito at gmail.com>
>>> >> >> >>>>>>> wrote:
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>> 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 ?
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> I think it's a mismatch between what the cross compiler has
>>> >> >> >>>>>>> and
>>> >> >> >>>>>>> what the
>>> >> >> >>>>>>> host compiler has. I've never figured this out.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> So, I think it's best to start with a lisp without
>>> >> >> >>>>>>> double-double
>>> >> >> >>>>>>> support.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> Support for double-double was apparently done by 19e, so
>>> >> >> >>>>>>> your
>>> >> >> >>>>>>> best
>>> >> >> >>>>>>> bet is to
>>> >> >> >>>>>>> do a checkout from 19d.  I think everything that you've done
>>> >> >> >>>>>>> up
>>> >> >> >>>>>>> to
>>> >> >> >>>>>>> now still
>>> >> >> >>>>>>> applies.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> Once that is done, we can consider adding double-double for
>>> >> >> >>>>>>> alpha.
>>> >> >> >>>>>>> It's
>>> >> >> >>>>>>> relatively easy, but you'll have to write a bunch of vops.
>>> >> >> >>>>>>> They
>>> >> >> >>>>>>> can probably
>>> >> >> >>>>>>> be copied almost verbatim from the sparc or ppc ports with
>>> >> >> >>>>>>> small
>>> >> >> >>>>>>> changes in
>>> >> >> >>>>>>> the actual instructions.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>>
>>> >> >> >>>>>>>> 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))
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> One last thing:  remove :alien-callback too. Alpha doesn't
>>> >> >> >>>>>>> support
>>> >> >> >>>>>>> that.
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> Hopefully this will get us farther along....
>>> >> >> >>>>>>>
>>> >> >> >>>>>>> --
>>> >> >> >>>>>>> Ray
>>> >> >> >>>>>>>
>>> >> >> >>>>>>>
>>> >> >
>>> >> >
>>> >
>>> >
>>
>>


More information about the cmucl-help mailing list