| Date Of Receipt: 18-MAY-1993 10:14:16.55
From: FLUME::"[email protected]" "Grant Van Dyck 381-2932"
To: [email protected], [email protected], [email protected]
CC: [email protected], [email protected], [email protected]
Subj: Re: Cross builds for alpha systems...
Sarah, Al, Darrell et al.
I read this, but I'd like to know if this means that the cross-build
is OFFICIALLY dead; that we no longer have to include space/hooks for
the cross build in the tools/rc_files space, that we no longer have to
try and answer/resolve cross-build problems etc.
If so, then please make a Global Official announcement to that effect,
otherwise we will continue to remain in the loop for all those people
who still think it's OK to build cross.
Thanks, Grant
| Mike,
|
| The cross tools are not supported for ueg builds. See mail below.
|
| Delivery-Date: Wed, 21 Apr 93 22:12:42 -0400
| Return-Path: newhouse
| Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
| id AA25522; Wed, 21 Apr 1993 22:12:15 -0400
| Date: Wed, 21 Apr 1993 22:12:15 -0400
| From: newhouse (Tim Newhouse UEG)
| To: [email protected]
| Subject: Re: Tim are you still supporting the cross tool kit?
| Cc: gooey::spence, meyer, newhouse, usilton
|
| we do support the V1.2 cross kit. that was our last release. based
| on our quality and performance work we should be recommending that
| developers use v1.3 native when possible. any bits we ship should be built
| that way. we are not actively fixing any cross kit problems.
| -Tim
| ---------------
| Delivery-Date: Thu, 22 Apr 93 12:15:38 -0400
| Return-Path: [email protected]
| Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
| id AA19104; Thu, 22 Apr 1993 12:15:24 -0400
| Received: from localhost by toto.zk3.dec.com (5.65/Ultrix-4.3)
| id AA11866; Thu, 22 Apr 1993 12:15:22 -0400
| Message-Id: <[email protected]>
| To: [email protected]
| Cc: [email protected], [email protected], [email protected]
| Subject:
| Date: Thu, 22 Apr 93 12:15:21 EDT
| From: "Susan Usilton 381-2928" <[email protected]>
|
| WE are not supporting the cross-tools. They are being 'supported'
| by the WWAMC which ships them as a product. They are currently working
| to release the SSB version. Our responsibility for maintenance stopped
| with the SSB version.
| su
|
|
|
| >
| > Maybe there should be a meeting to talk about this, but thought I would
| > put what I know on the table and let people take shots at it.
| >
| > o No one is building in a cross environment for the Sterling
| > release. (its broke!)
| >
| > o Need a means to be able to build objects to run on the native
| > machine that know about the data format of the target machine,
| > when doing cross builds (mips 64 bit compiler one example).
| >
| > Its easy enoughf to have standard.mk know when the build is native or
> cross. It also seems like it would be a good idea to do the following
| > if CCTYPE is set to host on cross development builds than the host_* rules
| > need to reference the compiler that knows about the target machines
| > data formats.
| >
| > The tools directory hierarchy is setup like this...
| >
| > tools/${host_machine}_${host_os_type}/${target_machine}/...
| >
| > I would like to have a native-that-knows-about-cross-compiler directory
| > in the above subdirectory. In my testing I called it cc, rational
| > that acc, and mcc generate executables for target machines, (alpha and
| > mips), and for local (none cross, the running system is used). Anyway
| > I don't care what the name is but it should be generic and clear.
| >
| > With the aboved mentioned changes, all that should be needed to support
| > build objects to run native that know about cross data types, would be
| > the following:
| >
| > o Leave majority of Makefiles alone!
| >
| > o Enhance standard.mk to know about native/cross host rules.
| >
| > o Add new value to custom.build, something like COFF_CC_EXEC_PREFIX
| > where the CC is the name I don't care what it is but needs
| > to be generic.
| >
| > o Populate fully (headers, compilers, etc...) the COFF_CC_EXEC_PREFIX
| > in the tools directory.
| >
| > I would like to hear any feedback/comments about this. I belive its very
| > important to keep the ODE pool model in place and I firmly belive that
| > all the variants that we can dream up are possible within the existing
| > pool structure and Makefiles.
| >
| >
| > =====================================================================
| > Michael D. Fairbrother, M/S: ZKO3-3/U14 TCP/IP: [email protected]
| > Digital Equipment Corporation DECnet: RUDDY::MDF
| > 110 Spit Brook Road Voice: 603-881-2399 (DTN-381-2399)
| > Nashua, New Hampshire 03062-2698 FAX: 603-881-2257 (DTN-381-2257)
|
|
| Date Of Receipt: 18-MAY-1993 10:31:50.33
From: WASTED::"[email protected]" "Sarah Tappan AUEG"
To: "Michael D. Fairbrother" <[email protected]>
CC: [email protected]
Subj: Re: Cross builds for alpha systems...
Mike,
The cross tools are not supported for ueg builds. See mail below.
Delivery-Date: Wed, 21 Apr 93 22:12:42 -0400
Return-Path: newhouse
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA25522; Wed, 21 Apr 1993 22:12:15 -0400
Date: Wed, 21 Apr 1993 22:12:15 -0400
From: newhouse (Tim Newhouse UEG)
To: [email protected]
Subject: Re: Tim are you still supporting the cross tool kit?
Cc: gooey::spence, meyer, newhouse, usilton
we do support the V1.2 cross kit. that was our last release. based
on our quality and performance work we should be recommending that
developers use v1.3 native when possible. any bits we ship should be built
that way. we are not actively fixing any cross kit problems.
-Tim
---------------
Delivery-Date: Thu, 22 Apr 93 12:15:38 -0400
Return-Path: [email protected]
Received: by flume.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA19104; Thu, 22 Apr 1993 12:15:24 -0400
Received: from localhost by toto.zk3.dec.com (5.65/Ultrix-4.3)
id AA11866; Thu, 22 Apr 1993 12:15:22 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject:
Date: Thu, 22 Apr 93 12:15:21 EDT
From: "Susan Usilton 381-2928" <[email protected]>
WE are not supporting the cross-tools. They are being 'supported'
by the WWAMC which ships them as a product. They are currently working
to release the SSB version. Our responsibility for maintenance stopped
with the SSB version.
su
>
> Maybe there should be a meeting to talk about this, but thought I would
> put what I know on the table and let people take shots at it.
>
> o No one is building in a cross environment for the Sterling
> release. (its broke!)
>
> o Need a means to be able to build objects to run on the native
> machine that know about the data format of the target machine,
> when doing cross builds (mips 64 bit compiler one example).
>
> Its easy enoughf to have standard.mk know when the build is native or
> cross. It also seems like it would be a good idea to do the following
> if CCTYPE is set to host on cross development builds than the host_* rules
> need to reference the compiler that knows about the target machines
> data formats.
>
> The tools directory hierarchy is setup like this...
>
> tools/${host_machine}_${host_os_type}/${target_machine}/...
>
> I would like to have a native-that-knows-about-cross-compiler directory
> in the above subdirectory. In my testing I called it cc, rational
> that acc, and mcc generate executables for target machines, (alpha and
> mips), and for local (none cross, the running system is used). Anyway
> I don't care what the name is but it should be generic and clear.
>
> With the aboved mentioned changes, all that should be needed to support
> build objects to run native that know about cross data types, would be
> the following:
>
> o Leave majority of Makefiles alone!
>
> o Enhance standard.mk to know about native/cross host rules.
>
> o Add new value to custom.build, something like COFF_CC_EXEC_PREFIX
> where the CC is the name I don't care what it is but needs
> to be generic.
>
> o Populate fully (headers, compilers, etc...) the COFF_CC_EXEC_PREFIX
> in the tools directory.
>
> I would like to hear any feedback/comments about this. I belive its very
> important to keep the ODE pool model in place and I firmly belive that
> all the variants that we can dream up are possible within the existing
> pool structure and Makefiles.
>
>
> =====================================================================
> Michael D. Fairbrother, M/S: ZKO3-3/U14 TCP/IP: [email protected]
> Digital Equipment Corporation DECnet: RUDDY::MDF
> 110 Spit Brook Road Voice: 603-881-2399 (DTN-381-2399)
> Nashua, New Hampshire 03062-2698 FAX: 603-881-2257 (DTN-381-2257)
|