[PATCH] minor Makefile and local-pull.c edits for Darwin

[PATCH] minor Makefile and local-pull.c edits for Darwin

[Mark Allen]

Darwin puts all of the openssl functionality into libcrypto not libssl. Also, gcc
complains about the st.size return value in local-pull.c if it's not cast explicitly as a
long.

Signed-off-by: Mark Allen <mrallen1@yahoo.com>

Index: Makefile
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/Makefile  (mode:100644)
+++ uncommitted/Makefile  (mode:100644)
@@ -80,7 +80,11 @@
        LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
 else
        SHA1_HEADER=<openssl/sha.h>
-       LIBS += -lssl
+       ifdef DARWIN
+               LIBS += -lcrypto
+       else
+               LIBS += -lssl
+       endif
 endif
 endif
 
Index: local-pull.c
===================================================================
--- 972d8624458936868e6f392b40858b7c362af8cd/local-pull.c  (mode:100644)
+++ uncommitted/local-pull.c  (mode:100644)
@@ -71,7 +71,7 @@
                close(ofd);
                if (status)
                        fprintf(stderr, "cannot write %s (%ld bytes)\n",
-                               dest_filename, st.st_size);
+                               dest_filename, (long) st.st_size);
                else
                        pull_say("copy %s\n", hex);
                return status;

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[Daniel Barkalow]

On Mon, 9 May 2005, Mark Allen wrote:

> Darwin puts all of the openssl functionality into libcrypto not
> libssl.

Actually, the relevant openssl functionality is always in libcrypto, not
libssl. It's just that ELF shared libraries include dependancies, and
libssl pulls in libcrypto. If you change it, change it for everyone,
rather than just Darwin.

	-Daniel
*This .sig left intentionally blank*

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[Junio C Hamano]

>>>>> "DB" == Daniel Barkalow <barkalow@iabervon.org> writes:

DB> Actually, the relevant openssl functionality is always in libcrypto, not
DB> libssl...

Ok, could people try the following single liner, and if it
breaks yell loudly at me (or Daniel ;-)?  It worked for me but I
just want to make sure before I put it in git-jc repository
which I will ask Linus to pull from later.

$ jit-diff 0:7
# - HEAD: Introduce GIT_DIR environment variable.
# + 7: Link with -lcrypto not -lssl
--- a/Makefile
+++ b/Makefile
@@ -60,7 +60,7 @@ ifdef PPC_SHA1
   LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
 else
   SHA1_HEADER=<openssl/sha.h>
-  LIBS += -lssl
+  LIBS += -lcrypto
 endif
 endif
 

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[H. Peter Anvin]

Mark Allen wrote:

>  
> Index: local-pull.c
> ===================================================================
> --- 972d8624458936868e6f392b40858b7c362af8cd/local-pull.c  (mode:100644)
> +++ uncommitted/local-pull.c  (mode:100644)
> @@ -71,7 +71,7 @@
>                 close(ofd);
>                 if (status)
>                         fprintf(stderr, "cannot write %s (%ld bytes)\n",
> -                               dest_filename, st.st_size);
> +                               dest_filename, (long) st.st_size);
>                 else
>                         pull_say("copy %s\n", hex);
>                 return status;

This is just plain WRONG.  st.st_size is longer than long on many 
architectures, including Linux/i386.

The easiest way to deal with it is to #include <inttypes.h>, use %jd and 
cast it to (intmax_t).  That is, however, a C99-ism.

	-hpa

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[Junio C Hamano]

>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:

HPA> This is just plain WRONG.  st.st_size is longer than long on many
HPA> architectures, including Linux/i386.

HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
HPA> and cast it to (intmax_t).  That is, however, a C99-ism.

Actually the easiest way is to stop reporting the size.  Nobody
else in core GIT reports st.st_size in their error messages.

Although I agree with you that what you say about the size of
st.st_size is correct, in GIT world view, apparently "unsigned
long" is big enough to hold st.st_size all over the code.  Would
you recommend tackling that assumption as well?

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> HPA> This is just plain WRONG.  st.st_size is longer than long on many
> HPA> architectures, including Linux/i386.
> 
> HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
> HPA> and cast it to (intmax_t).  That is, however, a C99-ism.
> 
> Actually the easiest way is to stop reporting the size.  Nobody
> else in core GIT reports st.st_size in their error messages.
> 
> Although I agree with you that what you say about the size of
> st.st_size is correct, in GIT world view, apparently "unsigned
> long" is big enough to hold st.st_size all over the code.  Would
> you recommend tackling that assumption as well?

Probably.  It's an off_t.

	-hpa

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[H. Peter Anvin]

H. Peter Anvin wrote:
> Junio C Hamano wrote:
> 
>>
>> HPA> This is just plain WRONG.  st.st_size is longer than long on many
>> HPA> architectures, including Linux/i386.
>>
>> HPA> The easiest way to deal with it is to #include <inttypes.h>, use %jd
>> HPA> and cast it to (intmax_t).  That is, however, a C99-ism.
>>
>> Actually the easiest way is to stop reporting the size.  Nobody
>> else in core GIT reports st.st_size in their error messages.
>>
>> Although I agree with you that what you say about the size of
>> st.st_size is correct, in GIT world view, apparently "unsigned
>> long" is big enough to hold st.st_size all over the code.  Would
>> you recommend tackling that assumption as well?
> 
> Probably.  It's an off_t.
> 

That being said, there are also a whole bunch of assumptions that any 
object can be memory-mapped *plus* fit uncompressed in memory... that's 
obviously not going to be the case for large files.

On the other hand, one has to start cleaning up somewhere...

	-hpa

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[Junio C Hamano]

>>>>> "HPA" == H Peter Anvin <hpa@zytor.com> writes:

HPA> That being said, there are also a whole bunch of assumptions that any
HPA> object can be memory-mapped *plus* fit uncompressed in
HPA> memory... that's obviously not going to be the case for large files.

HPA> On the other hand, one has to start cleaning up somewhere...

I agree to that, but on the other hand one also has to know
where to stop.  The primary purpose of GIT being to manage the
source files for the Linux kernel project, not worrying about
_huge_ files that would cause mmap+uncompressed or st.st_size
not fitting in unsigned long may just be fine.

Re: [PATCH] minor Makefile and local-pull.c edits for Darwin

[H. Peter Anvin]

Junio C Hamano wrote:
>>>>>>"HPA" == H Peter Anvin <hpa@zytor.com> writes:
> 
> 
> HPA> That being said, there are also a whole bunch of assumptions that any
> HPA> object can be memory-mapped *plus* fit uncompressed in
> HPA> memory... that's obviously not going to be the case for large files.
> 
> HPA> On the other hand, one has to start cleaning up somewhere...
> 
> I agree to that, but on the other hand one also has to know
> where to stop.  The primary purpose of GIT being to manage the
> source files for the Linux kernel project, not worrying about
> _huge_ files that would cause mmap+uncompressed or st.st_size
> not fitting in unsigned long may just be fine.
> 

Using the correct data types is a good start, though.

	-hpa