[PATCH] Building Git on Tru64

DORMANTno replies

7 messages, 5 authors, 2016-06-15 · open the first message on its own page

[PATCH] Building Git on Tru64

From: Daniel Richard G. <hidden>
Date: 2016-06-15 22:48:39

Building Git on a Tru64 V4.0G system (for the purpose of running a CMake
dashboard) was a bit of a challenge, and required numerous changes to
the source. It was a good exercise, however, in maintaining
compatibility with systems on which many modern facilities are missing.

A patch against 1.7.0.5 is attached, though parts of it are intended
more for reference than actual committing---some of the changes are system-
specific, and need to be integrated in a more generalized form.

A summary of the changes:

* Enum lists can't have a comma after the last element. (This was
  actually more for the benefit of the Solaris compiler, but Tru64
  complained as well.) I took out the comma, though for the sake of
  future diffs it may be preferable to add a last-element sentinel.

* Can't have C++-style comments in C code.

* Quelled a couple of control-reaches-end-of-non-void-function warnings
  by adding "return 0;" after an "exit(0);".

* compat/{hstrerror.c,inet_ntop.c,inet_pton.c} don't do any kind of feature-
  macro setup at the top, and a bit of this was necessary to get these
  files to compile.

* In daemon.c, the compiler complained about the last argument to
  accept() being the wrong size (32 bits instead of the expected 64).

* On Tru64, MAP_FAILED is #defined as (-1L), and the compiler chokes if
  you directly compare a pointer to an integer. So, need to cast
  MAP_FAILED to (void *), redundant as that may seem.

* Most of the modern features in the system headers are enabled by
  #defining _OSF_SOURCE. AES_SOURCE is needed to get setenv() and
  unsetenv().

* This rev of Tru64 doesn't have an inttypes.h header, so the #include
  has to be conditional, and you have to provide your own definitions of
  uint{16,32,64}_t and {,u}intptr_t. (These types are not present at all
  in the system headers.)

* The "inline" keyword is not supported.


Some additional necessities, handled in config.mak.autogen:

* The following options are needed:

        NO_HSTRERROR = 1
        NO_INET_NTOP = 1
        NO_INET_PTON = 1
        NO_NSEC = 1
        NO_SOCKADDR_STORAGE = 1
        NO_STRTOULL = 1

  Could checks for these be added to the configure script?

* Prototypes are not provided for the compat/* implementations of
  {,v}snprintf(), inet_ntop() and inet_pton() (and maybe others). This
  can potentially be an issue for at least inet_ntop(), which returns a
  pointer (that is truncated if the compiler assumes the function
  returns int).

* Need to define _POSIX_C_SOURCE with a value of at least 199506L, or
  else you don't get MAP_FAILED or various pthread-related types
  (pthread_attr_t, pthread_mutex_t et al.).

* Need to define _POSIX_PII_SOCKET to get socklen_t.


Even after all that, installing via DESTDIR doesn't work:
gmake install DESTDIR=/tmp/foo
    SUBDIR perl
perl.mak:691: *** ExtUtils::MakeMaker version "6.03" is older than 6.11 and so is likely incompatible with the DESTDIR mechanism.  Try setting NO_PERL_MAKEMAKER=1 instead.  Stop.
gmake[1]: *** [all] Error 2
gmake: *** [all] Error 2
gmake install DESTDIR=/tmp/foo NO_PERL_MAKEMAKER=1 
    SUBDIR perl
perl.mak:691: *** ExtUtils::MakeMaker version "6.03" is older than 6.11 and so is likely incompatible with the DESTDIR mechanism.  Try setting NO_PERL_MAKEMAKER=1 instead.  Stop.
gmake[1]: *** [all] Error 2
gmake: *** [all] Error 2

(Configuring with --without-perl prevents the build from even starting,
so is there any way to sidestep the above error?)

Comments are welcome, as well as requests for further testing. I'd like
to get Git to the point where it builds out-of-the-box on this system.


--Daniel


P.S.: Please Cc: any replies to me, as I am not subscribed to this list.


-- 
NAME = Daniel Richard G.     _\|/_    Remember, skunks
MAIL = skunk@iSKUNK.ORG     (/o|o\) _- don't smell bad---
MAIL+= skunk@alum.MIT.EDU   < (^),>     it's the people who
WWW  = (not there yet!)      /   \      annoy us that do!

Re: [PATCH] Building Git on Tru64

From: Alex Riesen <hidden>
Date: 2016-06-15 22:48:39

On Thu, Apr 15, 2010 at 21:09, Daniel Richard G. [off-list ref] wrote:
* On Tru64, MAP_FAILED is #defined as (-1L), and the compiler chokes if
 you directly compare a pointer to an integer. So, need to cast
 MAP_FAILED to (void *), redundant as that may seem.
That one may be better handled at one place (git-compat-util.h?) with
something like:

  #ifdef Tru64
  #define MAP_FAILED ((void *)MAP_FAILED)
  #endif

P.S. You may consider reading Documentation/SubmittingPatches.
The way you did it is a little unconventional.

Re: [PATCH] Building Git on Tru64

From: Daniel Richard G. <hidden>
Date: 2016-06-15 22:48:39

On Thu, 2010 Apr 15 21:29+0200, Alex Riesen wrote:
That one may be better handled at one place (git-compat-util.h?) with
something like:

  #ifdef Tru64
  #define MAP_FAILED ((void *)MAP_FAILED)
  #endif
I agree with the sentiment, but you can't have a macro refer to itself
:]
P.S. You may consider reading Documentation/SubmittingPatches. The way
you did it is a little unconventional.
The patch isn't meant to be committed as-is, at least not all of it.
Some of these things need to be massaged in a little (e.g. having
hstrerror.c #include git-compat-util.h instead of just sticking #define
_OSF_SOURCE at the top), but I need to hear from others on how to go
about this.


--Daniel


(Please Cc: any replies to me, as I am not subscribed to this list.)


-- 
NAME = Daniel Richard G.     _\|/_    Remember, skunks
MAIL = skunk@iSKUNK.ORG     (/o|o\) _- don't smell bad---
MAIL+= skunk@alum.MIT.EDU   < (^),>     it's the people who
WWW  = (not there yet!)      /   \      annoy us that do!

Re: [PATCH] Building Git on Tru64

From: Nicolas Pitre <nico@fluxnic.net>
Date: 2016-06-15 22:48:39

On Thu, 15 Apr 2010, Daniel Richard G. wrote:
On Thu, 2010 Apr 15 21:29+0200, Alex Riesen wrote:
quoted
That one may be better handled at one place (git-compat-util.h?) with
something like:

  #ifdef Tru64
  #define MAP_FAILED ((void *)MAP_FAILED)
  #endif
I agree with the sentiment, but you can't have a macro refer to itself
:]
you may undefine and redefine it appropriately instead.


Nicolas

Re: [PATCH] Building Git on Tru64

From: Daniel Richard G. <hidden>
Date: 2016-06-15 22:48:39

On Thu, 2010 Apr 15 16:04-0400, Nicolas Pitre wrote:
quoted
I agree with the sentiment, but you can't have a macro refer to
itself :]
you may undefine and redefine it appropriately instead.
Yes, the macro should have included the cast in the first place.

(I was going to say "you can't assume the value is always going to be -1
casted," but then this is only for Tru64, not for those weird platforms
that #define NULL as something other than (void*)0...)


--Daniel


-- 
NAME = Daniel Richard G.     _\|/_    Remember, skunks
MAIL = skunk@iSKUNK.ORG     (/o|o\) _- don't smell bad---
MAIL+= skunk@alum.MIT.EDU   < (^),>     it's the people who
WWW  = (not there yet!)      /   \      annoy us that do!

Re: [PATCH] Building Git on Tru64

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:48:39

"Daniel Richard G." [off-list ref] writes:
On Thu, 2010 Apr 15 21:29+0200, Alex Riesen wrote:
quoted
That one may be better handled at one place (git-compat-util.h?) with
something like:

  #ifdef Tru64
  #define MAP_FAILED ((void *)MAP_FAILED)
  #endif
I agree with the sentiment, but you can't have a macro refer to itself
It can.  From (cpp.info)

  3.10.5 Self-Referential Macros
  ------------------------------

  A "self-referential" macro is one whose name appears in its definition.
  Recall that all macro definitions are rescanned for more macros to
  replace.  If the self-reference were considered a use of the macro, it
  would produce an infinitely large expansion.  To prevent this, the
  self-reference is not considered a macro call.  It is passed into the
  preprocessor output unchanged.

  [...]

     One common, useful use of self-reference is to create a macro which
  expands to itself.  If you write

       #define EPERM EPERM

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: [PATCH] Building Git on Tru64

From: Erik Faye-Lund <hidden>
Date: 2016-06-15 22:48:39

On Thu, Apr 15, 2010 at 11:24 PM, Jakub Narebski [off-list ref] wrote:
"Daniel Richard G." [off-list ref] writes:
quoted
On Thu, 2010 Apr 15 21:29+0200, Alex Riesen wrote:
quoted
That one may be better handled at one place (git-compat-util.h?) with
something like:

  #ifdef Tru64
  #define MAP_FAILED ((void *)MAP_FAILED)
  #endif
I agree with the sentiment, but you can't have a macro refer to itself
It can.  From (cpp.info)

 3.10.5 Self-Referential Macros
 ------------------------------

 <snip>  It is passed into the
 preprocessor output unchanged.
Not very useful in this case, no?

$ echo "#define MAP_FAILED (-1L)
#define MAP_FAILED ((void *)MAP_FAILED)
void *v = MAP_FAILED" | gcc -x c -
<stdin>:2:1: warning: "MAP_FAILED" redefined
<stdin>:1:1: warning: this is the location of the previous definition
<stdin>:3: error: 'MAP_FAILED' undeclared here (not in a function)
<stdin>:3: error: expected ',' or ';' at end of input
$ echo "#define MAP_FAILED (-1L)
#define MAP_FAILED ((void *)MAP_FAILED)
void *v = MAP_FAILED" | cpp
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
<stdin>:2:1: warning: "MAP_FAILED" redefined
<stdin>:1:1: warning: this is the location of the previous definition


void *v = ((void *)MAP_FAILED)
$

-- 
Erik "kusma" Faye-Lund
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help