threads / discuss / 23664

new platform & S_IFGITLINK problem

Subject: new platform & S_IFGITLINK problem

## tl;dr

17 messages between May 1, 2010 and Aug 2, 2010.

replies: 16people: 6as markdown or json

Alan Hourihane· May 1, 2010, 23:29 UTC · lore
Hello,

Just joined as I'm compiling git on a new platform and wondered if someone can help solve a problem with the definition of S_IFGITLINK.

On my platform I have the following definitions....

#define __S_IFSOCK 0010000 /* Socket. */ #define __S_IFCHR 0020000 /* Character device. */ #define __S_IFDIR 0040000 /* Directory. */ #define __S_IFBLK 0060000 /* Block device. */ #define __S_IFREG 0100000 /* Regular file. */ #define __S_IFIFO 0120000 /* FIFO. */ #define __S_IFMEM 0140000 /* memory region or process */ #define __S_IFLNK 0160000 /* Symbolic link. */

Yet, S_IFGITLINK in the git sources is defined as 0160000, so this clashes with my platform.

There is a comment about the definition of S_IFGITLINK in cache.h that it shouldn't be used like this and should use internal values.

So I'm wondering if this can be fixed to remove this assumption ?

Additionally, attached is a patch that I currently need to apply in order to compile git successfully on the FreeMiNT platform (which is m68k based).

Comments appreciated.
Thanks,
Alan.

--- git-compat-util.h 2008-12-22 18:35:58.000000000 +0000 +++ git-compat-util.h 2008-12-22 18:39:21.000000000 +0000

@@ -123,7 +123,9 @@
 #ifdef _MSC_VER
 #include "compat/msvc.h"
 #endif
-
+#ifdef __MINT__
+#include "compat/mint.h"
+#endif
 #ifndef NO_LIBGEN_H
 #include <libgen.h>
 #else
--- /dev/null	2008-12-07 20:01:52.000000000 +0000
+++ compat/mint.h	2008-12-23 11:52:10.000000000 +0000
@@ -0,0 +1,2 @@
+#define SA_RESTART 0
+#define ss_family sa_family
--- Makefile	2009-01-29 12:12:01.000000000 +0000
+++ Makefile	2009-01-29 12:13:39.000000000 +0000
@@ -1618,7 +1613,7 @@
 
 git-imap-send$X: imap-send.o $(GITLIBS)
 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
-		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
+		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
 
 http.o http-walker.o http-push.o: http.h
 
@@ -1626,10 +1621,10 @@
 
 git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
-		$(LIBS) $(CURL_LIBCURL)
+		$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
 git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
-		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
 
 $(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY)
 	$(QUIET_LNCP)$(RM) $@ && \
@@ -1639,7 +1634,7 @@
 
 $(REMOTE_CURL_PRIMARY): remote-curl.o http.o http-walker.o $(GITLIBS)
 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
-		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
 
 $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
 $(patsubst git-%$X,%.o,$(PROGRAMS)) git.o: $(LIB_H) $(wildcard */*.h)
Junio C Hamano· May 2, 2010, 02:33 UTC · re: Alan Hourihane · lore

Re: new platform & S_IFGITLINK problem

Alan Hourihane <alanh@fairlite.co.uk> writes:
> Just joined as I'm compiling git on a new platform and wondered if
> someone can help solve a problem with the definition of S_IFGITLINK.

Yikes. The current codebase pretty much assumes that IFREG is 0100000, IFDIR 0040000, and IFLNK 0120000, and the bits read from "struct stat" and the mode bits we store in the index and tree objects are interchangeable.

Yes, that assumption is a gross POSIX violation but we so far haven't seen any platform that matters in real life that assigns the IFMT bits differently.

We would need to:
 (1) rename S_IFGITLINK to GIT_S_IFMODULE;
 (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;
 (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
     read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
     values; and
 (4) change all the code that read mode from struct stat and use it to
     first use MODE_SYSTEM_TO_GIT().

Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250 hits, so it is not infeasible amount of work, but it is not a trivial and mechanical replacement, either. I or somebody need to set aside a block of time to do this clean-up and audit the result.

Thanks for a report.
Alan Hourihane· May 2, 2010, 09:39 UTC · re: Junio C Hamano · lore

Re: new platform & S_IFGITLINK problem

On Sat, 2010-05-01 at 19:33 -0700, Junio C Hamano wrote:
Show 32 quoted lines
> Alan Hourihane <alanh@fairlite.co.uk> writes:
> 
> > Just joined as I'm compiling git on a new platform and wondered if
> > someone can help solve a problem with the definition of S_IFGITLINK.
> 
> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,
> IFDIR 0040000, and IFLNK 0120000, and the bits read from "struct stat" and
> the mode bits we store in the index and tree objects are interchangeable.
> 
> Yes, that assumption is a gross POSIX violation but we so far haven't seen
> any platform that matters in real life that assigns the IFMT bits
> differently.
> 
> We would need to:
> 
>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;
> 
>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;
> 
>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
>      read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
>      values; and
> 
>  (4) change all the code that read mode from struct stat and use it to
>      first use MODE_SYSTEM_TO_GIT().
> 
> Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250
> hits, so it is not infeasible amount of work, but it is not a trivial and
> mechanical replacement, either.  I or somebody need to set aside a block
> of time to do this clean-up and audit the result.
> 
> Thanks for a report.
No problem. Thanks for taking the challenge and sorting it out.
Let me know if there's anywhere I can help, test, or debug.
Thanks again!
Alan.
Linus Torvalds· May 4, 2010, 03:39 UTC · re: Junio C Hamano · lore

Re: new platform & S_IFGITLINK problem

On Sat, 1 May 2010, Junio C Hamano wrote:
> 
> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,
> IFDIR 0040000, and IFLNK 0120000, and the bits read from "struct stat" and
> the mode bits we store in the index and tree objects are interchangeable.

Yeah. This is painful. I knew it was wrong to just assume everything was sane and used the same traditional values, but I optimistically thought that the st_mode bits were the _one_ thing that everybody agrees on.

I was wrong. 
> Yes, that assumption is a gross POSIX violation but we so far haven't seen
> any platform that matters in real life that assigns the IFMT bits
> differently.

Indeed. Just out of interest - Alan, what _is_ the crazy platform that doesn't match what absolutely everybody else has always done?

> We would need to:
> 
>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;
I'd suggest dropping the "_S_" part, and just calling it
	GIT_IFxyz
	GIT_ISxyz()
Show 13 quoted lines
>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;
> 
>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
>      read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
>      values; and
> 
>  (4) change all the code that read mode from struct stat and use it to
>      first use MODE_SYSTEM_TO_GIT().
> 
> Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250
> hits, so it is not infeasible amount of work, but it is not a trivial and
> mechanical replacement, either.  I or somebody need to set aside a block
> of time to do this clean-up and audit the result.

Ugh. And since nobody sane has different values from the system ones, if we miss some case we'll never notice on any sane platform ;(

		Linus
Linus Torvalds· May 4, 2010, 03:52 UTC · re: Linus Torvalds · lore

Re: new platform & S_IFGITLINK problem

On Mon, 3 May 2010, Linus Torvalds wrote:
Show 16 quoted lines
> On Sat, 1 May 2010, Junio C Hamano wrote:
> > 
> >  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
> >      read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
> >      values; and
> > 
> >  (4) change all the code that read mode from struct stat and use it to
> >      first use MODE_SYSTEM_TO_GIT().
> > 
> > Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250
> > hits, so it is not infeasible amount of work, but it is not a trivial and
> > mechanical replacement, either.  I or somebody need to set aside a block
> > of time to do this clean-up and audit the result.
> 
> Ugh. And since nobody sane has different values from the system ones, if 
> we miss some case we'll never notice on any sane platform ;(

As to your (3) and (4), I actually think that the best option would be to stop using '[lf]stat()' directly for "working tree stat", and instead just introduce a 'git_[lf]stat()' function that just always does the conversion (when necessary - the "conversion" can be a no-op on sane architectures) for us.

Right now, a _lot_ of the functions work either directly on 'st->st_mode' _or_ on random index entries, and that would be a major pain if they might ever be in "different number domains". So the easiest way to make sure that we _always_ use the GIT_IFxyz numbers would be to never ever have anything that uses the native ones even by mistake.

I've actually wanted to have a 'git_lstat()' wrapper for other reasons: it would have made it _so_ much easier to do breakpoints etc when doing the whole name lookup optimizations. 

Note: there are various cases of '[lf]stat()' being used not for working 
tree entries, but for things like the pack files etc internal git files. 
Those should _not_ do the conversion - they should use the "native" stat() 
functions. It's only the working tree accesses we should need to do any 
conversion on, since those are the ones that are relevant for the index 
(and tree) comparisons.
			Linus
Andreas Ericsson· May 4, 2010, 06:13 UTC · re: Linus Torvalds · lore

Re: new platform & S_IFGITLINK problem

On 05/04/2010 05:52 AM, Linus Torvalds wrote:
Show 43 quoted lines
> 
> 
> On Mon, 3 May 2010, Linus Torvalds wrote:
>> On Sat, 1 May 2010, Junio C Hamano wrote:
>>>
>>>   (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
>>>       read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
>>>       values; and
>>>
>>>   (4) change all the code that read mode from struct stat and use it to
>>>       first use MODE_SYSTEM_TO_GIT().
>>>
>>> Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250
>>> hits, so it is not infeasible amount of work, but it is not a trivial and
>>> mechanical replacement, either.  I or somebody need to set aside a block
>>> of time to do this clean-up and audit the result.
>>
>> Ugh. And since nobody sane has different values from the system ones, if
>> we miss some case we'll never notice on any sane platform ;(
> 
> As to your (3) and (4), I actually think that the best option would be to
> stop using '[lf]stat()' directly for "working tree stat", and instead just
> introduce a 'git_[lf]stat()' function that just always does the conversion
> (when necessary - the "conversion" can be a no-op on sane architectures)
> for us.
> 
> Right now, a _lot_ of the functions work either directly on 'st->st_mode'
> _or_ on random index entries, and that would be a major pain if they might
> ever be in "different number domains". So the easiest way to make sure
> that we _always_ use the GIT_IFxyz numbers would be to never ever have
> anything that uses the native ones even by mistake.
> 
> I've actually wanted to have a 'git_lstat()' wrapper for other reasons: it
> would have made it _so_ much easier to do breakpoints etc when doing the
> whole name lookup optimizations.
> 
> Note: there are various cases of '[lf]stat()' being used not for working
> tree entries, but for things like the pack files etc internal git files.
> Those should _not_ do the conversion - they should use the "native" stat()
> functions. It's only the working tree accesses we should need to do any
> conversion on, since those are the ones that are relevant for the index
> (and tree) comparisons.
>

There are other benefits to the git_[fl]stat as well. Windows people would probably be delighted if they were introduced. We have them in libgit2 for that precise reason, since stat() sucks arse but some fileGetInfo() call is at least reasonably fast on windows.

So why not make even pack file access work with the git macros? After all, the conversion is a no-op on sane platforms, and it would probably be easier to review patches if one doesn't have to remember that we have two stat() implementations and which one to use where. Especially when we add utility functions like read_file_chunk() (no, it doesn't exist) that could operate on either internal files or work-tree files.

It would also make code-stealing to libgit2 a bit easier ;)
-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
Linus Torvalds· May 4, 2010, 14:34 UTC · re: Andreas Ericsson · lore

Re: new platform & S_IFGITLINK problem

On Tue, 4 May 2010, Andreas Ericsson wrote:
> 
> So why not make even pack file access work with the git macros?
Because I'm a sneaky bastard, and I have a long-term plan.
The whole filename character set conversion thing.

So having a git_[l]stat() macro - used only for working tree accesses - would be one step in that direction. Doing it for git internal files would totally screw that plan up.

		Linus
Junio C Hamano· May 4, 2010, 15:29 UTC · re: Linus Torvalds · lore

Re: new platform & S_IFGITLINK problem

Linus Torvalds <torvalds@linux-foundation.org> writes:
> I've actually wanted to have a 'git_lstat()' wrapper for other reasons: it 
> would have made it _so_ much easier to do breakpoints etc when doing the 
> whole name lookup optimizations.

Yes, I would imagine that canonicalized utf-8, windows codepages and other screw-ups can be dealt with easier with such a wrapper as well.

Alan Hourihane· May 4, 2010, 07:21 UTC · re: Linus Torvalds · lore

Re: new platform & S_IFGITLINK problem

On Mon, 2010-05-03 at 20:39 -0700, Linus Torvalds wrote:
Show 9 quoted lines
> 
> On Sat, 1 May 2010, Junio C Hamano wrote:
> > 
> > Yes, that assumption is a gross POSIX violation but we so far haven't seen
> > any platform that matters in real life that assigns the IFMT bits
> > differently.
> 
> Indeed. Just out of interest - Alan, what _is_ the crazy platform that 
> doesn't match what absolutely everybody else has always done?
You don't want to know :-)

But if you really must, it's an Atari platforms running FreeMiNT, but was also essentially Atari's own MultiTOS as well which they adopted from the original MiNT project.

Alan.
Alan Hourihane· Jul 22, 2010, 16:23 UTC · re: Junio C Hamano · lore

Re: new platform & S_IFGITLINK problem

On Sat, 2010-05-01 at 19:33 -0700, Junio C Hamano wrote:
Show 32 quoted lines
> Alan Hourihane <alanh@fairlite.co.uk> writes:
> 
> > Just joined as I'm compiling git on a new platform and wondered if
> > someone can help solve a problem with the definition of S_IFGITLINK.
> 
> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,
> IFDIR 0040000, and IFLNK 0120000, and the bits read from "struct stat" and
> the mode bits we store in the index and tree objects are interchangeable.
> 
> Yes, that assumption is a gross POSIX violation but we so far haven't seen
> any platform that matters in real life that assigns the IFMT bits
> differently.
> 
> We would need to:
> 
>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;
> 
>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;
> 
>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we
>      read from struct stat to the "canonical" GIT_S_IF{REG,DIR,LNK}
>      values; and
> 
>  (4) change all the code that read mode from struct stat and use it to
>      first use MODE_SYSTEM_TO_GIT().
> 
> Currently 'git grep -e "S_IF[A-Z]" -e "struct stat"' reports around 250
> hits, so it is not infeasible amount of work, but it is not a trivial and
> mechanical replacement, either.  I or somebody need to set aside a block
> of time to do this clean-up and audit the result.
> 
> Thanks for a report.
Hi Junio,
Is there any ETA on fixing this up ?
Thanks,
Alan.
Junio C Hamano· Jul 25, 2010, 17:29 UTC · re: Alan Hourihane · lore

Re: new platform & S_IFGITLINK problem

Alan Hourihane <alanh@fairlite.co.uk> writes:
> Is there any ETA on fixing this up ?

I don't think so, as I didn't see anybody who has a testable system volunteered to do this nor heard that somebody started doing it.

Alan Hourihane· Jul 25, 2010, 18:00 UTC · re: Junio C Hamano · lore

Re: new platform & S_IFGITLINK problem

On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:
Show 6 quoted lines
> Alan Hourihane <alanh@fairlite.co.uk> writes:
> 
> > Is there any ETA on fixing this up ?
> 
> I don't think so, as I didn't see anybody who has a testable system
> volunteered to do this nor heard that somebody started doing it.
O.k. Looks like I'll have to take it on over the long term.
Thanks,
Alan.
Ævar Arnfjörð Bjarmason· Aug 2, 2010, 16:11 UTC · re: Alan Hourihane · lore

Re: new platform & S_IFGITLINK problem

On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:
Show 9 quoted lines
> On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:
>> Alan Hourihane <alanh@fairlite.co.uk> writes:
>>
>> > Is there any ETA on fixing this up ?
>>
>> I don't think so, as I didn't see anybody who has a testable system
>> volunteered to do this nor heard that somebody started doing it.
>
> O.k. Looks like I'll have to take it on over the long term.

I've been adding smoke support to Git so that you could set up a cron job that automatically sent us failure reports on your platform. Then someone could fix this without your help.

Here's the preliminary smoke patch:
    http://github.com/avar/git/compare/git:pu...git-smoke-v2
Would you be willing to run a smoker on FreeMiNT?
Alan Hourihane· Aug 2, 2010, 16:14 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: new platform & S_IFGITLINK problem

On Mon, 2010-08-02 at 16:11 +0000, Ævar Arnfjörð Bjarmason wrote:
Show 20 quoted lines
> On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:
> > On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:
> >> Alan Hourihane <alanh@fairlite.co.uk> writes:
> >>
> >> > Is there any ETA on fixing this up ?
> >>
> >> I don't think so, as I didn't see anybody who has a testable system
> >> volunteered to do this nor heard that somebody started doing it.
> >
> > O.k. Looks like I'll have to take it on over the long term.
> 
> I've been adding smoke support to Git so that you could set up a cron
> job that automatically sent us failure reports on your platform. Then
> someone could fix this without your help.
> 
> Here's the preliminary smoke patch:
> 
>     http://github.com/avar/git/compare/git:pu...git-smoke-v2
> 
> Would you be willing to run a smoker on FreeMiNT?
Sure. I'll give it a shot.
Alan.
Ævar Arnfjörð Bjarmason· Aug 2, 2010, 16:26 UTC · re: Alan Hourihane · lore

Re: new platform & S_IFGITLINK problem

On Mon, Aug 2, 2010 at 16:14, Alan Hourihane <alanh@fairlite.co.uk> wrote:
Show 23 quoted lines
> On Mon, 2010-08-02 at 16:11 +0000, Ęvar Arnfjörš Bjarmason wrote:
>> On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:
>> > On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:
>> >> Alan Hourihane <alanh@fairlite.co.uk> writes:
>> >>
>> >> > Is there any ETA on fixing this up ?
>> >>
>> >> I don't think so, as I didn't see anybody who has a testable system
>> >> volunteered to do this nor heard that somebody started doing it.
>> >
>> > O.k. Looks like I'll have to take it on over the long term.
>>
>> I've been adding smoke support to Git so that you could set up a cron
>> job that automatically sent us failure reports on your platform. Then
>> someone could fix this without your help.
>>
>> Here's the preliminary smoke patch:
>>
>>     http://github.com/avar/git/compare/git:pu...git-smoke-v2
>>
>> Would you be willing to run a smoker on FreeMiNT?
>
> Sure. I'll give it a shot.

It'll be easier for you to wait until this gets merged into core and we have some easy-to-setup scripts for starting smokers "out of the box".

But it's good to know that you're interested in running one.
Jonathan Nieder· May 5, 2010, 02:29 UTC · re: Alan Hourihane · lore

Re: new platform & S_IFGITLINK problem

Hi,
Alan Hourihane wrote:
Show 5 quoted lines
> Additionally, attached is a patch that I currently need to apply in
> order to compile git successfully on the FreeMiNT platform (which is
> m68k based).
> 
> Comments appreciated.
While wiser people discuss the hard part, here are some tiny nitpicks. :)
Show 5 quoted lines
> --- /dev/null	2008-12-07 20:01:52.000000000 +0000
> +++ compat/mint.h	2008-12-23 11:52:10.000000000 +0000
> @@ -0,0 +1,2 @@
> +#define SA_RESTART 0
> +#define ss_family sa_family

Does MiNT restart interrupted system calls by default? Are most operations generally not interruptible anyway?

Show 8 quoted lines
> --- Makefile	2009-01-29 12:12:01.000000000 +0000
> +++ Makefile	2009-01-29 12:13:39.000000000 +0000
> @@ -1618,7 +1613,7 @@
>  
>  git-imap-send$X: imap-send.o $(GITLIBS)
>  	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> -		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
> +		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
NEEDS_CRYPTO_WITH_SSL = YesPlease
[...]
>  git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
>  	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> -		$(LIBS) $(CURL_LIBCURL)
> +		$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
[...]
CURL_LIBCURL = -lcurl $(OPENSSL_LIBSSL)

Hope that helps, Jonathan

Alan Hourihane· May 5, 2010, 08:36 UTC · re: Jonathan Nieder · lore

Re: new platform & S_IFGITLINK problem

On Tue, 2010-05-04 at 21:29 -0500, Jonathan Nieder wrote:
Show 20 quoted lines
> Hi,
> 
> Alan Hourihane wrote:
> 
> > Additionally, attached is a patch that I currently need to apply in
> > order to compile git successfully on the FreeMiNT platform (which is
> > m68k based).
> > 
> > Comments appreciated.
> 
> While wiser people discuss the hard part, here are some tiny nitpicks. :)
> 
> > --- /dev/null	2008-12-07 20:01:52.000000000 +0000
> > +++ compat/mint.h	2008-12-23 11:52:10.000000000 +0000
> > @@ -0,0 +1,2 @@
> > +#define SA_RESTART 0
> > +#define ss_family sa_family
> 
> Does MiNT restart interrupted system calls by default?  Are most
> operations generally not interruptible anyway?
Most operations are generally not interruptible.
Show 10 quoted lines
> > --- Makefile	2009-01-29 12:12:01.000000000 +0000
> > +++ Makefile	2009-01-29 12:13:39.000000000 +0000
> > @@ -1618,7 +1613,7 @@
> >  
> >  git-imap-send$X: imap-send.o $(GITLIBS)
> >  	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > -		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
> > +		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
> 
> NEEDS_CRYPTO_WITH_SSL = YesPlease
O.k.
Show 8 quoted lines
> [...]
> >  git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
> >  	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
> > -		$(LIBS) $(CURL_LIBCURL)
> > +		$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)
> [...]
> 
> CURL_LIBCURL = -lcurl $(OPENSSL_LIBSSL)
O.k.
Alan.

← back to recent threads