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

Johannes Sixt [off-list ref] writes:

Ramsay Jones schrieb:

quoted

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.

Junio C Hamano wrote:

How does Cygwin-ness of the build environment affect the end result when
you build with MSVC?

Not at all. This is an MSVC/NO_MMAP combo problem. (The "problem" also exists
with the msvc build on msysGit[1])

                     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.

See patch #3.

Shouldn't this be solved by teaching the Makefile about this new "Cygwin
but using MSVC as compiler toolchain" combination?

Yes. Err... see patch #3 :-P

[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?

About as sane as running msysGit and still use MSVC as the compiler! :D

 Is it
commonly done?  I have no idea.

Nor me. I just tried it, and it works (after applying these patches!); for
exactly the same reason, and to the same extent, that it works on msysGit.

[Footnote]
*1* I admit to sometimes being a bit sloppy with naming (and maybe confused
also!). Now, IIUC, MinGW is basically gcc + binutils, MSYS is bash + some
unix tools and msysGit is MinGW + MSYS + some additional packages needed to
build and run git (eg perl). So, the "MinGW build" should really be called the
msysGit build ;-) (but the config section specifically picks out the MINGW string
from uname_S)
Also, the "msvc build on MinGW" should really be the "msvc build on msysGit".
Or something like that!

ATB,
Ramsay Jones

Ramsay Jones schrieb:

Junio C Hamano wrote:

quoted

Shouldn't this be solved by teaching the Makefile about this new "Cygwin
but using MSVC as compiler toolchain" combination?

Yes. Err... see patch #3 :-P

A clarifiction: Junio talks about using the MSVC tools to build Cygwin
programs, that is, to merely substitute Cygwin's gcc by MSVC, but to still
link against cygwin's C runtime.

But this is not what this series is about.

When the "MSVC build" of git is made, then the MSVC compiler is used, and
this will always use Microsoft libraries in the resulting executables,
regardless of whether "make MSVC=1" was called from a "cygwin environment"
or from and "msys environment".

This series is about fixing "make MSVC=1" when it is run from a "cygwin
environment" by disentangling the MSVC and Cygwin configuration sections
in the Makefile.

-- Hannes