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

[Peter Rosin]

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)
* 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 "").
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).

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.

For 1) a proper autoconf test would solve this and clean up the
code at the same time.

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).

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?

Cheers,
Peter