RE: [patch #6448] [MSVC 7/7] Add MSVC Support
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 ). 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. 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. 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? Maybe you use msys as your environment, yes, but mingw is not involved at all in you compilations... How can you expect users to _not_ be confused when they think of mingw and get cl.exe? Calling your host ming32 feels just really really wrong, since your port has absolutely nothing (and really _nothing_ to do with mingw. What if somebody uses your port on, say, interix or cygwin? He doesn't necessarily need to know about mingw at all! 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)... 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 :) 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
Re: Linking with '-L /path/to/lib' (note the space!)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello! Thanks to all for handling this issue so quickly! I'm impressed. Cheers from Germany Olaf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIt58BtQ3riQ3oo/oRAmp2AKCugAKUHcZS5SUvQ3cAc2p7lFyACQCfU/SG ym5ik1Y3kRYftmEavJVdANY= =Oa21 -END PGP SIGNATURE-
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
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
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Not sure if I should drag this further along... So this is the last one ... :) [snip] __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. Ok, this point is true, yes. 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. But it cannot be even much work to simply add a new host everywhere (except for the locations where there are differences) additionally to mingw...? it took me a few minutes to do this for winnt/interix (I first had interix as host, which is wrong). Then you'd have a clean distinction of the both. 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. So if mingw isn't there, the host can't be mingw ...? 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. what if you do ./configure --host=i586-pc-winnt-msvc and have a link called i586-pc-winnt-msvc-cl to cl.exe? that would make configure select that compiler automatically. [snip] 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. Mhm, yeah thats true with plain cl.exe, right. 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. Parity is my wrapper, and - thats one oft he cool points - it teaches any binary it compiles to handle three different possible types
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: 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? Sorry for the delay -- I've been snowed under this week. What I meant was that there will soon be a proliferation of instances in ltmain where case $host in *-*-mingw* ) stuff will have to be special-cased with 'case $CC in' sub-clauses. (I know, I know -- policy is that all that stuff is handled in *.m4, and ltmain is generic. But in practice, it isn't true). However, looking more closely, there's no difference in that outcome than in the way we currently handle different compilers on, say, solaris. There are special cases for 'case $CC in *gcc*)' already. And, in master, we already have some (bitrotted) special casing for $host mingw in the form of 'when $CC is not gcc, assume msvc and do this stuff instead...' For client packages, I know that /I/ have been guilty of assuming 'mingw' implies 'gcc', and I've seen many others that do, as well. But again, that's no different that portable packages that assume $host==solaris implies gcc. They break when you try to use Sun's compiler -- and that is a /bug/ in the client package. It's not the fault of libtool or an indication that the $host triple is incorrect. Finally, there's one additional benefit to using *-*-mingw* to mean the windows runtime platform operating within the Win32/Win64 subsystem -- regardless of the compiler being used (as distinct from the Posix subsystem that interix uses, or the cygwin runtime operating in the Win32 subsystem): It makes RMS happy. (Look ma, no win) Ok, ok, maybe that was uncalled for. g But still, consider me convinced. -- Chuck
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Den 2008-08-29 13:27, skrev Duft Markus: what if you do ./configure --host=i586-pc-winnt-msvc and have a link called i586-pc-winnt-msvc-cl to cl.exe? that would make configure select that compiler automatically. Nope, doesn't work (after adjusting to i686-pc-winnt, since config.sub complains with i686-pc-winnt-msvc, you have to teach it that winnt-msvc* is a valid KERNEL-OS combination). checking build system type... i686-pc-winnt checking host system type... i686-pc-winnt checking target system type... i686-pc-winnt checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i686-pc-winnt-gcc... no checking for gcc... gcc You'd have to deliberately hide the MinGW compiler (or not install it). Parity is my wrapper, and - thats one oft he cool points - it teaches any binary it compiles to handle three different possible types of paths correctly: native win32 (C:\...), interix through psxdll.dll (/dev/fs/C/..., or /usr/local/...) and cygwin through cygwin1.dll (/cygdrive/..., /usr/local/). this happenes completely in the background, no additional work to be done by the package. Of course I know that this is not possible with plain cl.exe So for what I do, I don't feel it's a cross compile, as you can see... Interesting, but semi-alarming as well. That means that the binary is not as pure as you have previously stated. It leaves room for ambiguity (== security issues), as e.g. /etc/passwd is a valid win32 path. How do you tell if I wanted C:\etc\passwd (with C: being the current drive) or the /etc/passwd as seen by cygwin? Can this be turned off? And especially cygwin1.dll has license implications that should be considered... Is the cygwin path translation enabled even if you build on Interix? Just curious, where and how do you hook this functionality into the binary and what happens when you are using a parity dll with something not using parity? And the other way around? 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. Hmm... why not look for mingw, and add winnt-msvc? It wasn't so much of a pain for me... I know it's not that painful, the question is how to /minimize/ the pain. Also, remember that MSVC with cccl have not used a different $host, at least not to my knowledge? But how you are supposed to use cccl with libtool is beyond me... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Den 2008-08-18 11:50, skrev Peter Rosin:
Ralf Wildenhues skrev:
PS: yes, all the other new tag variables need documenting in the manual,
too, before the branch can be merged into master.
Like this?
[EMAIL PROTECTED] postlink_cmds
+Commands necessary for finishing linking programs. @var{postlink_cmds}
+are executed immediately after the program is linked. Any occurance of
+the string @[EMAIL PROTECTED]@} in @var{postlink_cmds} is replaced by the
+name of the created executable (i.e. not the wrapper, if a wrapper is
+generated) prior to execution. Normally disabled (i.e.
[EMAIL PROTECTED] empty).
[EMAIL PROTECTED] defvar
I think that should be @code{@@OUTPUT@@}? I'll fix that before
commiting, so if that was the only problem...
Cheers,
Peter
