Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html