Re: [PATCH] Add Tru64/OSF1 support in Makefile

From: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Date: Apr 2, 2010, 14:56 UTC
Message-ID: <RWfCNK1AsUFfin9YdRY1QqUtD-ISnv9hImfDeE0DFlh3_fRWdvEF2w@cipher.nrlssc.navy.mil>
In-Reply-To: <u2ld2d39d861004020707m7577182et40b4cd6b93bae830@mail.gmail.com>

On 04/02/2010 09:07 AM, Tor Arntsen wrote:

Show 30 quoted lines

> On Wed, Mar 31, 2010 at 18:29, Brandon Casey
> <brandon.casey.ctr@nrlssc.navy.mil> wrote:
>> On 03/30/2010 01:22 PM, Tor Arntsen wrote:
>>> This patch to Makefile makes git build for me on Tru64/OSF1 V5.1 with
>>> the native compiler.
> [..]
>>> +ifeq ($(uname_S),OSF1)
>>> +     # Tested with V5.1 w/libcurl and zlib-1.1.4-5 in /usr/local/
>>> +     CC = cc
>>> +     CFLAGS = -O2 -g3
>> I wonder if the native compiler will be the most common compiler
>> used on this platform?  I tend to lean towards configuring the
>> Makefile for gcc, unless gcc is not available for a platform. The
>> user can set CC and CFLAGS in config.mak and on the make command
>> line if they desire something different.
>>
>> This isn't an objection by me, I'm just mentioning it to bring
>> attention to the issue in case others think it is worthy for
>> git to have a stated policy one way or the other.
> 
> I'm not certain. I do in fact have gcc (3.3) installed on this Tru64
> box, but it doesn't seem to be part of the original 'freeware' CD that
> used to come with Tru64. Besides, the freeware CD was first removed as
> physical CD, and later (two or three years ago, apparently) pulled by
> HP from the online download which was used by their 'tachometer'
> ('apt-get'-like) freeware tool. Tru64 V51B (which seems to be the
> latest, there's no 5.2 as I originally thought) is still available for
> download, and so is the native compiler. As far as I can tell it's
> incredibly difficult to find precompiled freeware/oss packages for
> Tru64 anymore.

So the native compiler is a free download? Then yeah, it sounds like configuring the Makefile for the native compiler is the right thing to do.

Show 5 quoted lines

>> Also, I wonder if it suffers from the same trap handling that
>> ksh has on SunOS.
> [..]
> I tested that snippet you provided, and it exits with 0 on Tru64 (I
> also verified that indeed it doesn't on Solaris 10).

Ok, good. Solaris's ksh is the only one I've found that handles it wrong.

Here's another snippet which will show whether $? has the correct value inside a trap on EXIT:

   (atrap () { exit $?; }
    trap atrap EXIT
    exit 1) && echo 'FAILURE' || echo 'SUCCESS'

If that prints 'FAILURE', then you will need the patch that I have in order to run the test suite. ksh from IRIX 6.5 and Solaris both fail.

-brandon