threads / patch / 556

patchminor Makefile and local-pull.c edits for Darwin

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

## tl;dr

9 messages between May 10, 2005 and May 10, 2005. Diffs are folded; open one to read it.

replies: 8people: 4as markdown or json

Mark Allen· May 10, 2005, 02:11 UTC · lore

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>
Show changes to diff +6 −2
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;
Daniel Barkalow· May 10, 2005, 04:23 UTC · re: Mark Allen · lore

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

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*
Junio C Hamano· May 10, 2005, 06:37 UTC · re: Daniel Barkalow · lore

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

>>>>> "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

Show changes to Makefile +1 −1
--- 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
H. Peter Anvin· May 10, 2005, 04:30 UTC · re: Mark Allen · lore

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

Mark Allen wrote:
Show 14 quoted lines
>  
> 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
Junio C Hamano· May 10, 2005, 06:44 UTC · re: H. Peter Anvin · lore

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

>>>>> "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?

H. Peter Anvin· May 10, 2005, 14:43 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 14 quoted lines
> 
> 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
H. Peter Anvin· May 10, 2005, 14:52 UTC · re: H. Peter Anvin · lore

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

H. Peter Anvin wrote:
Show 19 quoted lines
> 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
Junio C Hamano· May 10, 2005, 21:05 UTC · re: H. Peter Anvin · lore

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

>>>>> "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.

H. Peter Anvin· May 10, 2005, 21:12 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 15 quoted lines
>>>>>>"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

← back to recent threads