{"thread":{"id":"21386","subject":"[PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","startedAt":"2009-10-27T19:03:36Z","lastAt":"2009-11-05T19:37:10Z","messageCount":8,"participants":["Ramsay Jones","Johannes Sixt","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":4},"messages":[{"id":"126054","messageId":"4AE74408.7080103@ramsay1.demon.co.uk","threadId":"21386","inReplyTo":null,"subject":"[PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-10-27T19:03:36Z","receivedAt":"2009-10-27T19:03:36Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nWhen the NO_MMAP build variable is set, which is the case by\ndefault on cygwin, the msvc linker complains:\n\n    error LNK2001: unresolved external symbol _getpagesize\n\nThe mingw build has a version of the getpagesize() function\ndefined in the libgcc.a library. In addition, this function\nis replaced, if USE_WIN32_MMAP is defined, by a version more\nsuitable for use with the native mmap.\n\nThe msvc libraries do not define any getpagesize() function,\nso we move the mingw_getpagesize() implementation from the\nconditionally built win32mmap.c file to mingw.c, which will\nalways be included in the MSVC build.\n\nSigned-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>\n---\n\nThis alone won't make the MSVC build work on cygwin; I have to\n\n    $ make MSVC=1 NEEDS_LIBICONV=\n\notherwise the linker complains about the absence of the iconv.lib.\n(I have downloaded the win32 version of the library, but I haven't\ngot around to installing it! see http://gnuwin32.sourceforge.net/\npackages/libiconv.htm)\n\nThe real problem, of course, is that the cygwin and MSVC configuration\nsections are not mutually exclusive. (see patch 3/4)\n\nATB,\nRamsay Jones\n\n compat/mingw.c     |   12 ++++++++++++\n compat/mingw.h     |    2 +-\n compat/win32mmap.c |   12 ------------\n 3 files changed, 13 insertions(+), 13 deletions(-)\n\ndiff --git a/compat/mingw.c b/compat/mingw.c\nindex 6b5b5b2..15fe33e 100644\n--- a/compat/mingw.c\n+++ b/compat/mingw.c\n@@ -1000,6 +1000,18 @@ repeat:\n \treturn -1;\n }\n \n+/*\n+ * Note that this doesn't return the actual pagesize, but\n+ * the allocation granularity. If future Windows specific git code\n+ * needs the real getpagesize function, we need to find another solution.\n+ */\n+int mingw_getpagesize(void)\n+{\n+\tSYSTEM_INFO si;\n+\tGetSystemInfo(&si);\n+\treturn si.dwAllocationGranularity;\n+}\n+\n struct passwd *getpwuid(int uid)\n {\n \tstatic char user_name[100];\ndiff --git a/compat/mingw.h b/compat/mingw.h\nindex 5b5258b..26c4027 100644\n--- a/compat/mingw.h\n+++ b/compat/mingw.h\n@@ -166,7 +166,7 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz);\n int mingw_rename(const char*, const char*);\n #define rename mingw_rename\n \n-#ifdef USE_WIN32_MMAP\n+#if defined(USE_WIN32_MMAP) || defined(_MSC_VER)\n int mingw_getpagesize(void);\n #define getpagesize mingw_getpagesize\n #endif\ndiff --git a/compat/win32mmap.c b/compat/win32mmap.c\nindex 779d796..1c5a149 100644\n--- a/compat/win32mmap.c\n+++ b/compat/win32mmap.c\n@@ -1,17 +1,5 @@\n #include \"../git-compat-util.h\"\n \n-/*\n- * Note that this doesn't return the actual pagesize, but\n- * the allocation granularity. If future Windows specific git code\n- * needs the real getpagesize function, we need to find another solution.\n- */\n-int mingw_getpagesize(void)\n-{\n-\tSYSTEM_INFO si;\n-\tGetSystemInfo(&si);\n-\treturn si.dwAllocationGranularity;\n-}\n-\n void *git_mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)\n {\n \tHANDLE hmap;\n-- \n1.6.5\n"},{"id":"126626","messageId":"4AEFD9E2.6060004@viscovery.net","threadId":"21386","inReplyTo":"4AE74408.7080103@ramsay1.demon.co.uk","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-03T07:21:06Z","receivedAt":"2009-11-03T07:21:06Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Ramsay Jones schrieb:\n> When the NO_MMAP build variable is set, which is the case by\n> default on cygwin, the msvc linker complains:\n> \n>     error LNK2001: unresolved external symbol _getpagesize\n\nMake up your mind: use the cygwin configuration or use the MSVC\nconfiguration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?\n\nI understand that you run into this error if you define NO_MMAP in your\nconfig.mak. I don't know whether we support NO_MMAP as a knob for to tweak\nthe builds on all platforms. If this is the case (Junio?), then your\njustification must be updated.\n\n-- Hannes\n"},{"id":"126633","messageId":"7veiogt4g8.fsf@alter.siamese.dyndns.org","threadId":"21386","inReplyTo":"4AEFD9E2.6060004@viscovery.net","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-03T08:09:27Z","receivedAt":"2009-11-03T08:09:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Ramsay Jones schrieb:\n>> When the NO_MMAP build variable is set, which is the case by\n>> default on cygwin, the msvc linker complains:\n>> \n>>     error LNK2001: unresolved external symbol _getpagesize\n>\n> Make up your mind: use the cygwin configuration or use the MSVC\n> configuration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?\n>\n> I understand that you run into this error if you define NO_MMAP in your\n> config.mak. I don't know whether we support NO_MMAP as a knob for to tweak\n> the builds on all platforms. If this is the case (Junio?), then your\n> justification must be updated.\n\nI don't _mind_ per-se if platform people add good support for building\nwith both using and not using mmap(), even though I do not see a strong\nneed for supporting NO_MMAP configuration, on a platform with a working\ngood-quality mmap(), either emulation or native.\n\nHow does Cygwin-ness of the build environment affect the end result when\nyou build with MSVC?  I am not a Windows person, so I am only guessing,\nbut I suspect that the result does not pull any library nor crt0 from what\npeople usually consider \"Cygwin environment\".  It feels that the \"default\nconfiguration of Cygwin\" that insists on NO_MMAP is the guilty party here.\n\nThe logic to set NO_MMAP on Cygwin obviously predates MSVC support, so it\nprobably was perfectly sane to say \"We are compiling on Cygwin, and by\ndefinition we use gcc to compile, link with the Cygwin libraries, and\nmmap() support there is weak and we are better off with NO_MMAP from\nperformance (or correctness) standpoint\".\n\nIf we are supporting use of MSVC as compiler toolchain on Cygwin, that\nstatement may no longer be true [*1*].\n\nShouldn't this be solved by teaching the Makefile about this new \"Cygwin\nbut using MSVC as compiler toolchain\" combination?  \"Even on Cygwin, if we\nare using MSVC, here are the compat layers we want to use and here are\nwhat the underlying C library and POSIX emulation layer gives us.\"\n\nSo it really boils down to this question.  Is there _anything_ in the end\nresult that should be affected by Cygwin-ness of the build environment\nwhen you build with MSVC?\n\nHere are what I see in the Cygwin section:\n\n        NO_D_TYPE_IN_DIRENT = YesPlease\n        NO_D_INO_IN_DIRENT = YesPlease\n        NO_STRCASESTR = YesPlease\n        NO_MEMMEM = YesPlease\n        NO_MKSTEMPS = YesPlease\n        NO_SYMLINK_HEAD = YesPlease\n        NEEDS_LIBICONV = YesPlease\n        NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes\n        NO_TRUSTABLE_FILEMODE = UnfortunatelyYes\n        OLD_ICONV = UnfortunatelyYes\n        NO_MMAP = YesPlease\n        NO_IPV6 = YesPlease\n\nThese all look very much like they depend on the way how C runtime library\nand the POSIX emulation layer are set up.  Perhaps these should be used\nonly when compiling with gcc and linking with glibc on Cygwin (which is\nthe norm)?\n\n\n[Footnote]\n\n*1* Notice \"if\" at the beginning of this sentence---I am not qualified to\nmake a judgement without help from area experts here.  Is it a sane thing\nto run Cygwin and still use MSVC as the compiler toolchain?  Is it\ncommonly done?  I have no idea.\n"},{"id":"126819","messageId":"4AF1D3A7.2070407@ramsay1.demon.co.uk","threadId":"21386","inReplyTo":"4AEFD9E2.6060004@viscovery.net","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-11-04T19:19:03Z","receivedAt":"2009-11-04T19:19:03Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Johannes Sixt wrote:\n> Ramsay Jones schrieb:\n>> When the NO_MMAP build variable is set, which is the case by\n>> default on cygwin, the msvc linker complains:\n>>\n>>     error LNK2001: unresolved external symbol _getpagesize\n> \n> Make up your mind: use the cygwin configuration or use the MSVC\n> configuration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?\n\nHeh, well as I said elsewhere in this email, the \"real problem\" is that the\nMSVC and cygwin configuration sections are not mutually exclusive and that\nis fixed in patch #3. So, if you apply patch #3, this \"problem\" disappears.\n\nHowever, ...\n\n> I understand that you run into this error if you define NO_MMAP in your\n> config.mak. I don't know whether we support NO_MMAP as a knob for to tweak\n> the builds on all platforms. If this is the case (Junio?), then your\n> justification must be updated.\n\nAFAICT, the only build to not support NO_MMAP is MSVC (on cygwin *or* msysGit).\nThe solution was obvious and low impact, so why not remove this anomaly?\n\n(It may even prove to be a useful capability ;-)\n\nATB,\nRamsay Jones\n"},{"id":"126823","messageId":"4AF1E1FD.1050102@ramsay1.demon.co.uk","threadId":"21386","inReplyTo":"7veiogt4g8.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsay1.demon.co.uk","sentAt":"2009-11-04T20:20:13Z","receivedAt":"2009-11-04T20:20:13Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Junio C Hamano wrote:\n> How does Cygwin-ness of the build environment affect the end result when\n> you build with MSVC?\n\nNot at all. This is an MSVC/NO_MMAP combo problem. (The \"problem\" also exists\nwith the msvc build on msysGit[1])\n\n>                      I am not a Windows person, so I am only guessing,\n> but I suspect that the result does not pull any library nor crt0 from what\n> people usually consider \"Cygwin environment\".  It feels that the \"default\n> configuration of Cygwin\" that insists on NO_MMAP is the guilty party here.\n> \n\nSee patch #3.\n\n> Shouldn't this be solved by teaching the Makefile about this new \"Cygwin\n> but using MSVC as compiler toolchain\" combination?\n\nYes. Err... see patch #3 :-P\n\n> [Footnote]\n> \n> *1* Notice \"if\" at the beginning of this sentence---I am not qualified to\n> make a judgement without help from area experts here.  Is it a sane thing\n> to run Cygwin and still use MSVC as the compiler toolchain?\n\nAbout as sane as running msysGit and still use MSVC as the compiler! :D\n\n>  Is it\n> commonly done?  I have no idea.\n> \n\nNor me. I just tried it, and it works (after applying these patches!); for\nexactly the same reason, and to the same extent, that it works on msysGit.\n\n[Footnote]\n*1* I admit to sometimes being a bit sloppy with naming (and maybe confused\nalso!). Now, IIUC, MinGW is basically gcc + binutils, MSYS is bash + some\nunix tools and msysGit is MinGW + MSYS + some additional packages needed to\nbuild and run git (eg perl). So, the \"MinGW build\" should really be called the\nmsysGit build ;-) (but the config section specifically picks out the MINGW string\nfrom uname_S)\nAlso, the \"msvc build on MinGW\" should really be the \"msvc build on msysGit\".\nOr something like that!\n\nATB,\nRamsay Jones\n"},{"id":"126883","messageId":"4AF2803A.6020108@viscovery.net","threadId":"21386","inReplyTo":"4AF1D3A7.2070407@ramsay1.demon.co.uk","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-05T07:35:22Z","receivedAt":"2009-11-05T07:35:22Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Ramsay Jones schrieb:\n> Johannes Sixt wrote:\n>> I understand that you run into this error if you define NO_MMAP in your\n>> config.mak. I don't know whether we support NO_MMAP as a knob for to tweak\n>> the builds on all platforms. If this is the case (Junio?), then your\n>> justification must be updated.\n> \n> AFAICT, the only build to not support NO_MMAP is MSVC (on cygwin *or* msysGit).\n> The solution was obvious and low impact, so why not remove this anomaly?\n\nSure, why not? But then the justification is different, as I said.\n\n-- Hannes\n"},{"id":"126887","messageId":"4AF284EF.2030606@viscovery.net","threadId":"21386","inReplyTo":"4AF1E1FD.1050102@ramsay1.demon.co.uk","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-05T07:55:27Z","receivedAt":"2009-11-05T07:55:27Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Ramsay Jones schrieb:\n> Junio C Hamano wrote:\n>> Shouldn't this be solved by teaching the Makefile about this new \"Cygwin\n>> but using MSVC as compiler toolchain\" combination?\n> \n> Yes. Err... see patch #3 :-P\n\nA clarifiction: Junio talks about using the MSVC tools to build Cygwin\nprograms, that is, to merely substitute Cygwin's gcc by MSVC, but to still\nlink against cygwin's C runtime.\n\nBut this is not what this series is about.\n\nWhen the \"MSVC build\" of git is made, then the MSVC compiler is used, and\nthis will always use Microsoft libraries in the resulting executables,\nregardless of whether \"make MSVC=1\" was called from a \"cygwin environment\"\nor from and \"msys environment\".\n\nThis series is about fixing \"make MSVC=1\" when it is run from a \"cygwin\nenvironment\" by disentangling the MSVC and Cygwin configuration sections\nin the Makefile.\n\n-- Hannes\n"},{"id":"126916","messageId":"7vhbt8ahll.fsf@alter.siamese.dyndns.org","threadId":"21386","inReplyTo":"4AF284EF.2030606@viscovery.net","subject":"Re: [PATCH 1/4] MSVC: Fix an \"unresolved symbol\" linker error on cygwin","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-05T19:37:10Z","receivedAt":"2009-11-05T19:37:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt <j.sixt@viscovery.net> writes:\n\n> Ramsay Jones schrieb:\n>> Junio C Hamano wrote:\n>>> Shouldn't this be solved by teaching the Makefile about this new \"Cygwin\n>>> but using MSVC as compiler toolchain\" combination?\n>> \n>> Yes. Err... see patch #3 :-P\n>\n> A clarifiction: Junio talks about using the MSVC tools to build Cygwin\n> programs, that is, to merely substitute Cygwin's gcc by MSVC, but to still\n> link against cygwin's C runtime.\n\nActually I do not talk about that; at least I meant to.\n\n> When the \"MSVC build\" of git is made, then the MSVC compiler is used, and\n> this will always use Microsoft libraries in the resulting executables,\n> regardless of whether \"make MSVC=1\" was called from a \"cygwin environment\"\n> or from and \"msys environment\".\n\n> This series is about fixing \"make MSVC=1\" when it is run from a \"cygwin\n> environment\" by disentangling the MSVC and Cygwin configuration sections\n> in the Makefile.\n\nYup.\n\nI think we all three are in agreement that \"When on Cygwin we do this\"\npart of the Makefile should be adjusted.  Even though I lost track of the\nexact text in \"patch #3\", I can tell from Ramsay's response that the\nseries is about that.\n"}]}