{"thread":{"id":"23664","subject":"new platform & S_IFGITLINK problem","startedAt":"2010-05-01T23:29:15Z","lastAt":"2010-08-02T16:26:40Z","messageCount":17,"participants":["Alan Hourihane","Junio C Hamano","Linus Torvalds","Andreas Ericsson","Jonathan Nieder","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"140717","messageId":"1272756555.13488.1314.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":null,"subject":"new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-05-01T23:29:15Z","receivedAt":"2010-05-01T23:29:15Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"Hello,\n\nJust joined as I'm compiling git on a new platform and wondered if\nsomeone can help solve a problem with the definition of S_IFGITLINK.\n\nOn my platform I have the following definitions....\n\n#define __S_IFSOCK      0010000 /* Socket.  */\n#define __S_IFCHR       0020000 /* Character device.  */\n#define __S_IFDIR       0040000 /* Directory.  */\n#define __S_IFBLK       0060000 /* Block device.  */\n#define __S_IFREG       0100000 /* Regular file.  */\n#define __S_IFIFO       0120000 /* FIFO.  */\n#define __S_IFMEM       0140000 /* memory region or process */\n#define __S_IFLNK       0160000 /* Symbolic link.  */\n\nYet, S_IFGITLINK in the git sources is defined as 0160000, so this\nclashes with my platform.\n\nThere is a comment about the definition of S_IFGITLINK in cache.h that\nit shouldn't be used like this and should use internal values.\n\nSo I'm wondering if this can be fixed to remove this assumption ?\n\nAdditionally, attached is a patch that I currently need to apply in\norder to compile git successfully on the FreeMiNT platform (which is\nm68k based).\n\nComments appreciated.\n\nThanks,\n\nAlan.\n\n\n--- git-compat-util.h\t2008-12-22 18:35:58.000000000 +0000\n+++ git-compat-util.h\t2008-12-22 18:39:21.000000000 +0000\n@@ -123,7 +123,9 @@\n #ifdef _MSC_VER\n #include \"compat/msvc.h\"\n #endif\n-\n+#ifdef __MINT__\n+#include \"compat/mint.h\"\n+#endif\n #ifndef NO_LIBGEN_H\n #include <libgen.h>\n #else\n--- /dev/null\t2008-12-07 20:01:52.000000000 +0000\n+++ compat/mint.h\t2008-12-23 11:52:10.000000000 +0000\n@@ -0,0 +1,2 @@\n+#define SA_RESTART 0\n+#define ss_family sa_family\n--- Makefile\t2009-01-29 12:12:01.000000000 +0000\n+++ Makefile\t2009-01-29 12:13:39.000000000 +0000\n@@ -1618,7 +1613,7 @@\n \n git-imap-send$X: imap-send.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n-\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)\n+\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n \n http.o http-walker.o http-push.o: http.h\n \n@@ -1626,10 +1621,10 @@\n \n git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n-\t\t$(LIBS) $(CURL_LIBCURL)\n+\t\t$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n-\t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n+\t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n \n $(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY)\n \t$(QUIET_LNCP)$(RM) $@ && \\\n@@ -1639,7 +1634,7 @@\n \n $(REMOTE_CURL_PRIMARY): remote-curl.o http.o http-walker.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n-\t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n+\t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n \n $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)\n $(patsubst git-%$X,%.o,$(PROGRAMS)) git.o: $(LIB_H) $(wildcard */*.h)\n"},{"id":"140719","messageId":"7vfx2b2ft5.fsf@alter.siamese.dyndns.org","threadId":"23664","inReplyTo":"1272756555.13488.1314.camel@jetpack.demon.co.uk","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-02T02:33:26Z","receivedAt":"2010-05-02T02:33:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Hourihane <alanh@fairlite.co.uk> writes:\n\n> Just joined as I'm compiling git on a new platform and wondered if\n> someone can help solve a problem with the definition of S_IFGITLINK.\n\nYikes.  The current codebase pretty much assumes that IFREG is 0100000,\nIFDIR 0040000, and IFLNK 0120000, and the bits read from \"struct stat\" and\nthe mode bits we store in the index and tree objects are interchangeable.\n\nYes, that assumption is a gross POSIX violation but we so far haven't seen\nany platform that matters in real life that assigns the IFMT bits\ndifferently.\n\nWe would need to:\n\n (1) rename S_IFGITLINK to GIT_S_IFMODULE;\n\n (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;\n\n (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n     read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n     values; and\n\n (4) change all the code that read mode from struct stat and use it to\n     first use MODE_SYSTEM_TO_GIT().\n\nCurrently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\nhits, so it is not infeasible amount of work, but it is not a trivial and\nmechanical replacement, either.  I or somebody need to set aside a block\nof time to do this clean-up and audit the result.\n\nThanks for a report.\n"},{"id":"140749","messageId":"1272793169.13488.1315.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"7vfx2b2ft5.fsf@alter.siamese.dyndns.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-05-02T09:39:29Z","receivedAt":"2010-05-02T09:39:29Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Sat, 2010-05-01 at 19:33 -0700, Junio C Hamano wrote:\n> Alan Hourihane <alanh@fairlite.co.uk> writes:\n> \n> > Just joined as I'm compiling git on a new platform and wondered if\n> > someone can help solve a problem with the definition of S_IFGITLINK.\n> \n> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,\n> IFDIR 0040000, and IFLNK 0120000, and the bits read from \"struct stat\" and\n> the mode bits we store in the index and tree objects are interchangeable.\n> \n> Yes, that assumption is a gross POSIX violation but we so far haven't seen\n> any platform that matters in real life that assigns the IFMT bits\n> differently.\n> \n> We would need to:\n> \n>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;\n> \n>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;\n> \n>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n>      read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n>      values; and\n> \n>  (4) change all the code that read mode from struct stat and use it to\n>      first use MODE_SYSTEM_TO_GIT().\n> \n> Currently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\n> hits, so it is not infeasible amount of work, but it is not a trivial and\n> mechanical replacement, either.  I or somebody need to set aside a block\n> of time to do this clean-up and audit the result.\n> \n> Thanks for a report.\n\nNo problem. Thanks for taking the challenge and sorting it out.\n\nLet me know if there's anywhere I can help, test, or debug.\n\nThanks again!\n\nAlan.\n"},{"id":"140881","messageId":"alpine.LFD.2.00.1005032035310.5478@i5.linux-foundation.org","threadId":"23664","inReplyTo":"7vfx2b2ft5.fsf@alter.siamese.dyndns.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-04T03:39:25Z","receivedAt":"2010-05-04T03:39:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 1 May 2010, Junio C Hamano wrote:\n> \n> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,\n> IFDIR 0040000, and IFLNK 0120000, and the bits read from \"struct stat\" and\n> the mode bits we store in the index and tree objects are interchangeable.\n\nYeah. This is painful. I knew it was wrong to just assume everything was \nsane and used the same traditional values, but I optimistically thought \nthat the st_mode bits were the _one_ thing that everybody agrees on.\n\nI was wrong. \n\n> Yes, that assumption is a gross POSIX violation but we so far haven't seen\n> any platform that matters in real life that assigns the IFMT bits\n> differently.\n\nIndeed. Just out of interest - Alan, what _is_ the crazy platform that \ndoesn't match what absolutely everybody else has always done?\n\n> We would need to:\n> \n>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;\n\nI'd suggest dropping the \"_S_\" part, and just calling it\n\n\tGIT_IFxyz\n\tGIT_ISxyz()\n\n>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;\n> \n>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n>      read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n>      values; and\n> \n>  (4) change all the code that read mode from struct stat and use it to\n>      first use MODE_SYSTEM_TO_GIT().\n> \n> Currently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\n> hits, so it is not infeasible amount of work, but it is not a trivial and\n> mechanical replacement, either.  I or somebody need to set aside a block\n> of time to do this clean-up and audit the result.\n\nUgh. And since nobody sane has different values from the system ones, if \nwe miss some case we'll never notice on any sane platform ;(\n\n\t\tLinus\n"},{"id":"140882","messageId":"alpine.LFD.2.00.1005032042470.5478@i5.linux-foundation.org","threadId":"23664","inReplyTo":"alpine.LFD.2.00.1005032035310.5478@i5.linux-foundation.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-04T03:52:31Z","receivedAt":"2010-05-04T03:52:31Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 May 2010, Linus Torvalds wrote:\n> On Sat, 1 May 2010, Junio C Hamano wrote:\n> > \n> >  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n> >      read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n> >      values; and\n> > \n> >  (4) change all the code that read mode from struct stat and use it to\n> >      first use MODE_SYSTEM_TO_GIT().\n> > \n> > Currently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\n> > hits, so it is not infeasible amount of work, but it is not a trivial and\n> > mechanical replacement, either.  I or somebody need to set aside a block\n> > of time to do this clean-up and audit the result.\n> \n> Ugh. And since nobody sane has different values from the system ones, if \n> we miss some case we'll never notice on any sane platform ;(\n\nAs to your (3) and (4), I actually think that the best option would be to \nstop using '[lf]stat()' directly for \"working tree stat\", and instead just \nintroduce a 'git_[lf]stat()' function that just always does the conversion \n(when necessary - the \"conversion\" can be a no-op on sane architectures) \nfor us.\n\nRight now, a _lot_ of the functions work either directly on 'st->st_mode' \n_or_ on random index entries, and that would be a major pain if they might \never be in \"different number domains\". So the easiest way to make sure \nthat we _always_ use the GIT_IFxyz numbers would be to never ever have \nanything that uses the native ones even by mistake.\n\nI've actually wanted to have a 'git_lstat()' wrapper for other reasons: it \nwould have made it _so_ much easier to do breakpoints etc when doing the \nwhole name lookup optimizations. \n\nNote: there are various cases of '[lf]stat()' being used not for working \ntree entries, but for things like the pack files etc internal git files. \nThose should _not_ do the conversion - they should use the \"native\" stat() \nfunctions. It's only the working tree accesses we should need to do any \nconversion on, since those are the ones that are relevant for the index \n(and tree) comparisons.\n\n\t\t\tLinus\n"},{"id":"140889","messageId":"4BDFBB18.70800@op5.se","threadId":"23664","inReplyTo":"alpine.LFD.2.00.1005032042470.5478@i5.linux-foundation.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-05-04T06:13:44Z","receivedAt":"2010-05-04T06:13:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 05/04/2010 05:52 AM, Linus Torvalds wrote:\n> \n> \n> On Mon, 3 May 2010, Linus Torvalds wrote:\n>> On Sat, 1 May 2010, Junio C Hamano wrote:\n>>>\n>>>   (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n>>>       read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n>>>       values; and\n>>>\n>>>   (4) change all the code that read mode from struct stat and use it to\n>>>       first use MODE_SYSTEM_TO_GIT().\n>>>\n>>> Currently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\n>>> hits, so it is not infeasible amount of work, but it is not a trivial and\n>>> mechanical replacement, either.  I or somebody need to set aside a block\n>>> of time to do this clean-up and audit the result.\n>>\n>> Ugh. And since nobody sane has different values from the system ones, if\n>> we miss some case we'll never notice on any sane platform ;(\n> \n> As to your (3) and (4), I actually think that the best option would be to\n> stop using '[lf]stat()' directly for \"working tree stat\", and instead just\n> introduce a 'git_[lf]stat()' function that just always does the conversion\n> (when necessary - the \"conversion\" can be a no-op on sane architectures)\n> for us.\n> \n> Right now, a _lot_ of the functions work either directly on 'st->st_mode'\n> _or_ on random index entries, and that would be a major pain if they might\n> ever be in \"different number domains\". So the easiest way to make sure\n> that we _always_ use the GIT_IFxyz numbers would be to never ever have\n> anything that uses the native ones even by mistake.\n> \n> I've actually wanted to have a 'git_lstat()' wrapper for other reasons: it\n> would have made it _so_ much easier to do breakpoints etc when doing the\n> whole name lookup optimizations.\n> \n> Note: there are various cases of '[lf]stat()' being used not for working\n> tree entries, but for things like the pack files etc internal git files.\n> Those should _not_ do the conversion - they should use the \"native\" stat()\n> functions. It's only the working tree accesses we should need to do any\n> conversion on, since those are the ones that are relevant for the index\n> (and tree) comparisons.\n> \n\nThere are other benefits to the git_[fl]stat as well. Windows people would\nprobably be delighted if they were introduced. We have them in libgit2 for\nthat precise reason, since stat() sucks arse but some fileGetInfo() call is\nat least reasonably fast on windows.\n\nSo why not make even pack file access work with the git macros? After all,\nthe conversion is a no-op on sane platforms, and it would probably be\neasier to review patches if one doesn't have to remember that we have two\nstat() implementations and which one to use where. Especially when we add\nutility functions like read_file_chunk() (no, it doesn't exist) that could\noperate on either internal files or work-tree files.\n\nIt would also make code-stealing to libgit2 a bit easier ;)\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"140892","messageId":"1272957697.13488.1319.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"alpine.LFD.2.00.1005032035310.5478@i5.linux-foundation.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-05-04T07:21:36Z","receivedAt":"2010-05-04T07:21:36Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Mon, 2010-05-03 at 20:39 -0700, Linus Torvalds wrote:\n> \n> On Sat, 1 May 2010, Junio C Hamano wrote:\n> > \n> > Yes, that assumption is a gross POSIX violation but we so far haven't seen\n> > any platform that matters in real life that assigns the IFMT bits\n> > differently.\n> \n> Indeed. Just out of interest - Alan, what _is_ the crazy platform that \n> doesn't match what absolutely everybody else has always done?\n\nYou don't want to know :-)\n\nBut if you really must, it's an Atari platforms running FreeMiNT, but\nwas also essentially Atari's own MultiTOS as well which they adopted\nfrom the original MiNT project.\n\nAlan.\n"},{"id":"140906","messageId":"alpine.LFD.2.00.1005040732310.5478@i5.linux-foundation.org","threadId":"23664","inReplyTo":"4BDFBB18.70800@op5.se","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2010-05-04T14:34:04Z","receivedAt":"2010-05-04T14:34:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 4 May 2010, Andreas Ericsson wrote:\n> \n> So why not make even pack file access work with the git macros?\n\nBecause I'm a sneaky bastard, and I have a long-term plan.\n\nThe whole filename character set conversion thing.\n\nSo having a git_[l]stat() macro - used only for working tree accesses - \nwould be one step in that direction. Doing it for git internal files would \ntotally screw that plan up.\n\n\t\tLinus\n"},{"id":"140910","messageId":"7vwrvjofbl.fsf@alter.siamese.dyndns.org","threadId":"23664","inReplyTo":"alpine.LFD.2.00.1005032042470.5478@i5.linux-foundation.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-05-04T15:29:50Z","receivedAt":"2010-05-04T15:29:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@linux-foundation.org> writes:\n\n> I've actually wanted to have a 'git_lstat()' wrapper for other reasons: it \n> would have made it _so_ much easier to do breakpoints etc when doing the \n> whole name lookup optimizations. \n\nYes, I would imagine that canonicalized utf-8, windows codepages and other\nscrew-ups can be dealt with easier with such a wrapper as well.\n"},{"id":"140956","messageId":"20100505022907.GA17743@progeny.tock","threadId":"23664","inReplyTo":"1272756555.13488.1314.camel@jetpack.demon.co.uk","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-05-05T02:29:08Z","receivedAt":"2010-05-05T02:29:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nAlan Hourihane wrote:\n\n> Additionally, attached is a patch that I currently need to apply in\n> order to compile git successfully on the FreeMiNT platform (which is\n> m68k based).\n> \n> Comments appreciated.\n\nWhile wiser people discuss the hard part, here are some tiny nitpicks. :)\n\n> --- /dev/null\t2008-12-07 20:01:52.000000000 +0000\n> +++ compat/mint.h\t2008-12-23 11:52:10.000000000 +0000\n> @@ -0,0 +1,2 @@\n> +#define SA_RESTART 0\n> +#define ss_family sa_family\n\nDoes MiNT restart interrupted system calls by default?  Are most\noperations generally not interruptible anyway?\n\n> --- Makefile\t2009-01-29 12:12:01.000000000 +0000\n> +++ Makefile\t2009-01-29 12:13:39.000000000 +0000\n> @@ -1618,7 +1613,7 @@\n>  \n>  git-imap-send$X: imap-send.o $(GITLIBS)\n>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n> -\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)\n> +\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n\nNEEDS_CRYPTO_WITH_SSL = YesPlease\n\n[...]\n>  git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)\n>  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n> -\t\t$(LIBS) $(CURL_LIBCURL)\n> +\t\t$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n[...]\n\nCURL_LIBCURL = -lcurl $(OPENSSL_LIBSSL)\n\nHope that helps,\nJonathan\n"},{"id":"140973","messageId":"1273048594.13488.1343.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"20100505022907.GA17743@progeny.tock","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-05-05T08:36:34Z","receivedAt":"2010-05-05T08:36:34Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Tue, 2010-05-04 at 21:29 -0500, Jonathan Nieder wrote:\n> Hi,\n> \n> Alan Hourihane wrote:\n> \n> > Additionally, attached is a patch that I currently need to apply in\n> > order to compile git successfully on the FreeMiNT platform (which is\n> > m68k based).\n> > \n> > Comments appreciated.\n> \n> While wiser people discuss the hard part, here are some tiny nitpicks. :)\n> \n> > --- /dev/null\t2008-12-07 20:01:52.000000000 +0000\n> > +++ compat/mint.h\t2008-12-23 11:52:10.000000000 +0000\n> > @@ -0,0 +1,2 @@\n> > +#define SA_RESTART 0\n> > +#define ss_family sa_family\n> \n> Does MiNT restart interrupted system calls by default?  Are most\n> operations generally not interruptible anyway?\n\nMost operations are generally not interruptible.\n\n> > --- Makefile\t2009-01-29 12:12:01.000000000 +0000\n> > +++ Makefile\t2009-01-29 12:13:39.000000000 +0000\n> > @@ -1618,7 +1613,7 @@\n> >  \n> >  git-imap-send$X: imap-send.o $(GITLIBS)\n> >  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n> > -\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)\n> > +\t\t$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n> \n> NEEDS_CRYPTO_WITH_SSL = YesPlease\n\nO.k.\n\n> [...]\n> >  git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)\n> >  \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n> > -\t\t$(LIBS) $(CURL_LIBCURL)\n> > +\t\t$(LIBS) $(CURL_LIBCURL) $(OPENSSL_LIBSSL) $(LIB_4_CRYPTO)\n> [...]\n> \n> CURL_LIBCURL = -lcurl $(OPENSSL_LIBSSL)\n\nO.k.\n\nAlan.\n"},{"id":"145998","messageId":"1279815812.7796.5499.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"7vfx2b2ft5.fsf@alter.siamese.dyndns.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-07-22T16:23:32Z","receivedAt":"2010-07-22T16:23:32Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Sat, 2010-05-01 at 19:33 -0700, Junio C Hamano wrote:\n> Alan Hourihane <alanh@fairlite.co.uk> writes:\n> \n> > Just joined as I'm compiling git on a new platform and wondered if\n> > someone can help solve a problem with the definition of S_IFGITLINK.\n> \n> Yikes.  The current codebase pretty much assumes that IFREG is 0100000,\n> IFDIR 0040000, and IFLNK 0120000, and the bits read from \"struct stat\" and\n> the mode bits we store in the index and tree objects are interchangeable.\n> \n> Yes, that assumption is a gross POSIX violation but we so far haven't seen\n> any platform that matters in real life that assigns the IFMT bits\n> differently.\n> \n> We would need to:\n> \n>  (1) rename S_IFGITLINK to GIT_S_IFMODULE;\n> \n>  (2) define GIT_S_IF{REG,DIR,LNK} as 0100000, 0040000, and 0120000;\n> \n>  (3) write MODE_SYSTEM_TO_GIT() macro to convert from S_IF{REG,DIR,LNK} we\n>      read from struct stat to the \"canonical\" GIT_S_IF{REG,DIR,LNK}\n>      values; and\n> \n>  (4) change all the code that read mode from struct stat and use it to\n>      first use MODE_SYSTEM_TO_GIT().\n> \n> Currently 'git grep -e \"S_IF[A-Z]\" -e \"struct stat\"' reports around 250\n> hits, so it is not infeasible amount of work, but it is not a trivial and\n> mechanical replacement, either.  I or somebody need to set aside a block\n> of time to do this clean-up and audit the result.\n> \n> Thanks for a report.\n\nHi Junio,\n\nIs there any ETA on fixing this up ?\n\nThanks,\n\nAlan.\n"},{"id":"146302","messageId":"7vwrsjcvx6.fsf@alter.siamese.dyndns.org","threadId":"23664","inReplyTo":"1279815812.7796.5499.camel@jetpack.demon.co.uk","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-25T17:29:09Z","receivedAt":"2010-07-25T17:29:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Hourihane <alanh@fairlite.co.uk> writes:\n\n> Is there any ETA on fixing this up ?\n\nI don't think so, as I didn't see anybody who has a testable system\nvolunteered to do this nor heard that somebody started doing it.\n"},{"id":"146312","messageId":"1280080833.3622.4772.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"7vwrsjcvx6.fsf@alter.siamese.dyndns.org","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-07-25T18:00:33Z","receivedAt":"2010-07-25T18:00:33Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:\n> Alan Hourihane <alanh@fairlite.co.uk> writes:\n> \n> > Is there any ETA on fixing this up ?\n> \n> I don't think so, as I didn't see anybody who has a testable system\n> volunteered to do this nor heard that somebody started doing it.\n\nO.k. Looks like I'll have to take it on over the long term.\n\nThanks,\n\nAlan.\n"},{"id":"146953","messageId":"AANLkTikcLk_W_guvBd3s15CY9xz6utmZASb67ndbt4=o@mail.gmail.com","threadId":"23664","inReplyTo":"1280080833.3622.4772.camel@jetpack.demon.co.uk","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-02T16:11:39Z","receivedAt":"2010-08-02T16:11:39Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:\n> On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:\n>> Alan Hourihane <alanh@fairlite.co.uk> writes:\n>>\n>> > Is there any ETA on fixing this up ?\n>>\n>> I don't think so, as I didn't see anybody who has a testable system\n>> volunteered to do this nor heard that somebody started doing it.\n>\n> O.k. Looks like I'll have to take it on over the long term.\n\nI've been adding smoke support to Git so that you could set up a cron\njob that automatically sent us failure reports on your platform. Then\nsomeone could fix this without your help.\n\nHere's the preliminary smoke patch:\n\n    http://github.com/avar/git/compare/git:pu...git-smoke-v2\n\nWould you be willing to run a smoker on FreeMiNT?\n"},{"id":"146954","messageId":"1280765681.15734.1202.camel@jetpack.demon.co.uk","threadId":"23664","inReplyTo":"AANLkTikcLk_W_guvBd3s15CY9xz6utmZASb67ndbt4=o@mail.gmail.com","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Alan Hourihane","fromEmail":"alanh@fairlite.co.uk","sentAt":"2010-08-02T16:14:41Z","receivedAt":"2010-08-02T16:14:41Z","isPatch":false,"sender":{"key":"alanh@fairlite.co.uk","avatar":null},"body":"On Mon, 2010-08-02 at 16:11 +0000, Ævar Arnfjörð Bjarmason wrote:\n> On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:\n> > On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:\n> >> Alan Hourihane <alanh@fairlite.co.uk> writes:\n> >>\n> >> > Is there any ETA on fixing this up ?\n> >>\n> >> I don't think so, as I didn't see anybody who has a testable system\n> >> volunteered to do this nor heard that somebody started doing it.\n> >\n> > O.k. Looks like I'll have to take it on over the long term.\n> \n> I've been adding smoke support to Git so that you could set up a cron\n> job that automatically sent us failure reports on your platform. Then\n> someone could fix this without your help.\n> \n> Here's the preliminary smoke patch:\n> \n>     http://github.com/avar/git/compare/git:pu...git-smoke-v2\n> \n> Would you be willing to run a smoker on FreeMiNT?\n\nSure. I'll give it a shot.\n\nAlan.\n"},{"id":"146955","messageId":"AANLkTim2X7w2dUrXXZUnXvYM8j-L2=O=Gn8a61ON=v=T@mail.gmail.com","threadId":"23664","inReplyTo":"1280765681.15734.1202.camel@jetpack.demon.co.uk","subject":"Re: new platform & S_IFGITLINK problem","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-02T16:26:40Z","receivedAt":"2010-08-02T16:26:40Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Aug 2, 2010 at 16:14, Alan Hourihane <alanh@fairlite.co.uk> wrote:\n> On Mon, 2010-08-02 at 16:11 +0000, Ęvar Arnfjörš Bjarmason wrote:\n>> On Sun, Jul 25, 2010 at 18:00, Alan Hourihane <alanh@fairlite.co.uk> wrote:\n>> > On Sun, 2010-07-25 at 10:29 -0700, Junio C Hamano wrote:\n>> >> Alan Hourihane <alanh@fairlite.co.uk> writes:\n>> >>\n>> >> > Is there any ETA on fixing this up ?\n>> >>\n>> >> I don't think so, as I didn't see anybody who has a testable system\n>> >> volunteered to do this nor heard that somebody started doing it.\n>> >\n>> > O.k. Looks like I'll have to take it on over the long term.\n>>\n>> I've been adding smoke support to Git so that you could set up a cron\n>> job that automatically sent us failure reports on your platform. Then\n>> someone could fix this without your help.\n>>\n>> Here's the preliminary smoke patch:\n>>\n>>     http://github.com/avar/git/compare/git:pu...git-smoke-v2\n>>\n>> Would you be willing to run a smoker on FreeMiNT?\n>\n> Sure. I'll give it a shot.\n\nIt'll be easier for you to wait until this gets merged into core and\nwe have some easy-to-setup scripts for starting smokers \"out of the box\".\n\nBut it's good to know that you're interested in running one.\n"}]}