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 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. regards, Fausto 2014-08-31 19:34 GMT+02:00 Fausto Saporito <[email protected]>: > 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 <[email protected]>: >> >> >> >> On Sat, Aug 30, 2014 at 2:57 PM, Fausto Saporito <[email protected]> >> 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 <[email protected]>: >>> > 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 <[email protected]>: >>> >> 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 >>> >> <[email protected]> >>> >> 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 >>> >>> <[email protected]>: >>> >>> > 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 <[email protected]>: >>> >>> >> 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 >>> >>> >> <[email protected]> >>> >>> >> 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 >>> >>> >>> [email protected] >>> >>> >>> http://lists.zs64.net/mailman/listinfo/cmucl-help >>> >>> >> >>> >>> >> >>> >> >>> >> >>> _______________________________________________ >>> cmucl-help mailing list >>> [email protected] >>> http://lists.zs64.net/mailman/listinfo/cmucl-help >> >> _______________________________________________ cmucl-help mailing list [email protected] http://lists.zs64.net/mailman/listinfo/cmucl-help
