{"thread":{"id":"14688","subject":"[PATCH] Modify mingw_main() workaround to avoid link errors","startedAt":"2008-07-26T09:41:44Z","lastAt":"2008-08-03T21:21:20Z","messageCount":21,"participants":["Steffen Prohaska","Johannes Schindelin","Rene Herman","Junio C Hamano","Johannes Sixt","Jan Hudec"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"85035","messageId":"1217065304-27815-1-git-send-email-prohaska@zib.de","threadId":"14688","inReplyTo":null,"subject":"[PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-26T09:41:44Z","receivedAt":"2008-07-26T09:41:44Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"With MinGW's\n\n gcc.exe (GCC) 3.4.5 (mingw special)\n GNU ld version 2.17.50 20060824\n\nthe old define caused link errors:\n\n git.o: In function `main':\n C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n collect2: ld returned 1 exit status\n\nThe modified define works.\n\nSigned-off-by: Steffen Prohaska \n---\n compat/mingw.h | 5 +++--\n 1 files changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/compat/mingw.h b/compat/mingw.h\nindex 290a9e6..a52e657 100644\n--- a/compat/mingw.h\n+++ b/compat/mingw.h\n@@ -228,9 +228,10 @@ char **env_setenv(char **env, const char *name);\n * A replacement of main() that ensures that argv[0] has a path\n */\n \n-#define main(c,v) main(int argc, const char **argv) \\\n+#define main(c,v) dummy_decl_mingw_main(); \\\n+static int mingw_main(); \\\n+int main(int argc, const char **argv) \\\n { \\\n-\tstatic int mingw_main(); \\\n \targv[0] = xstrdup(_pgmptr); \\\n \treturn mingw_main(argc, argv); \\\n } \\\n-- \n1.6.0.rc0.42.g186458\n"},{"id":"85056","messageId":"alpine.DEB.1.00.0807261515290.26810@eeepc-johanness","threadId":"14688","inReplyTo":"1217065304-27815-1-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T13:17:45Z","receivedAt":"2008-07-26T13:17:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 Jul 2008, Steffen Prohaska wrote:\n\n> -#define main(c,v) main(int argc, const char **argv) \\\n> +#define main(c,v) dummy_decl_mingw_main(); \\\n\nWhat is this dummy_*() statement supposed to do?\n\nNote that I still think it would be a better fix to refactor the \nlookup_prog() function from mingw.c.\n\nCiao,\nDscho\n"},{"id":"85058","messageId":"alpine.DEB.1.00.0807261613120.26810@eeepc-johanness","threadId":"14688","inReplyTo":"1217065304-27815-1-git-send-email-prohaska@zib.de","subject":"[PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T14:14:33Z","receivedAt":"2008-07-26T14:14:33Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen the program 'git' is in the PATH, the argv[0] is set to the basename.\nHowever, argv0_path needs the full path, so add a function to discover the\nprogram by traversing the PATH manually.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tSo it is not easily possible to reuse this function in \n\tcompat/mingw.c, as Junio said that compat/ should not depend\n\t(at least too much) on libgit.a.\n\n\tOf course, we could try to follow a symlinked git, too, but I \n\tthink this is overkill until someone proves me wrong.\n\n exec_cmd.c | 22 ++++++++++++++++++++++\n exec_cmd.h | 1 +\n git.c | 6 ++++++\n 3 files changed, 29 insertions(+), 0 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 0ed768d..048f3ca 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -125,3 +125,25 @@ int execl_git_cmd(const char *cmd,...)\n \targv[argc] = NULL;\n \treturn execv_git_cmd(argv);\n }\n+\n+char *lookup_program_in_path(const char *program)\n+{\n+\tstruct strbuf buf = STRBUF_INIT;\n+\tconst char *path = getenv(\"PATH\");\n+\n+\tif (!path || !*path)\n+\t\treturn NULL;\n+\n+\tfor (;;) {\n+\t\tconst char *colon = strchrnul(path, PATH_SEP);\n+\n+\t\tstrbuf_setlen(&buf, 0);\n+\t\tstrbuf_addf(&buf, \"%.*s/%s\",\n+\t\t\t\t(int)(colon - path), path, program);\n+\t\tif (!access(buf.buf, X_OK))\n+\t\t\treturn strbuf_detach(&buf, NULL);\n+\t\tif (!*colon)\n+\t\t\treturn NULL;\n+\t\tpath = colon + 1;\n+\t}\n+}\ndiff --git a/exec_cmd.h b/exec_cmd.h\nindex 0c46cd5..4548390 100644\n--- a/exec_cmd.h\n+++ b/exec_cmd.h\n@@ -8,5 +8,6 @@ extern void setup_path(void);\n extern int execv_git_cmd(const char **argv); /* NULL terminated */\n extern int execl_git_cmd(const char *cmd, ...);\n extern const char *system_path(const char *path);\n+extern char *lookup_program_in_path(const char *program);\n \n #endif /* GIT_EXEC_CMD_H */\ndiff --git a/git.c b/git.c\nindex 54c5bfa..0ec8ee1 100644\n--- a/git.c\n+++ b/git.c\n@@ -428,6 +428,12 @@ int main(int argc, const char **argv)\n \tdo\n \t\t--slash;\n \twhile (cmd <= slash && !is_dir_sep(*slash));\n+\tif (slash < cmd) {\n+\t\tcmd = lookup_program_in_path(cmd);\n+\t\tfor (slash = (char *)cmd + strlen(cmd) - 1;\n+\t\t\t\tcmd <= slash && !is_dir_sep(*slash); slash--)\n+\t\t\t; /* do nothing */\n+\t}\n \tif (cmd <= slash) {\n \t\t*slash++ = 0;\n \t\tgit_set_argv0_path(cmd);\n-- \n1.5.6.2.516.g22071\n"},{"id":"85065","messageId":"488B3A97.6000606@keyaccess.nl","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261613120.26810@eeepc-johanness","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-07-26T14:54:15Z","receivedAt":"2008-07-26T14:54:15Z","isPatch":true,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 26-07-08 16:14, Johannes Schindelin wrote:\n\n> When the program 'git' is in the PATH, the argv[0] is set to the\n> basename. However, argv0_path needs the full path, so add a function\n> to discover the program by traversing the PATH manually.\n\nWhile not having read the context for this, this ofcourse sounds like a \nhuge gaping race-condition. If applicable here (as said, did not read \ncontext) you generally want to make sure that there's no window that a \npath could be replaced -- while perhaps not here, that's often the kind \nof thing that security attacks end up abusing.\n\nRene.\n"},{"id":"85069","messageId":"alpine.DEB.1.00.0807261709090.26810@eeepc-johanness","threadId":"14688","inReplyTo":"488B3A97.6000606@keyaccess.nl","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T15:10:48Z","receivedAt":"2008-07-26T15:10:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 Jul 2008, Rene Herman wrote:\n\n> On 26-07-08 16:14, Johannes Schindelin wrote:\n> \n> > When the program 'git' is in the PATH, the argv[0] is set to the\n> > basename. However, argv0_path needs the full path, so add a function\n> > to discover the program by traversing the PATH manually.\n> \n> While not having read the context for this, this ofcourse sounds like a huge\n> gaping race-condition. If applicable here (as said, did not read context) you\n> generally want to make sure that there's no window that a path could be\n> replaced -- while perhaps not here, that's often the kind of thing that\n> security attacks end up abusing.\n\nYeah, and that's why you would carefully time your attack just in between \nthe command invocation and the discovery of argv[0] in the PATH.\n\nRather than replacing the 'git' program with an infected version right \naway.\n\nGiggling,\nDscho\n"},{"id":"85071","messageId":"488B409D.40709@keyaccess.nl","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261709090.26810@eeepc-johanness","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-07-26T15:19:57Z","receivedAt":"2008-07-26T15:19:57Z","isPatch":true,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 26-07-08 17:10, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 26 Jul 2008, Rene Herman wrote:\n> \n>> On 26-07-08 16:14, Johannes Schindelin wrote:\n>>\n>>> When the program 'git' is in the PATH, the argv[0] is set to the\n>>> basename. However, argv0_path needs the full path, so add a function\n>>> to discover the program by traversing the PATH manually.\n>> While not having read the context for this, this ofcourse sounds like a huge\n>> gaping race-condition. If applicable here (as said, did not read context) you\n>> generally want to make sure that there's no window that a path could be\n>> replaced -- while perhaps not here, that's often the kind of thing that\n>> security attacks end up abusing.\n> \n> Yeah, and that's why you would carefully time your attack just in between \n> the command invocation and the discovery of argv[0] in the PATH.\n> \n> Rather than replacing the 'git' program with an infected version right \n> away.\n\nAdding to the PATH is generally not disallowed by user level security. \nReplacing the GIT binary generally is.\n\nSure maybe it's not much of a problem here; as said, I didn't read the \ncontext and am not a GIT person. Just commented on a git-user list when \nthis was the next message on the list. Though a heads-up might still be \nin order. If it wasn't useful -- so be it, but even making a command do \nsomething different than a user expected can have serious implications, \nfor example in this case for the tree they are working on.\n\nRene.\n"},{"id":"85076","messageId":"alpine.DEB.1.00.0807261732500.26810@eeepc-johanness","threadId":"14688","inReplyTo":"488B409D.40709@keyaccess.nl","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T15:35:10Z","receivedAt":"2008-07-26T15:35:10Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 Jul 2008, Rene Herman wrote:\n\n> Adding to the PATH is generally not disallowed by user level security. \n> Replacing the GIT binary generally is.\n\nPrepending to the PATH is generally not disallowed either. And that's \njust as good as replacing the Git binary.\n\nThis issue is totally independent of Git. And it is totally bogus to \nthink about the complicated issues when the \"weakest link of the chain\" is \nmuch easier to exploit.\n\nHth,\nDscho\n"},{"id":"85082","messageId":"488B4868.4030405@keyaccess.nl","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261732500.26810@eeepc-johanness","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Rene Herman","fromEmail":"rene.herman@keyaccess.nl","sentAt":"2008-07-26T15:53:12Z","receivedAt":"2008-07-26T15:53:12Z","isPatch":true,"sender":{"key":"rene.herman@keyaccess.nl","avatar":null},"body":"On 26-07-08 17:35, Johannes Schindelin wrote:\n\n> And it is totally bogus to think about the complicated issues when\n> the \"weakest link of the chain\" is much easier to exploit.\n\n/me tips hat and unsubscribes again.\n\nRene.\n"},{"id":"85085","messageId":"65E5BA28-DAB0-4731-A6DA-DBE646367FBF@zib.de","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261515290.26810@eeepc-johanness","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-26T16:07:45Z","receivedAt":"2008-07-26T16:07:45Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 26, 2008, at 3:17 PM, Johannes Schindelin wrote:\n\n> On Sat, 26 Jul 2008, Steffen Prohaska wrote:\n>\n>> -#define main(c,v) main(int argc, const char **argv) \\\n>> +#define main(c,v) dummy_decl_mingw_main(); \\\n>\n> What is this dummy_*() statement supposed to do?\n\n\nAvoid compile errors. The original statement is\n\n int main( ...\n\nBut we want\n\n static int mingw_main( ...\n\nSo we need to first get rid of the original int, before\nwe can start the static decl. We get rid by completing\nthe original int with the dummy_decl_mingw_main(); to a\nfull function decl.\n\n\tSteffen\n"},{"id":"85097","messageId":"7vod4kft7d.fsf@gitster.siamese.dyndns.org","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261613120.26810@eeepc-johanness","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-26T17:31:18Z","receivedAt":"2008-07-26T17:31:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> When the program 'git' is in the PATH, the argv[0] is set to the basename.\n\nWhile it may be true, I do not think it matters that we cannot get the\nfull path _UNLESS_ we are doing the relative \"../\" business. \n\n> However, argv0_path needs the full path, so add a function to discover the\n> program by traversing the PATH manually.\n\nI think unconditionally requiring argv0_path to be set is the root cause\nof the bug. Unless we do not fix _that_, we will have to make a needless\ncall to lookup_program_in_path() even when nobody needs that information,\nwhich is unacceptable.\n"},{"id":"85098","messageId":"alpine.DEB.1.00.0807261940450.26810@eeepc-johanness","threadId":"14688","inReplyTo":"7vod4kft7d.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-07-26T17:42:36Z","receivedAt":"2008-07-26T17:42:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 26 Jul 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > However, argv0_path needs the full path, so add a function to discover \n> > the program by traversing the PATH manually.\n> \n> I think unconditionally requiring argv0_path to be set is the root cause \n> of the bug. Unless we do not fix _that_, we will have to make a \n> needless call to lookup_program_in_path() even when nobody needs that \n> information, which is unacceptable.\n\nFair enough. How about having a function called from system_path() which \nhas a flag so it is run only once, and then calls lookup_program_in_path() \nprovided that argv0_path contains no slashes _and_ exec_path is relative?\n\nCiao,\nDscho\n"},{"id":"85116","messageId":"1217104655.488b8b0f5ca48@webmail.nextra.at","threadId":"14688","inReplyTo":"1217065304-27815-1-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2008-07-26T20:37:35Z","receivedAt":"2008-07-26T20:37:35Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Zitat von Steffen Prohaska :\n> With MinGW's\n>\n> gcc.exe (GCC) 3.4.5 (mingw special)\n> GNU ld version 2.17.50 20060824\n>\n> the old define caused link errors:\n>\n> git.o: In function `main':\n> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n> collect2: ld returned 1 exit status\n>\n> The modified define works.\n\nI have the same tools, but not this error. ???\n\n-- Hannes\n"},{"id":"85118","messageId":"4CCD1862-48FB-412B-80B6-E1B822BF3A87@zib.de","threadId":"14688","inReplyTo":"1217104655.488b8b0f5ca48@webmail.nextra.at","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-26T21:36:47Z","receivedAt":"2008-07-26T21:36:47Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:\n\n> Zitat von Steffen Prohaska :\n>> With MinGW's\n>>\n>> gcc.exe (GCC) 3.4.5 (mingw special)\n>> GNU ld version 2.17.50 20060824\n>>\n>> the old define caused link errors:\n>>\n>> git.o: In function `main':\n>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n>> collect2: ld returned 1 exit status\n>>\n>> The modified define works.\n>\n> I have the same tools, but not this error. ???\n\nI cleaned my work tree and built several times but did not\nfind out what exactly is causing the error. So I came up\nwith the modified define, which declares the static\nmingw_main in global scope. I have no clue why I see the\nerror that you don't have.\n\n\tSteffen\n"},{"id":"85192","messageId":"1217186640.488ccb50a934a@webmail.nextra.at","threadId":"14688","inReplyTo":"4CCD1862-48FB-412B-80B6-E1B822BF3A87@zib.de","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2008-07-27T19:24:00Z","receivedAt":"2008-07-27T19:24:00Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Zitat von Steffen Prohaska :\n\n>\n> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:\n>\n> > Zitat von Steffen Prohaska :\n> >> With MinGW's\n> >>\n> >> gcc.exe (GCC) 3.4.5 (mingw special)\n> >> GNU ld version 2.17.50 20060824\n> >>\n> >> the old define caused link errors:\n> >>\n> >> git.o: In function `main':\n> >> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n> >> collect2: ld returned 1 exit status\n> >>\n> >> The modified define works.\n> >\n> > I have the same tools, but not this error. ???\n>\n> I cleaned my work tree and built several times but did not\n> find out what exactly is causing the error. So I came up\n> with the modified define, which declares the static\n> mingw_main in global scope. I have no clue why I see the\n> error that you don't have.\n\nNeither do I. But a strange line number you have there. In 01d9b2d (from\nmingw.git) I have 'exit(1)' in line 500 of git.c.\n\n-- Hannes\n"},{"id":"85396","messageId":"B6158330-640B-4CA3-8589-310FA8EA6CC9@zib.de","threadId":"14688","inReplyTo":"1217186640.488ccb50a934a@webmail.nextra.at","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-29T04:46:59Z","receivedAt":"2008-07-29T04:46:59Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:\n\n> Zitat von Steffen Prohaska :\n>\n>>\n>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:\n>>\n>>> Zitat von Steffen Prohaska :\n>>>> With MinGW's\n>>>>\n>>>> gcc.exe (GCC) 3.4.5 (mingw special)\n>>>> GNU ld version 2.17.50 20060824\n>>>>\n>>>> the old define caused link errors:\n>>>>\n>>>> git.o: In function `main':\n>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n>>>> collect2: ld returned 1 exit status\n>>>>\n>>>> The modified define works.\n>>>\n>>> I have the same tools, but not this error. ???\n>>\n>> I cleaned my work tree and built several times but did not\n>> find out what exactly is causing the error. So I came up\n>> with the modified define, which declares the static\n>> mingw_main in global scope. I have no clue why I see the\n>> error that you don't have.\n>\n> Neither do I. But a strange line number you have there. In 01d9b2d \n> (from\n> mingw.git) I have 'exit(1)' in line 500 of git.c.\n\nI have the same in line 500. I am still wondering what this could\nmean. But I do not yet now :-(\n\n\tSteffen\n"},{"id":"85432","messageId":"1217320426.488ed5ea47384@webmail.nextra.at","threadId":"14688","inReplyTo":"B6158330-640B-4CA3-8589-310FA8EA6CC9@zib.de","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2008-07-29T08:33:46Z","receivedAt":"2008-07-29T08:33:46Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Zitat von Steffen Prohaska :\n\n>\n> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:\n>\n> > Zitat von Steffen Prohaska :\n> >\n> >>\n> >> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:\n> >>\n> >>> Zitat von Steffen Prohaska :\n> >>>> With MinGW's\n> >>>>\n> >>>> gcc.exe (GCC) 3.4.5 (mingw special)\n> >>>> GNU ld version 2.17.50 20060824\n> >>>>\n> >>>> the old define caused link errors:\n> >>>>\n> >>>> git.o: In function `main':\n> >>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n> >>>> collect2: ld returned 1 exit status\n> >>>>\n> >>>> The modified define works.\n> >>>\n> >>> I have the same tools, but not this error. ???\n> >>\n> >> I cleaned my work tree and built several times but did not\n> >> find out what exactly is causing the error. So I came up\n> >> with the modified define, which declares the static\n> >> mingw_main in global scope. I have no clue why I see the\n> >> error that you don't have.\n> >\n> > Neither do I. But a strange line number you have there. In 01d9b2d\n> > (from\n> > mingw.git) I have 'exit(1)' in line 500 of git.c.\n>\n> I have the same in line 500. I am still wondering what this could\n> mean. But I do not yet now :-(\n\nCan you try 'make -k' and see whether you have a similar problem with the\nnon-builtins that have their own main()?\n\n-- Hannes\n"},{"id":"85509","messageId":"E8DB683F-209F-4D49-9BE4-7F8209C512F0@zib.de","threadId":"14688","inReplyTo":"1217320426.488ed5ea47384@webmail.nextra.at","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2008-07-29T19:46:36Z","receivedAt":"2008-07-29T19:46:36Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 29, 2008, at 10:33 AM, Johannes Sixt wrote:\n\n> Zitat von Steffen Prohaska :\n>\n>>\n>> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:\n>>\n>>> Zitat von Steffen Prohaska :\n>>>\n>>>>\n>>>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:\n>>>>\n>>>>> Zitat von Steffen Prohaska :\n>>>>>> With MinGW's\n>>>>>>\n>>>>>> gcc.exe (GCC) 3.4.5 (mingw special)\n>>>>>> GNU ld version 2.17.50 20060824\n>>>>>>\n>>>>>> the old define caused link errors:\n>>>>>>\n>>>>>> git.o: In function `main':\n>>>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n>>>>>> collect2: ld returned 1 exit status\n>>>>>>\n>>>>>> The modified define works.\n>>>>>\n>>>>> I have the same tools, but not this error. ???\n>>>>\n>>>> I cleaned my work tree and built several times but did not\n>>>> find out what exactly is causing the error. So I came up\n>>>> with the modified define, which declares the static\n>>>> mingw_main in global scope. I have no clue why I see the\n>>>> error that you don't have.\n>>>\n>>> Neither do I. But a strange line number you have there. In 01d9b2d\n>>> (from\n>>> mingw.git) I have 'exit(1)' in line 500 of git.c.\n>>\n>> I have the same in line 500. I am still wondering what this could\n>> mean. But I do not yet now :-(\n>\n> Can you try 'make -k' and see whether you have a similar problem \n> with the\n> non-builtins that have their own main()?\n\n\nWith your master 01d9b2d:\n\n$ make -k\n LINK git.exe\ngit.o: In function `main':\nC:/msysgit/git/git.c:500: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git.exe] Error 1\n LINK git-hash-object.exe\nhash-object.o: In function `main':\nC:/msysgit/git/hash-object.c:114: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-hash-object.exe] Error 1\n LINK git-index-pack.exe\nindex-pack.o: In function `main':\nC:/msysgit/git/index-pack.c:974: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-index-pack.exe] Error 1\n LINK git-merge-index.exe\nmerge-index.o: In function `main':\nC:/msysgit/git/merge-index.c:120: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-merge-index.exe] Error 1\n LINK git-merge-tree.exe\nmerge-tree.o: In function `main':\nC:/msysgit/git/merge-tree.c:346: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-merge-tree.exe] Error 1\n LINK git-mktag.exe\nmktag.o: In function `main':\nC:/msysgit/git/mktag.c:144: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-mktag.exe] Error 1\n LINK git-mktree.exe\nmktree.o: In function `main':\nC:/msysgit/git/strbuf.h:73: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-mktree.exe] Error 1\n LINK git-pack-redundant.exe\npack-redundant.o: In function `main':\nC:/msysgit/git/pack-redundant.c:181: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-pack-redundant.exe] Error 1\n LINK git-patch-id.exe\npatch-id.o: In function `main':\nC:/msysgit/git/patch-id.c:80: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-patch-id.exe] Error 1\n LINK git-receive-pack.exe\nreceive-pack.o: In function `main':\nC:/msysgit/git/receive-pack.c:386: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-receive-pack.exe] Error 1\n LINK git-show-index.exe\nshow-index.o: In function `main':\nC:/msysgit/git/show-index.c:64: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-show-index.exe] Error 1\n LINK git-unpack-file.exe\nunpack-file.o: In function `main':\nC:/msysgit/git/unpack-file.c:19: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-unpack-file.exe] Error 1\n LINK git-update-server-info.exe\nupdate-server-info.o: In function `main':\nC:/msysgit/git/update-server-info.c:20: undefined reference to \n`mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-update-server-info.exe] Error 1\n LINK git-upload-pack.exe\nupload-pack.o: In function `main':\nC:/msysgit/git/upload-pack.c:180: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-upload-pack.exe] Error 1\n LINK git-var.exe\nvar.o: In function `main':\nC:/msysgit/git/var.c:51: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [git-var.exe] Error 1\nmake: Target `all' not remade because of errors.\n SUBDIR git-gui\n SUBDIR gitk-git\nmake[1]: Nothing to be done for `all'.\n SUBDIR perl\nmkdir -p blib/lib\nrm -f blib/lib/Git.pm; cp Git.pm blib/lib/\nrm -f blib/lib/Error.pm\n SUBDIR templates\n LINK test-chmtime.exe\ntest-chmtime.o: In function `main':\nC:/msysgit/git/test-chmtime.c:50: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-chmtime.exe] Error 1\n LINK test-date.exe\ntest-date.o: In function `main':\nC:/msysgit/git/test-date.c:3: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-date.exe] Error 1\n LINK test-delta.exe\ntest-delta.o: In function `main':\nC:/msysgit/git/test-delta.c:67: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-delta.exe] Error 1\n LINK test-sha1.exe\ntest-sha1.o: In function `main':\nC:/msysgit/git/test-sha1.c:14: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-sha1.exe] Error 1\n LINK test-match-trees.exe\ntest-match-trees.o: In function `main':\nC:/msysgit/git/test-match-trees.c:23: undefined reference to \n`mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-match-trees.exe] Error 1\n LINK test-parse-options.exe\ntest-parse-options.o: In function `main':\nC:/msysgit/git/test-parse-options.c:21: undefined reference to \n`mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-parse-options.exe] Error 1\n LINK test-path-utils.exe\ntest-path-utils.o: In function `main':\nC:/msysgit/git/test-path-utils.c:8: undefined reference to `mingw_main'\ncollect2: ld returned 1 exit status\nmake: *** [test-path-utils.exe] Error 1\nmake: Target `all' not remade because of errors.\n\n\tSteffen\n"},{"id":"86095","messageId":"1217793328.48960d306d2b7@webmail.nextra.at","threadId":"14688","inReplyTo":"1217065304-27815-1-git-send-email-prohaska@zib.de","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Johannes Sixt","fromEmail":"johannes.sixt@telecom.at","sentAt":"2008-08-03T19:55:28Z","receivedAt":"2008-08-03T19:55:28Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Zitat von Steffen Prohaska :\n> With MinGW's\n>\n> gcc.exe (GCC) 3.4.5 (mingw special)\n> GNU ld version 2.17.50 20060824\n>\n> the old define caused link errors:\n>\n> git.o: In function `main':\n> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'\n> collect2: ld returned 1 exit status\n>\n> The modified define works.\n>\n> Signed-off-by: Steffen Prohaska \n\nAcked-by: Johannes Sixt \n\nI was not aware that my version (block-scoped static function forward\ndeclaration) is not valid C. Thanks, Björn, for pointing out the gcc bugzilla\nentries.\n\n-- Hannes\n\n> ---\n> compat/mingw.h | 5 +++--\n> 1 files changed, 3 insertions(+), 2 deletions(-)\n>\n> diff --git a/compat/mingw.h b/compat/mingw.h\n> index 290a9e6..a52e657 100644\n> --- a/compat/mingw.h\n> +++ b/compat/mingw.h\n> @@ -228,9 +228,10 @@ char **env_setenv(char **env, const char *name);\n> * A replacement of main() that ensures that argv[0] has a path\n> */\n>\n> -#define main(c,v) main(int argc, const char **argv) \\\n> +#define main(c,v) dummy_decl_mingw_main(); \\\n> +static int mingw_main(); \\\n> +int main(int argc, const char **argv) \\\n> { \\\n> -\tstatic int mingw_main(); \\\n> \targv[0] = xstrdup(_pgmptr); \\\n> \treturn mingw_main(argc, argv); \\\n> } \\\n> --\n> 1.6.0.rc0.42.g186458\n"},{"id":"86097","messageId":"20080803202513.GC3482@efreet.light.src","threadId":"14688","inReplyTo":"alpine.DEB.1.00.0807261613120.26810@eeepc-johanness","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2008-08-03T20:25:13Z","receivedAt":"2008-08-03T20:25:13Z","isPatch":true,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Jul 26, 2008 at 16:14:33 +0200, Johannes Schindelin wrote:\n> When the program 'git' is in the PATH, the argv[0] is set to the basename.\n> However, argv0_path needs the full path, so add a function to discover the\n> program by traversing the PATH manually.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> \n> \tSo it is not easily possible to reuse this function in \n> \tcompat/mingw.c, as Junio said that compat/ should not depend\n> \t(at least too much) on libgit.a.\n> \n> \tOf course, we could try to follow a symlinked git, too, but I \n> \tthink this is overkill until someone proves me wrong.\n\nOn UNIX, not only that argv[0] can contain the program without path -- it can\ncontain anything the user thinks of. However most systems provide some way to\nget the path of the executable. On Linux (and some other unices, but not all\nof them) a reliable way is to readlink(\"/proc/self/exe\", ...). Maybe since\nit's only needed for resolving a relative exec dir, relative exec dir could\nbe supported only on systems that have such method (which is most of them).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"86098","messageId":"7v3allvnhm.fsf@gitster.siamese.dyndns.org","threadId":"14688","inReplyTo":"20080803202513.GC3482@efreet.light.src","subject":"Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-03T20:43:01Z","receivedAt":"2008-08-03T20:43:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Hudec writes:\n\n> On UNIX, not only that argv[0] can contain the program without path -- it can\n> contain anything the user thinks of.... Maybe since\n> it's only needed for resolving a relative exec dir, relative exec dir could\n> be supported only on systems that have such method (which is most of them).\n\nThe \"relocatable install\" itself is not usually a common concept in the\nUNIX world, and I do not think this matters anyway.\n"},{"id":"86106","messageId":"7v3allu75b.fsf@gitster.siamese.dyndns.org","threadId":"14688","inReplyTo":"1217793328.48960d306d2b7@webmail.nextra.at","subject":"Re: [PATCH] Modify mingw_main() workaround to avoid link errors","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-03T21:21:20Z","receivedAt":"2008-08-03T21:21:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Zitat von Steffen Prohaska :\n> ...\n>> The modified define works.\n>>\n>> Signed-off-by: Steffen Prohaska \n>\n> Acked-by: Johannes Sixt \n>\n> I was not aware that my version (block-scoped static function forward\n> declaration) is not valid C. Thanks, Björn, for pointing out the gcc bugzilla\n> entries.\n\nThanks all. Applied.\n"}]}