Re: [patch #6448] [MSVC 7/7] Add MSVC Support

[Peter Rosin]

Not sure if I should drag this further along...

Den 2008-08-29 08:00, skrev Duft Markus:
> > Den 2008-08-26 13:53, skrev Peter Rosin:
> > > Charles Wilson skrev:
> > > > I also think that -winnt is too broad; and I'd really hate to see
> > the
> > > > massive uglification of the libtool code -- and thousands of
> > > > configure.ac's out there -- that would ensue if -mingw* were
> > > > /officially/ overloaded to also represent the msvc-toolchain case.
> > > Thanks a bunch for that. Where specifically is this "massive
> > > uglification" in the pr-msvc-support branch?
> > Ok, I ended up spending the evening doing an experiment: I grabbed
> > a package at random, it happened to be libsndfile, and made it build
> > with MSVC (I selected it before I had a look at the code, I only
> > checked if it was using libtool, v1.5.22, so I updated it to
> > pr-msvc-support + patches waiting for review). The problems I
> > encountered were:
> >
> > * snprintf is spelled _snprintf (worked around elsewhere, code
> >    has apparently been ported at some point, but suffered a bit
> >    of bitrot)
> > * inline is spelled __inline (added AC_C_INLINE)
> > * cl does understand -c -o (added AM_PROG_CC_C_O)

Ooops, should of course be "does not".

> > * MSVC does not have unistd.h (commented it out a few times,
> >    found #if HAVE_UNISTD_H elsewhere in the code...)
> > * truncate() definition ifdeffed away (_WIN32 spelling bad, the
> >    code had #ifdef __WIN32, typo?)
> > * MSVC does not have the __func__ macro (defined it to "").
>
> I assume __func__ contains the current function name? If yes, those are
> the closest matches from MSDN:
>
> __FUNCDNAME__
>  Valid only within a function and returns the decorated name of the
> enclosing function (as a string). __FUNCDNAME__ is not expanded if you
> use the /EP or /P compiler option.
>  
> __FUNCSIG__
>  Valid only within a function and returns the signature of the enclosing
> function (as a string). __FUNCSIG__ is not expanded if you use the /EP
> or /P compiler option.
> On a 64-bit operating system, the calling convention is __cdecl by
> default.
>  
> __FUNCTION__
>  Valid only within a function and returns the undecorated name of the
> enclosing function (as a string). __FUNCTION__ is not expanded if you
> use the /EP or /P compiler option.

Ok, on a first glance those seem like better matches than "" :-)

> > etc
> >
> > I.e. small stuff that affects the code, not the build system,
> > and $host has no bearing whatsoever.
> >
> > Then there are two things which seem connected to $host mingw*
> > that would be the source of the "massive uglification" in the
> > build files.
> >
> > 1) libsndfile seems to want to kill signed/unsigned warnings
> > caused by sizeof, by defining a SIGNED_SIZEOF macro, the contents
> > of this macro is hardcoded when $host is mingw*, and the
> > definition is bad for MSVC (it uses int64_t).
>
> You're lucky that there is only one such small thing. I saw packages
> hardcoding _lots_ of things based on $host.

The question here is if you see "thousands" of packages with
"massive" amounts of such hardcoding. It is also a question if the
maintainers of those packages are indeed going to bother about MSVC
at all, no matter exactly what changes are required to the build
system. Since MSVC is so ignorant of standards it will probably be
ignored by many. Maintainers just don't want the uglification in
the code, and my guess is that any uglification in the build system
is minor in comparison to the crap needed to get the code to
compile at all.

> > 2) the ordinals in the built dll doesn't pass the testsuite
> > (but they don't do that with mingw-gcc either, perhaps because
> > I built out of tree? I had to do some tweeks to make that
> > work, maybe I missed something...). libsndfile passes the .def
> > file directly to the linker using -Wl, when it is using gcc.
>
> Assuming that the compiler/linker understands certain options based on
> $host is seen quite often. Especially with mingw, since mingw is the
> name of a _compiler_. Can't you see, that mingw32 is the compiler?

For the packages that I regularly use (and the reason for my libtool
work), the things that are common between MinGW and MSVC outnumber
the differences (if you talk about build system issues where $host
matters, the actual code is something else...).

That's my reason for sticking to mingw*, I also realize that it might
not be the best thing to do. I'm open to change, but I need arguments
that hold.

>  Maybe
> you use msys as your environment, yes, but mingw is not involved at all
> in you compilations...

Of course MinGW is not involved, that's the whole point.

>  How can you expect users to _not_ be confused
> when they think of mingw and get cl.exe?

Err, they just don't "get" MSVC imposed on them, they also have to
say CC=cl etc etc.

> Calling your host ming32 feels
> just really really wrong, since your port has absolutely nothing (and
> really _nothing_ to do with mingw.

Except that they both use the Microsoft libc's. And that they are
compatible. When I first wrote the dang thing, I was still using
MSVC 6 so the sameness was even more true than it is with
contemporary versions. It's not my fault that mingw32 is such a poor
name for the os part of $host, and it's not my fault that it has
taken so long for my patches to go in (no, not blaming anybody, but
it's definitely not my fault, oh wait, it is my fault, I could have
done more work to get 2.0 out the door, so I'm sorry and I'll take
it back, but then the champagne for the 2.2 release would not have
tasted as good, so I guess I'm not sorry after all).

>  What if somebody uses your port on,
> say, interix or cygwin? He doesn't necessarily need to know about mingw
> at all!

It's currently not possible to not use MSYS with pr-msvc-support,
since neither Interix nor Cygwin translates filenames on the
command line from Posix style to Win32 style (automatically, that
is). But if libtool could be made to use cygpath etc, *everywhere*
it's needed, I suspect it would be as any other cross compile,
with all problems and shortcomings involved with that.

How do you use MinGW from Interix? To minimize surprices I suspect
you do it as you do it on any *nix, i.e. as a cross compiler. How
do you use MinGW from Cygwin? Soon you will do it as you do on any
*nix (the -mno-cygwin confusion is on its way out), i.e. as a
cross compiler. How do you use MSVC from Interix/Cygwin? MSVC is
not available as a cross compiler, so you will have to jump thorugh
hoops to make it work (i.e. wrap it in a script of some sort) and
if you fool the other build tools that you are a native compiler
while you're at it, you also get away from the usual cross build
limitations.

But you are still doing a cross build. If you don't realize
that, think of the case were a testsuite has a program that
takes a filename as argument. If you don't special case anything
the build tools will pass that filename using Posix semantics,
and the testsuite may fail because of it.

How do you use MinGW from MSYS? Gosh, MSYS does the path
translation for me! Thank you very much, I don't need a wrapper.
IMHO, MSYS is the Posixy scripting environment that is closest to
being native Win32, and config.guess recognizes MSYS as something
like i686-pc-mingw32. And hey, on MSYS "uname -s" (the "kernel
name", or the "name of the operating system" according to various
man pages!), is something like MINGW32_NT-5.1. So, I guess it's
not only the compiler that is named MinGW...

> > For 1) a proper autoconf test would solve this and clean up the
> > code at the same time.
>
> Sure, but I guess you won't get that message to 300 package maintainers
> if that means additional work. Those people will tell you: "hey, I have
> working windows support already, I don't need your stuff, so I won't put
> hours into cleaning up mingw"... even if things work out of the box,
> people are unlikely to use it, if they have another solution already (I
> saw that with parity)...

This is of course the perfect argument why this discussion does not
matter at all. The population of package maintainers caring about
MSVC is probably tiny, if they go for Windows, they will go for
MinGW and be satisfied with that.

My experiment was not an argument that using $host mingw* for MSVC
is the best way to go, it was an attempt to refute the "massive
uglification" argument. I felt that was on the border to FUD.

> > For 2) libsndfile doesn't set an export file unless you build
> > with gcc, so it would be easy to add the correct argument when
> > building with MSVC, without causing any extra clutter. And if
> > the code is changed to use the libtool option -export-symbols
> > instead of using -Wl, I think MinGW and MSVC can use the same
> > export file, including ordinal specification. But I haven't
> > tested that (you should be able to pass a .def file straight
> > through to the linker using -export-symbols by having the first
> > line read EXPORTS, for both MinGW and MSVC).
>
> Mhm, sounds as i fit can work :)

Yeez, I had an unresonably hard time parsing that, s/i fit/if it/ :-)

> > If I make the testsuite ignore the ordinals problem, and manually
> > fix the SIGNED_SIZEOF problem all other tests pass (there are
> > quite a few).
> >
> > I realize that one random package doesn't say much. But one
> > tweek (or two, maybe maybe two) inside mingw* territory is
> > definitely not "massive uglification", not when there is room
> > for unification. Or?
>
> As I said above, I feel mingw is just plain wrong... but it's your
> patch, you will know. :)

And besides, it's fun fun fun to add windows*, win32*, winnt*,
winxp*, win* or whatever it ends up being called, to those
case $host_os statements. Pick your poison.

All of the theories about what name to use are pointless, really.
It all boils down to what is practical, and I need some evidence
that using mingw* for MSVC on MSYS really is b0rked before I agree
to change. Using mingw* is practical for me.

Cheers,
Peter