Re: [PATCH 1/4] MSVC: Fix an "unresolved symbol" linker error on cygwin

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 3, 2009, 08:09 UTC
Message-ID: <7veiogt4g8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4AEFD9E2.6060004@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 13 quoted lines

> Ramsay Jones schrieb:
>> When the NO_MMAP build variable is set, which is the case by
>> default on cygwin, the msvc linker complains:
>> 
>>     error LNK2001: unresolved external symbol _getpagesize
>
> Make up your mind: use the cygwin configuration or use the MSVC
> configuration. MSVC doesn't define NO_MMAP for a reason. Where is the problem?
>
> I understand that you run into this error if you define NO_MMAP in your
> config.mak. I don't know whether we support NO_MMAP as a knob for to tweak
> the builds on all platforms. If this is the case (Junio?), then your
> justification must be updated.

I don't _mind_ per-se if platform people add good support for building with both using and not using mmap(), even though I do not see a strong need for supporting NO_MMAP configuration, on a platform with a working good-quality mmap(), either emulation or native.

How does Cygwin-ness of the build environment affect the end result when you build with MSVC? I am not a Windows person, so I am only guessing, but I suspect that the result does not pull any library nor crt0 from what people usually consider "Cygwin environment". It feels that the "default configuration of Cygwin" that insists on NO_MMAP is the guilty party here.

The logic to set NO_MMAP on Cygwin obviously predates MSVC support, so it probably was perfectly sane to say "We are compiling on Cygwin, and by definition we use gcc to compile, link with the Cygwin libraries, and mmap() support there is weak and we are better off with NO_MMAP from performance (or correctness) standpoint".

If we are supporting use of MSVC as compiler toolchain on Cygwin, that statement may no longer be true [*1*].

Shouldn't this be solved by teaching the Makefile about this new "Cygwin but using MSVC as compiler toolchain" combination? "Even on Cygwin, if we are using MSVC, here are the compat layers we want to use and here are what the underlying C library and POSIX emulation layer gives us."

So it really boils down to this question. Is there _anything_ in the end result that should be affected by Cygwin-ness of the build environment when you build with MSVC?

Here are what I see in the Cygwin section:

        NO_D_TYPE_IN_DIRENT = YesPlease
        NO_D_INO_IN_DIRENT = YesPlease
        NO_STRCASESTR = YesPlease
        NO_MEMMEM = YesPlease
        NO_MKSTEMPS = YesPlease
        NO_SYMLINK_HEAD = YesPlease
        NEEDS_LIBICONV = YesPlease
        NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
        NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
        OLD_ICONV = UnfortunatelyYes
        NO_MMAP = YesPlease
        NO_IPV6 = YesPlease

These all look very much like they depend on the way how C runtime library and the POSIX emulation layer are set up. Perhaps these should be used only when compiling with gcc and linking with glibc on Cygwin (which is the norm)?

[Footnote]

*1* Notice "if" at the beginning of this sentence---I am not qualified to make a judgement without help from area experts here. Is it a sane thing to run Cygwin and still use MSVC as the compiler toolchain? Is it commonly done? I have no idea.