[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #6, patch #6448 (project libtool): Peter, you have mentioned, that you wanted to test this path with cccl, but doesn't worked for you. I don't know if this is still an issue but there exists a new patch for cccl mentioned on this site: http://folti.blogs.balabit.com/2009/08/compiling-autoconfmake-using-sources.html source code can be downloaded from $ git clone git://git.balabit.hu/folti/cccl.git I hope this helps to improve the MSVC support, because for now this is a must have to introduce the use of open source libraries in our company! Cheers, Matthias ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #7, patch #6448 (project libtool): Hi Matthias! Ok, I have tried that cccl script, but it still fails miserably to even build libtool. So naturally I have no testsuite results. The failure looks the same (on a cursory look) on master and on the pr-msvc-support branch so I do not appear to have made things worse... This cccl script is not targeting MSYS (it uses single forward slashes) and can therefore only be used from cygwin. It is also a fact that this cccl script uses cygpath to convert incoming posix paths to windows paths, which libtool is also doing when cccl is detected on cygwin. That looks like a major incompatibilty to me. The provided ccclibtool wrapper isn't improving things for me. I still need someone to show me a recipe for how to build libtool with (some incarnation of) cccl. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hello Bjorn, * Bjorn Everts wrote on Thu, May 07, 2009 at 04:57:41PM CEST: Additional Item Attachment, patch #6448 (project libtool): File name: msvc.patch Size:12 KB Reply to this item at: http://savannah.gnu.org/patch/?6448 It is probably easier if you just follow the pr-msvc-support branch in the git tree of Libtool. Cheers, Ralf
[patch #6448] [MSVC 7/7] Add MSVC Support
Additional Item Attachment, patch #6448 (project libtool): File name: msvc.patch Size:12 KB ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/
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: [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
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 ). 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
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: [snip] Again, I just /mentioned/ the patchlevel issue. I'm only advocating that the API level of the ms runtime be encoded in $host. (Anything finer grained is just as completely FUBARed^W difficult to manage as MS's side-by-side solution). So then id' suggest the following host triplets for us: i586-pc-winnt-paritymsvc-version (e.g. i586-pc-winnt-parity80) i586-pc-winnt-msvcmsvc-version (e.g. i586-pc-winnt-msvc80) what do you think? Maybe we should think about using win32/win64 instead of winnt too. Parity only supports win32 by now. OTOH the i586 denotes a x86 CPU anyway. But: one could build (in the future) x86_64-pc-win32-msvc80 or something like that... Ideas? Cheers, Markus -- Chuck
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: I created a simple dll, exporting one function doing a printf (some random libc function). When building this dll, MSVC8 generated a manifest, but I instead embedded the manifest pointing to an older msvcr80. I.e. Embedded this: assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / instead of what MSVC8 generated, which was this: assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / Then I created an exe using both fopen (some other libc function) and consuming this dll, and in that exe I embedded the generated manifest (i.e. version 8.0.50727.762). Looking at this exe with depends.exe reveals that only one msvcr80.dll is loaded. That might be a bug in depends.exe though. Turns out there's a policy involved as well. For all assemblies on my system containing msvcr80.dll (there's currently three) the policy says to redirect older versions to the one the policy is for. I.e. for version 8.0.50727.1433 of the assembly, there's this in the policy file: bindingRedirect oldVersion=8.0.41204.256-8.0.50608.0 newVersion=8.0.50727.1433/ bindingRedirect oldVersion=8.0.50727.42-8.0.50727.1433 newVersion=8.0.50727.1433/ That explains why I only saw one of the dlls being loaded. However, why are versions 8.0.50608.1-8.0.50727.41 not being redirected? That's disheartening... So I took the liberty of temporarily renaming the policy files, and I could indeed make depends.exe show something other than the .1433 dll, but I could not make it show two different libc at the same time. With the policy files renamed, I also failed to make depends.exe show two different msvcr80.dll when using LoadLibrary on the dll instead of linking with the import library, so that's something... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
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? Cheers, Peter
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
I Forgot to answer some things... snip My patches use the same host/build as MinGW when using MSYS, on the grounds that the output from the MinGW tools and MSVC are compatible (so same $host) and that MSYS is MSYS (same $build). That's also how cccl has it (at least I think so...) Hmm.. but your compiler is a different one, and thus behaves different than mingw. I don't think it's a good idea to take the mingw triplet for something other than mingw. Who knows - if there is something out there that is capable of patching mingw binaries in some form, relying on code that only gcc creates (I know that sample is kind of unrealistic, but hey - I patch MSVC binary code ;)) - it would fail with you binaries. The winnt was just the best that came to our ming, since the result is plain win32 binaries. winnt is not the only kind of output from MSVC. So, why is winnt better than win9x/winxp/win2k3 or whatever? And other tools also target winnt. To sum it up, I think winnt is both too narrow and too broad to be used as $host. Why not just parity? I don't support the 9x series of windows, and everything else is NT-kernel based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2, Vista and 2008 - that's what I intend. If you want to have a common name, mingw is it, that's what's used to denote the win32 environment w/o compatibility layers. If you want to go your own way, winnt is too generic. IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. That's just my view of things of course, but I have previously been proven to have a distorted view. So, use the salt shaker liberaly... Hehe, my opinion has been proven to be distorted too. So maybe discussing on this leads both of us somewhere :) Cheers, Markus So really the host could be *- interix* and target of parity is *-winnt*. Are interix binaries not in the posix subsystem? Or did you mean *-interix* as $build and *-winnt* as $host? Cheers, Peter
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Markus Duft skrev: I Forgot to answer some things... snip My patches use the same host/build as MinGW when using MSYS, on the grounds that the output from the MinGW tools and MSVC are compatible (so same $host) and that MSYS is MSYS (same $build). That's also how cccl has it (at least I think so...) Hmm.. but your compiler is a different one, and thus behaves different than mingw. I don't think it's a good idea to take the mingw triplet for something other than mingw. Who knows - if there is something out there that is capable of patching mingw binaries in some form, relying on code that only gcc creates (I know that sample is kind of unrealistic, but hey - I patch MSVC binary code ;)) - it would fail with you binaries. Then I think you are reading too much into the host triplet, it denotes hardware-vendor-os (and possibly -libc appended). There is no info in there that helps you determine the compiler. Hm, yeah, right :) The winnt was just the best that came to our ming, since the result is plain win32 binaries. winnt is not the only kind of output from MSVC. So, why is winnt better than win9x/winxp/win2k3 or whatever? And other tools also target winnt. To sum it up, I think winnt is both too narrow and too broad to be used as $host. Why not just parity? I don't support the 9x series of windows, and everything else is NT- kernel based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2, Vista and 2008 - that's what I intend. Ok, but MinGW is also winnt. (If you stretch it a bit, Cygwin is also winnt for that matter, but that's a different libc.) If you want to have a common name, mingw is it, that's what's used to denote the win32 environment w/o compatibility layers. If you want to go your own way, winnt is too generic. IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). I don't think that matters when it comes to the $host triplet, you can link code from MinGW with code from MSVC. Same os, same libc. Not necessarily same libc. Same kernel only. As you say below, mingw uses msvcrt.dll, which is the windows _internal only_ libc (MSDN: The msvcrt.dll is now a known DLL, meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.). this means, that not a single windows default user can link against it. I guess mingw provides an import library for it, or ld can handle the dll directly without import lib. However it's in no way a setup you can get without mingw that easy (although - of course - msvcrt.dll may be loaded and used through LoadLibrary, even if another msvc??.dll is linked in). This means, that mingw is _not_ what the windows compilers/linkers will produce by default - I found quite big differences from msvcrt.dll and msvc80.dll for example. It's nothing else but _compatible_ with winnt. Phew.. getting headaches now too (again...) :) Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. MinGW binaries are also native Windows binaries, and nothing else. I agree that -parity as -os is bad, but since the only reason for you to add a new -os is to make it simple for you (i.e. easy to test in configure and libtool, no cross compiles when using interix as $build etc), I think -parity is the best fit. I don't agree here. I think winnt ist the best match, since (opposed to mingw) I really use all the libraries and such exactly the same as the native compiler/linker... However, i686-pc-mingw32 is perhaps not correct for Microsoft compilers other than MSVC 6, since they use a different libc. It might also be incorrect for MSVC 6 w/o the -MD option since then you are also using a different libc than MinGW (i.e. msvcrt.dll). Ok, maybe correct for MSVC6, but come one... :) this is stone-age. From todays POV it's no more than compatible, and even this is questionable, because mixing heap managers can be dangerous. What if a mingw dll allocates memory using msvcrt.dll, passes the pointer to an executable built with native linker, and this free's using msvc80.dll - or the other way round. I had such problems when I started out with parity. Believe me, they are no fun to hunt down ;) Cheers, Markus I'm getting a headache... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Markus Duft skrev: Markus Duft skrev: The winnt was just the best that came to our ming, since the result is plain win32 binaries. winnt is not the only kind of output from MSVC. So, why is winnt better than win9x/winxp/win2k3 or whatever? And other tools also target winnt. To sum it up, I think winnt is both too narrow and too broad to be used as $host. Why not just parity? I don't support the 9x series of windows, and everything else is NT- kernel based, so I think winnt denotes all of NT4, 2000, XP, 2003, 2003R2, Vista and 2008 - that's what I intend. Ok, but MinGW is also winnt. (If you stretch it a bit, Cygwin is also winnt for that matter, but that's a different libc.) If you want to have a common name, mingw is it, that's what's used to denote the win32 environment w/o compatibility layers. If you want to go your own way, winnt is too generic. IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). I don't think that matters when it comes to the $host triplet, you can link code from MinGW with code from MSVC. Same os, same libc. Not necessarily same libc. Same kernel only. As you say below, mingw uses msvcrt.dll, which is the windows _internal only_ libc (MSDN: The msvcrt.dll is now a known DLL, meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.). this means, that not a single windows default user can link against it. I guess mingw provides an import library for it, or ld can handle the dll directly without import lib. However it's in no way a setup you can get without mingw that easy (although - of course - msvcrt.dll may be loaded and used through LoadLibrary, even if another msvc??.dll is linked in). This means, that mingw is _not_ what the windows compilers/linkers will produce by default - I found quite big differences from msvcrt.dll and msvc80.dll for example. It's nothing else but _compatible_ with winnt. Of course you'll shoot yourself in the foot if you're using two libc in the same bin without taking *great* care. This also applies to the heap manager below... Phew.. getting headaches now too (again...) :) Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. MinGW binaries are also native Windows binaries, and nothing else. I agree that -parity as -os is bad, but since the only reason for you to add a new -os is to make it simple for you (i.e. easy to test in configure and libtool, no cross compiles when using interix as $build etc), I think -parity is the best fit. I don't agree here. I think winnt ist the best match, since (opposed to mingw) I really use all the libraries and such exactly the same as the native compiler/linker... You *are* using the native compiler/linker :-) Or maybe not /the native/, but the most popular compiler/linker provided by the vendor... However, i686-pc-mingw32 is perhaps not correct for Microsoft compilers other than MSVC 6, since they use a different libc. It might also be incorrect for MSVC 6 w/o the -MD option since then you are also using a different libc than MinGW (i.e. msvcrt.dll). Ok, maybe correct for MSVC6, but come one... :) this is stone-age. From todays POV it's no more than compatible, and even this is questionable, because mixing heap managers can be dangerous. What if a mingw dll allocates memory using msvcrt.dll, passes the pointer to an executable built with native linker, and this free's using msvc80.dll - or the other way round. I had such problems when I started out with parity. Believe me, they are no fun to hunt down ;) Cheers, Markus I'm getting a headache... I've been reading a bit in the MinGW list archive... Apparently Microsoft has added newer stuff to the system msvcrt.dll as provided by the WinXP (and later) systems, so that it in fact is looking very much like msvcr71.dll (i.e. MSVC .Net, was that 2003?). Or was that msvcr70.dll? Oh well, the exact details doesn't matter here. That doesn't mean that you can mix this new msvcrt.dll with an actuall msvcr71.dll in the same bin though, it's just a hint that msvcrt.dll isn't tied to MSVC 6 (i.e. the stone age). If I got it right, you can enable the new functions by using something like #define __MSVC_VERSION 710 prior to including the system includes when using MinGW. But then you'll get a binary that will not run on Win2k and earlier since msvcrt.dll on those systems don't have the needed functions. Also, MinGW apparently has import libraries like libmsvcr71.a to actually bring in the newer versions of the MS runtime, if that's really what you want to do. So, it's not set in stone that msvcrt.dll is MSVC 6, and MinGW has ways to use a
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Markus Duft wrote: IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). And remember, you can only link code generated by mingw and by msvc together if you're using C. Not C++ or any other symbol-mangled ABI. PLUS, if you're talking about shared libraries (DLLs explicitly encode the libc that they depend on), you also can only use DLLs in the same app that depend on the same mxvcrt -- that is, msvcrt.dll. Not msvcrt71.dll etc. Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. I've been using *-*-msvcXX to designate microsoft compiler-based host triples. So, for Visual C++ 2005, it's -msvc80. This really saved our bacon at work when we switched from VizStudio 2003 to 2005; the different host triple allowed us to keep old/new stuff separate which was important during the transition, as they couldn't be linked together due to the different runtime requirements. (Plus, the 2003 stuff didn't need any of that .manifest crap, and couldn't understand it anyway, while it was required for the 2005 stuff). I suspect libtool will have to deal with this too -- wouldn't it be good have the .manifest-related code active only when -msvc80 or above? -- Chuck
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Markus Duft wrote: IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). And remember, you can only link code generated by mingw and by msvc together if you're using C. Not C++ or any other symbol-mangled ABI. PLUS, if you're talking about shared libraries (DLLs explicitly encode the libc that they depend on), you also can only use DLLs in the same app that depend on the same mxvcrt -- that is, msvcrt.dll. Not msvcrt71.dll etc. Yeah, that's what i'm talking about :) mingw != winnt. Period. Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. I've been using *-*-msvcXX to designate microsoft compiler-based host triples. So, for Visual C++ 2005, it's -msvc80. I was just thinking about something quite similar. I though about renaming my *-winnt to *-winnt-parity, and suggest peter to use *-winnt-msvc. Maybe the runtime version would be required too for both of them... This really saved our bacon at work when we switched from VizStudio 2003 to 2005; the different host triple allowed us to keep old/new stuff separate which was important during the transition, as they couldn't be linked together due to the different runtime requirements. (Plus, the 2003 stuff didn't need any of that .manifest crap, and couldn't understand it anyway, while it was required for the 2005 stuff). I suspect libtool will have to deal with this too -- wouldn't it be good have the .manifest-related code active only when -msvc80 or above? As for parity, the manifest handling is built-in, no need to worry about this. Parity can be used exactly the same for all of VS2003, VS2005, VS2008 and VS2008 Express Editions (attention: _not_ VS2005 Express Edition, except with some hacking :)) But maybe this is something peter has to handle in libtool? Cheers, Markus -- Chuck
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Charles Wilson skrev: I've been using *-*-msvcXX to designate microsoft compiler-based host triples. So, for Visual C++ 2005, it's -msvc80. This really saved our bacon at work when we switched from VizStudio 2003 to 2005; the different host triple allowed us to keep old/new stuff separate which was important during the transition, as they couldn't be linked together due to the different runtime requirements. (Plus, the 2003 stuff didn't need any of that .manifest crap, and couldn't understand it anyway, while it was required for the 2005 stuff). Hi Charles, What did you use as $build? Did you use any glue like cccl to use MSVC with the gnu tools? I suspect libtool will have to deal with this too -- wouldn't it be good have the .manifest-related code active only when -msvc80 or above? I embed the manifest if a .manifest file is generated. See http://article.gmane.org/gmane.comp.gnu.libtool.cvs/2665 Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Duft Markus skrev: Markus Duft wrote: IMHO mingw produces code that is very different from what MSVC produces - not only performance wise (in some cases). And remember, you can only link code generated by mingw and by msvc together if you're using C. Not C++ or any other symbol-mangled ABI. PLUS, if you're talking about shared libraries (DLLs explicitly encode the libc that they depend on), you also can only use DLLs in the same app that depend on the same mxvcrt -- that is, msvcrt.dll. Not msvcrt71.dll etc. You can have different C++ mangling on other systems too, and I still suspect $host to be the same. But this I don't know for a fact though. Yeah, that's what i'm talking about :) mingw != winnt. Period. On the contrary, I would say that mingw is indeed winnt since Microsoft has declared msvcrt to be owned by the operating system. I.e. winnt. Maybe i586-pc-msvc or i586-pc-winnt-msvc would be better, since this describes (in the same form as on linux) which platform I'm on. Parity as platform would be a little bit misleading I guess, since I want everyone to see on the first look that those binaries are native windows, and nothing else. I've been using *-*-msvcXX to designate microsoft compiler-based host triples. So, for Visual C++ 2005, it's -msvc80. I was just thinking about something quite similar. I though about renaming my *-winnt to *-winnt-parity, and suggest peter to use *-winnt-msvc. Maybe the runtime version would be required too for both of them... That may not work, if Charles statements about dlls requiring different patchlevels of msvcr80 holds. But that appears to not be the case: I created a simple dll, exporting one function doing a printf (some random libc function). When building this dll, MSVC8 generated a manifest, but I instead embedded the manifest pointing to an older msvcr80. I.e. Embedded this: assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / instead of what MSVC8 generated, which was this: assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' / Then I created an exe using both fopen (some other libc function) and consuming this dll, and in that exe I embedded the generated manifest (i.e. version 8.0.50727.762). Looking at this exe with depends.exe reveals that only one msvcr80.dll is loaded. That might be a bug in depends.exe though. This really saved our bacon at work when we switched from VizStudio 2003 to 2005; the different host triple allowed us to keep old/new stuff separate which was important during the transition, as they couldn't be linked together due to the different runtime requirements. (Plus, the 2003 stuff didn't need any of that .manifest crap, and couldn't understand it anyway, while it was required for the 2005 stuff). I suspect libtool will have to deal with this too -- wouldn't it be good have the .manifest-related code active only when -msvc80 or above? As for parity, the manifest handling is built-in, no need to worry about this. Parity can be used exactly the same for all of VS2003, VS2005, VS2008 and VS2008 Express Editions (attention: _not_ VS2005 Express Edition, except with some hacking :)) But maybe this is something peter has to handle in libtool? Yes, it is handled by libtool. Though, libtool will currently not embed manifests in built dlls, only exes. Maybe dlls also need to have the manifest embedded, but I have not needed that yet... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: That may not work, if Charles statements about dlls requiring different patchlevels of msvcr80 holds. But that appears to not be the case: I created a simple dll, exporting one function doing a printf (some random libc function). When building this dll, MSVC8 generated a manifest, but I instead embedded the manifest pointing to an older msvcr80. [snip] Then I created an exe using both fopen (some other libc function) and consuming this dll, and in that exe I embedded the generated manifest (i.e. version 8.0.50727.762). Looking at this exe with depends.exe reveals that only one msvcr80.dll is loaded. That might be a bug in depends.exe though. In a non-toy application, consisting of a dozen different open-source C libraries, thirty or more proprietary libraries comprising about 250k lines of C++ code, and a handful of applications, we ran into significant issues when developer A built the open source libraries with MSVC 2005 patchlevel X, and developer B linked the application(s) using, and where our proprietary code was compiled with, his MSVC 2005 patchlevel Y. The apps crashed badly. These problems went away when everything -- including C open-source libraries -- were all compiled with the same patchlevel compiler, with no other changes. Yes, it is handled by libtool. Though, libtool will currently not embed manifests in built dlls, only exes. Maybe dlls also need to have the manifest embedded, but I have not needed that yet... VisStudio does embed manifests in the DLLs AFAICT. However, this /may/ not be necessary, and perhaps I should try turning that off. Then, the only items in my on-the-job work that would actually specify which patchlevel/runtime should be loaded would be the application itself. As long as there's no conflict (for C++) between inline code taken from the STL headers of patchlevel X, and the non-inline code dynamically linked at runtime from the msvcp80.dll of patchlevel Y. (Note here I'm specifically talking about the C++ runtime, but similar inline/vs/out-of-line concerns probably hold for the C runtime of doffering patchlevels). Only experimentation will tell. -- Chuck
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Charles Wilson skrev: Peter Rosin wrote: That may not work, if Charles statements about dlls requiring different patchlevels of msvcr80 holds. But that appears to not be the case: I created a simple dll, exporting one function doing a printf (some random libc function). When building this dll, MSVC8 generated a manifest, but I instead embedded the manifest pointing to an older msvcr80. [snip] Then I created an exe using both fopen (some other libc function) and consuming this dll, and in that exe I embedded the generated manifest (i.e. version 8.0.50727.762). Looking at this exe with depends.exe reveals that only one msvcr80.dll is loaded. That might be a bug in depends.exe though. In a non-toy application, consisting of a dozen different open-source C libraries, thirty or more proprietary libraries comprising about 250k lines of C++ code, and a handful of applications, we ran into significant issues when developer A built the open source libraries with MSVC 2005 patchlevel X, and developer B linked the application(s) using, and where our proprietary code was compiled with, his MSVC 2005 patchlevel Y. The apps crashed badly. These problems went away when everything -- including C open-source libraries -- were all compiled with the same patchlevel compiler, with no other changes. Do you remember if anything C++ was built with the offending patchlevel? Or was it the open-source C libraries and nothing else that was built differently? Yes, it is handled by libtool. Though, libtool will currently not embed manifests in built dlls, only exes. Maybe dlls also need to have the manifest embedded, but I have not needed that yet... VisStudio does embed manifests in the DLLs AFAICT. However, this /may/ not be necessary, and perhaps I should try turning that off. Then, the only items in my on-the-job work that would actually specify which patchlevel/runtime should be loaded would be the application itself. Not embedding the manifest might be dangerous as the inline/dll boundary might have changed with a new patchlevel. Yes, I'm speculating. Just a word of caution... As long as there's no conflict (for C++) between inline code taken from the STL headers of patchlevel X, and the non-inline code dynamically linked at runtime from the msvcp80.dll of patchlevel Y. (Note here I'm specifically talking about the C++ runtime, but similar inline/vs/out-of-line concerns probably hold for the C runtime of doffering patchlevels). Only experimentation will tell. You might compare the situation to the compatibility problems with different g++ major versions. The g++ major version is not reflected in $host, and that's a considerably more stable number... So, I think we need to find out if the MSVC patchlevel influences the libc compatibility. I.e. ignore C++ for this discussion, as C++ has a whole new set of incompatibility possibilities that are already ignored elsewhere... Hmmm, just taking a step back here, changing $host to reflect the MSVC8 patchlevel is going to resolve these issues how, exactly? I mean if you pick up a prebuilt dll somewhere and mindlessly link with it, it's not unlikely that you're SOL in any case. There is no way to keep the user isolated from this mess, so when will it help to add the MSVC8 patchlevel to $host? Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: Do you remember if anything C++ was built with the offending patchlevel? Or was it the open-source C libraries and nothing else that was built differently? Looks like there was also xerces-c, which is open-source but C++. So, the root of the problem might not, in fact, have to do with the patchlevel revisions of the C runtime(s), but rather the MSVC C++ runtime(s). Not embedding the manifest might be dangerous as the inline/dll boundary might have changed with a new patchlevel. Yes, I'm speculating. Just a word of caution... Yes, that was what I was trying to convey. You might compare the situation to the compatibility problems with different g++ major versions. The g++ major version is not reflected in $host, and that's a considerably more stable number... Ok. However, that doesn't invalidate my point concerning the MS *C* runtime major versions. Because they change fairly often -- every year or so -- much more often than *nix libc.so ABI changes. Plus, you just don't DO that on *nix: mix different ABI versions of libc.so on the same system. That sort of thing is reserved for major distribution upgrades. Yet, on windows, you will routinely have msvc70, msvc71, msvc80 (31 flavors), msvcrt.dll, etc. all installed at the same time. However, it's probably very rare that even a developer will have more than one version of MSVC installed on the same machine. Right? So maybe it's a non-issue. So, I think we need to find out if the MSVC patchlevel influences the libc compatibility. I.e. ignore C++ for this discussion, as C++ has a whole new set of incompatibility possibilities that are already ignored elsewhere... Okay... Hmmm, just taking a step back here, changing $host to reflect the MSVC8 patchlevel is going to resolve these issues how, exactly? Well, actually I *wasn't* advocating that $host reflect the MSVC8 patchlevel. I was just pointing out the (potential) problem -- unfortunately the whole discussion went straight to the tall weeds. I *was* advocating that $host reflect the major revision (70, 71, 80). And I still do, because those represent API changes -- behavioral, as well as new interfaces added -- to the underlying C runtime in use. Many triples specify dietlibc or uclibc vs glibc, especially in the embedded world. I don't really see that this is different. 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. I mean if you pick up a prebuilt dll somewhere and mindlessly link with it, it's not unlikely that you're SOL in any case. There is no way to keep the user isolated from this mess, so when will it help to add the MSVC8 patchlevel to $host? Again, I just /mentioned/ the patchlevel issue. I'm only advocating that the API level of the ms runtime be encoded in $host. (Anything finer grained is just as completely FUBARed^W difficult to manage as MS's side-by-side solution). -- Chuck
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Ralf, Ralf Wildenhues skrev: Hi Peter, snip So, I guess I'm saying that I'd prefer sticking to: if test $GCC != yes; then reload_cmds=false fi Ok to push? Could this break parity support? I know It's not in the tree yet, but I still hope, that ralf comes to looking into my patch some day I'm thinking of two problem cases: - could be someone would like to use cccl with GNU binutils ld I guess neither cccl nor parity will work with GNU ld right now, BUT: M$ own cc and cc89 scripts (which are used by M$ to build nearly the whole system with MSVC as backend) use GNU ld, maybe those aren't too important, since not many people except M$ use it, but still ... I have wasted quite a bit of time trying to make cccl work. Can someone pleasepleaseprettypleasewithsugerontop point me to the *exact* cccl script I should use, what environment I should have and how I should configure to make it work? Use parity instead :) Cheers, Markus - could be another non-GCC compiler (we've had reports about those on w32 before, I don't remember whether that was Portland or so) FWIW, did you know that 'w32' to me just means Windows, 32bit? ;-) Err, yes, what makes you make that statement? The same goes for me, but cygwin is also w32 but most of the time you are best off if you forget that when you are using cygwin, and that's one of the reasons the name w32 is not all that useful. When I'm aware of what I'm doing I try to hold back any use of w32, it's generally too unspecific. Any time I see w32, I think: Ok, what is not included this time? Cheers, Ralf PS: I'm aware of other loose ends in this thread. I'll get to them eventually, hopefully. ;-) Feel free to ping me if I haven't by the end of next (not this) weekend. I will, thanks in advance! Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Hi Markus, Markus Duft skrev: Hi Ralf, Ralf Wildenhues skrev: Hi Peter, snip So, I guess I'm saying that I'd prefer sticking to: if test $GCC != yes; then reload_cmds=false fi Ok to push? Could this break parity support? I know It's not in the tree yet, but I still hope, that ralf comes to looking into my patch some day Well, my guess is that you would know if you have implemented reloadable objects (the -r switch) in parity. If you don't know, I expect reloadable objects are not supported and that this patch will help parity. Hold on! Since parity is using a $host matching *winnt*, this patch doesn't affect parity at all. BTW, did you file a copyright assignment? I'm thinking of two problem cases: - could be someone would like to use cccl with GNU binutils ld I guess neither cccl nor parity will work with GNU ld right now, BUT: M$ own cc and cc89 scripts (which are used by M$ to build nearly the whole system with MSVC as backend) use GNU ld, maybe those aren't too important, since not many people except M$ use it, but still ... This is exactly my point, the only thing that currently works with libtool and gnu ld is gcc (at least I think so). I.e. for these cases: case $host_os in cygwin* | mingw* | pw32* | cegcc*) So, why make exceptions at this time for something that doesn't work anyway? It can be added when (if ever) all the other bits needed for cross toolchain support are added. Regarding cc and cc89, that would be with interix as host, so not affected by this. Right? Cheers, Peter
RE: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Hi Markus, snip Hold on! Since parity is using a $host matching *winnt*, this patch doesn't affect parity at all. Yeah, right, i oversaw that :) BTW, did you file a copyright assignment? Sure, now 2 years ago, or so... Cheers, Markus I'm thinking of two problem cases: - could be someone would like to use cccl with GNU binutils ld I guess neither cccl nor parity will work with GNU ld right now, BUT: M$ own cc and cc89 scripts (which are used by M$ to build nearly the whole system with MSVC as backend) use GNU ld, maybe those aren't too important, since not many people except M$ use it, but still ... This is exactly my point, the only thing that currently works with libtool and gnu ld is gcc (at least I think so). I.e. for these cases: case $host_os in cygwin* | mingw* | pw32* | cegcc*) So, why make exceptions at this time for something that doesn't work anyway? It can be added when (if ever) all the other bits needed for cross toolchain support are added. Regarding cc and cc89, that would be with interix as host, so not affected by this. Right? Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hello Markus, * Markus Duft wrote on Wed, Aug 20, 2008 at 09:26:10AM CEST: Could this break parity support? We try to ensure that it doesn't happen. I know It's not in the tree yet, but I still hope, that ralf comes to looking into my patch some day Yes. My plan is to get Peter's stuff fully through once, then merge, then sigh and probably take a couple of weeks off Libtool, then do the same game with your parity patches. I took Peter's patches first since they have been waiting for longer. I'll go crazy if I have to do both at once. Cheers, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Ralf, Ralf Wildenhues skrev: Hi Peter, * Peter Rosin wrote on Sun, Aug 17, 2008 at 08:47:12AM CEST: One easy way to avoid cc_basename is to simply leave this for the next non-gnu tool to fix, i.e.: --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -3024,7 +3024,12 @@ case $reload_flag in esac reload_cmds='$LD$reload_flag -o $output$reload_objs' case $host_os in + cygwin* | mingw* | pw32* | cegcc*) +if test $GCC != yes; then + reload_cmds=false +fi +;; Hmm, a bit better. What about something like this? case $host_os in cygwin* | mingw* | pw32* | cegcc*) if test $GCC != yes; then case $LD in link* | LINK* | lib* | LIB* ) reload_cmds=false ;; esac fi ;; ... If you think that is overkill, then please say so. There is a major(?) problem with that, and that is that you have to look at $CC (and thus cc_basename) to automatically determine $LD. So, your suggestion will require an additional LD=link argument to configure (and would not allow for e.g. LD=/some/path/link, but that could be fixed). Currently $LD is not used (to my knowledge) by any code path when using MSVC, so that requirement is a bit unfortunate. Sorry for not making this point in my previous post when you mentioned $LD the first time... So, I guess I'm saying that I'd prefer sticking to: if test $GCC != yes; then reload_cmds=false fi Ok to push? I'm thinking of two problem cases: - could be someone would like to use cccl with GNU binutils ld I have wasted quite a bit of time trying to make cccl work. Can someone pleasepleaseprettypleasewithsugerontop point me to the *exact* cccl script I should use, what environment I should have and how I should configure to make it work? - could be another non-GCC compiler (we've had reports about those on w32 before, I don't remember whether that was Portland or so) FWIW, did you know that 'w32' to me just means Windows, 32bit? ;-) Err, yes, what makes you make that statement? The same goes for me, but cygwin is also w32 but most of the time you are best off if you forget that when you are using cygwin, and that's one of the reasons the name w32 is not all that useful. When I'm aware of what I'm doing I try to hold back any use of w32, it's generally too unspecific. Any time I see w32, I think: Ok, what is not included this time? Cheers, Ralf PS: I'm aware of other loose ends in this thread. I'll get to them eventually, hopefully. ;-) Feel free to ping me if I haven't by the end of next (not this) weekend. I will, thanks in advance! Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
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?
One more hurdle is the $AR_SEP issue. It is normally set to ' ', but that
doesn't fit too well with make (as you have previously mentioned, I'm
just raising the flag...).
2008-08-18 Peter Rosin [EMAIL PROTECTED]
* doc/libtool.texi (libtool script contents): Document
new variables introduced by the MSVC port.
Cheers,
Peter
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 1782811..9eefc18 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5530,6 +5530,23 @@ are used within @code{ltmain.sh} (@pxref{Configuring}):
The name of the system library archiver.
@end defvar
[EMAIL PROTECTED] AR_FLAGS
+Flags to create an archive.
[EMAIL PROTECTED] defvar
+
[EMAIL PROTECTED] AR_TFLAGS
+Flags to list archive content.
[EMAIL PROTECTED] defvar
+
[EMAIL PROTECTED] AR_XFLAGS
+Flags to extract files (or a single file, see @var{ar_extract_one_by_one})
+from an archive.
[EMAIL PROTECTED] defvar
+
[EMAIL PROTECTED] AR_SEP
+Separator between @var{AR} flags (e.g. @var{AR_TFLAGS}) and @var{AR} files.
[EMAIL PROTECTED] defvar
+
@defvar CC
The name of the compiler used to configure libtool. This will always
contain the compiler for the current language (@pxref{Tags}).
@@ -5595,6 +5612,13 @@ using @var{export_symbols_cmds} before linking an
archive.
Set to @samp{yes} or @samp{no}. Default is @samp{no}.
@end defvar
[EMAIL PROTECTED] ar_extract_one_by_one
+Extract archive members one by one as listed by @var{AR} using the
+option @var{AR_TFLAGS} in case the archiver does not support
+extracting all archive members with the @var{AR_XFLAGS} option.
+Normally @samp{no}, enable with @samp{yes}.
[EMAIL PROTECTED] defvar
+
@defvar archive_cmds
@defvarx archive_expsym_cmds
@defvarx old_archive_cmds
@@ -5620,6 +5644,10 @@ these commands, libtool will proceed to link against
@var{$objdir/$newlib}
instead of @var{soname}.
@end defvar
[EMAIL PROTECTED] archiver_list_spec
+How to feed a file listing to the archiver.
[EMAIL PROTECTED] defvar
+
@defvar build
@defvarx build_alias
@defvarx build_os
@@ -5637,6 +5665,11 @@ Whether libtool should build static libraries on this
system. Set to
@samp{yes} or @samp{no}.
@end defvar
[EMAIL PROTECTED] compile_tag
+Add tag specific option for the compiler. Normally disabled (i.e.
[EMAIL PROTECTED] is empty).
[EMAIL PROTECTED] defvar
+
@defvar compiler_c_o
Whether the compiler supports the @option{-c} and @option{-o} options
simultaneously. Set to @samp{yes} or @samp{no}.
@@ -5649,6 +5682,26 @@ convenience archives or a set of object file names can
be passed via
linker-specific options or linker scripts.
@end defvar
[EMAIL PROTECTED] dashL_envvar
+When linking, move all paths specified with @option{-L} options to
+this variable, for toolchains where it makes sense to pass the library
+search paths in an environment variable. Normally disabled (i.e.
[EMAIL PROTECTED] empty).
[EMAIL PROTECTED] defvar
+
[EMAIL PROTECTED] dashL_envvar_spec
+When moving library search paths with @var{dashL_envvar}, prepend this
+to each @option{-L} path that is added to @var{dashL_envvar}. Unused
+if @var{dashL_envvar} is empty.
[EMAIL PROTECTED] defvar
+
[EMAIL PROTECTED] dashl_xform
[EMAIL PROTECTED] expression for transforming -l options for the linker. The
+input to the @code{sed} instance is the original argument to the
[EMAIL PROTECTED] option, the output is fed as an arguments to the linker.
+Normally disabled (i.e. @var{dashl_xform} empty).
[EMAIL PROTECTED] defvar
+
@defvar dlopen_support
Whether @code{dlopen} is supported on the platform.
Set to @samp{yes} or @samp{no}.
@@ -5708,6 +5761,16 @@ and relinking at install time is triggered. This also
means that @var{DESTDIR}
installation does not work as expected.
@end defvar
[EMAIL PROTECTED] file_magic_glob
+How to find potential files when @var{deplibs_check_method} is
[EMAIL PROTECTED] @var{file_magic_glob} is a @code{sed} expression,
+and the @code{sed} instance is fed potential files, that is
+transformed by the @var{file_magic_glob} expression. Useful when the
+shell does not support the shell option @code{nocaseglob}, making
[EMAIL PROTECTED] inappropriate. Normally disabled (i.e.
[EMAIL PROTECTED] empty).
[EMAIL PROTECTED] defvar
+
@defvar finish_cmds
Commands to tell the dynamic linker how to find shared libraries in a
specific directory.
@@ -5874,6 +5937,10 @@ Whether files must be locked to prevent conflicts when
compiling
simultaneously. Set to @samp{yes} or @samp{no}.
@end defvar
[EMAIL PROTECTED] nm_file_list_spec
+Specify filename containing input files for @var{NM}.
[EMAIL PROTECTED] defvar
+
@defvar no_builtin_flag
Compiler flag to disable builtin functions that conflict with declaring
external global symbols as @code{char}.
@@ -5907,6 +5974,15 @@ Commands run after installing a shared or static
library,
Archiver handling (was Re: [patch #6448] [MSVC 7/7] Add MSVC Support)
Regarding the issue of merging the MSVC branch... Peter Rosin skrev: One more hurdle is the $AR_SEP issue. It is normally set to ' ', but that doesn't fit too well with make (as you have previously mentioned, I'm just raising the flag...). I can see one way out, and that is to create a new libtool mode, i.e. an interface something like this: .../libtool --mode=ar cru foo.a a.o b.o c.o .../libtool --mode=ar x foo.a .../libtool --mode=ar t foo.a Then in libtool.m4 set LTAR to '.../libtool --mode=ar' if $AR is too incompatible with a standard archiver interface. If $AR is compatible, simply set LTAR=$AR. Makefiles (and automake) can then use $LTAR if they like, or continue to use $AR if they wish to remain incompatible... Is that overkill for a stupid space problem? One pro with this approach is that it is a chance to clear up the $ARFLAGS/$AR_FLAGS confusion. Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: * Peter Rosin wrote on Fri, Aug 15, 2008 at 11:36:14AM CEST: Ralf Wildenhues skrev: --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4821,6 +4821,7 @@ _LT_EOF mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL PROTECTED]; $RM @[EMAIL PROTECTED]; fi' + reload_cmds=false Why is this not set in _LT_CMD_RELOAD? That's where reload_cmds is set (exceptions not invalidating the rule ;-) Because - explanation retrofitted :-) - I only want to set it to false for cc_basename matching cl*, and cc_basename isn't available in _LT_CMD_RELOAD. So I added a call to _LT_CC_BASENAME to _LT_CMD_RELOAD, is that ok. No, sorry, that is not ok. We don't want _LT_CC_BASENAME to be expanded more than once, and we don't want reload_cmds to depend on $CC at all if we can avoid it. I see two ways out: either go with your first patch, or not depend on $cc_basename here. This is after all mostly a linker-only business. Can we depend on $LD to decide? One easy way to avoid cc_basename is to simply leave this for the next non-gnu tool to fix, i.e.: --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -3024,7 +3024,12 @@ case $reload_flag in esac reload_cmds='$LD$reload_flag -o $output$reload_objs' case $host_os in + cygwin* | mingw* | pw32* | cegcc*) +if test $GCC != yes; then + reload_cmds=false +fi +;; etc Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Fri, Aug 15, 2008 at 01:44:30PM CEST: Ralf Wildenhues skrev: * Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST: LIBA_SCOPE int (*const v12) (void); Why doesn't this one need LIBA_SCOPE_VAR annotation only? (I guess I'm to search for the answer to this one in Brian's post) That I don't know. It's the same in export.at (probably copied one way or the other). I just left it as is, and changing it is orthogonal to this, so should be a separate patch anyway, right? You shouldn't change it. It was put there for a reason. The reason should appear in a comment (or in the hopefully-to-be-written chapter about w32 oddities ;-) Cheers, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Fri, Aug 15, 2008 at 11:36:14AM CEST:
Ralf Wildenhues skrev:
Please add Set to @code{false} on systems that cannot create
reloadable objects to the reload_cmds documentation in libtool.texi.
I used @samp(false) instead, as that seemed to be the usage for
constants in the surrounding entries.
Fine with me.
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4821,6 +4821,7 @@ _LT_EOF
mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL
PROTECTED];
$RM @[EMAIL PROTECTED];
fi'
+ reload_cmds=false
Why is this not set in _LT_CMD_RELOAD? That's where reload_cmds is set
(exceptions not invalidating the rule ;-)
Because - explanation retrofitted :-) - I only want to set it to false
for cc_basename matching cl*, and cc_basename isn't available in
_LT_CMD_RELOAD. So I added a call to _LT_CC_BASENAME to _LT_CMD_RELOAD,
is that ok.
No, sorry, that is not ok. We don't want _LT_CC_BASENAME to be expanded
more than once, and we don't want reload_cmds to depend on $CC at all if
we can avoid it.
I see two ways out: either go with your first patch, or not depend on
$cc_basename here. This is after all mostly a linker-only business.
Can we depend on $LD to decide?
Thanks,
Ralf
2008-08-15 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_CMD_RELOAD)
[cygwin, mingw, pw32, cegcc] cl*: Indicate that reloadable
objects does not work.
* tests/duplicate_conv.at: Skip last test if reloadable
objects does not work.
* doc/libtool.texi (libtool script contents): Document how to
indicate that reloadable objects does not work.
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3023,7 +3023,15 @@ case $reload_flag in
*) reload_flag= $reload_flag ;;
esac
reload_cmds='$LD$reload_flag -o $output$reload_objs'
+_LT_CC_BASENAME([$CC])
case $host_os in
+ cygwin* | mingw* | pw32* | cegcc*)
+if test $GCC != yes; then
+ case $cc_basename in
+ cl*) reload_cmds=false ;;
+ esac
+fi
+;;
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev:
Hi Peter,
* Peter Rosin wrote on Wed, Aug 13, 2008 at 12:41:04PM CEST:
2008-08-13 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
[cygwin, mingw, pw32, cegcc] cl*: Indicate that reloadable
objects does not work.
* tests/duplicate_conv.at: Skip last test if reloadable
objects does not work.
Please add Set to @code{false} on systems that cannot create
reloadable objects to the reload_cmds documentation in libtool.texi.
I used @samp(false) instead, as that seemed to be the usage for
constants in the surrounding entries.
OK with nit below addressed.
Thanks,
Ralf
And thanks to you to for all your reviews and excellent feedback!
PS: yes, all the other new tag variables need documenting in the manual,
too, before the branch can be merged into master.
Right...
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4821,6 +4821,7 @@ _LT_EOF
mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL
PROTECTED];
$RM @[EMAIL PROTECTED];
fi'
+ reload_cmds=false
Why is this not set in _LT_CMD_RELOAD? That's where reload_cmds is set
(exceptions not invalidating the rule ;-)
Because - explanation retrofitted :-) - I only want to set it to false
for cc_basename matching cl*, and cc_basename isn't available in
_LT_CMD_RELOAD. So I added a call to _LT_CC_BASENAME to _LT_CMD_RELOAD,
is that ok.
Ok to push like this?
2008-08-15 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_CMD_RELOAD)
[cygwin, mingw, pw32, cegcc] cl*: Indicate that reloadable
objects does not work.
* tests/duplicate_conv.at: Skip last test if reloadable
objects does not work.
* doc/libtool.texi (libtool script contents): Document how to
indicate that reloadable objects does not work.
Cheers,
Peter
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 7b6b3f5..ee1f362 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5909,7 +5909,8 @@ Commands run after uninstalling a shared or static
library, respectively.
@defvar reload_cmds
@defvarx reload_flag
-Commands to create a reloadable object.
+Commands to create a reloadable object. Set to @samp{false} on systems
+that cannot create reloadable objects.
@end defvar
@defvar runpath_var
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7ceec66..e61d899 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3023,7 +3023,15 @@ case $reload_flag in
*) reload_flag= $reload_flag ;;
esac
reload_cmds='$LD$reload_flag -o $output$reload_objs'
+_LT_CC_BASENAME([$CC])
case $host_os in
+ cygwin* | mingw* | pw32* | cegcc*)
+if test $GCC != yes; then
+ case $cc_basename in
+ cl*) reload_cmds=false ;;
+ esac
+fi
+;;
darwin*)
if test $GCC = yes; then
reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
diff --git a/tests/duplicate_conv.at b/tests/duplicate_conv.at
index ac5643b..be04005 100644
--- a/tests/duplicate_conv.at
+++ b/tests/duplicate_conv.at
@@ -25,6 +25,8 @@
AT_SETUP([duplicate convenience archive names])
AT_KEYWORDS([libtool])
+eval `$LIBTOOL --config | sed -n '/^reload_cmds=/,/^$/p'`
+
# We create two convenience archives with the same name, and _also_
# containing an object with the same name. This is necessary to detect
# the failure with both 1.5.22 and HEAD, since the latter does not (did
@@ -75,6 +77,8 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main
main.$OBJEXT ./libce
LT_AT_EXEC_CHECK([./main],[0],[ignore],[ignore])
$LIBTOOL --mode=clean rm -f libcee.la
+AT_CHECK([test x$reload_cmds = xfalse exit 77], [1])
+
# Test whether this works with reloadable objects as well.
AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT
c.lo a/liba.la b/liba.la],
[0], [ignore], [ignore])
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: Hi Peter, * Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST: 72: stresstest.at:31 Link option thorough search test Automatic path conversion in MSYS doesn't kick in for the argument -OUT:/some/absolute/path so lib.exe barfs. Commenting out absolute paths from the stress test reveals a couple of other problems... Who'd have thought that. ;-) First, when l3='-rpath /nonexistent' and st='-no-install', I see no reason for linking main using main-static.lo, so clear the mst variable for this case. I'm not sure whether I understand the logic behind this reasoning. If l3='-rpath /nonexistent', then liba.la will be an uninstalled shared library. That means that import semantics must be used, right? Right (unless you link with -static). 2008-08-13 Peter Rosin [EMAIL PROTECTED] * tests/stresstest.at: Link with main.lo when liba is shared and linking main with -no-install. Ahh, the actual commit message makes this much clearer. :-) IOW, I only had problems parsing the paragraph above, the actual patch is fine with me, although it might do with some comment at the case matching logic which doesn't look trivial any more (like: if -static is not passed, and the library is shared, then we have to use -DLIBA_DLL_IMPORT, thus main.lo). You got it. I have pushed this patch, with the extra comment, and with a couple of whitespace fixes in the immediate vicinity. 2008-08-13 Peter Rosin [EMAIL PROTECTED] * tests/stresstest.at [MSVC]: dllimport all imported variables. This is also ok with nits below addressed/explained. Pushed, see below. Thanks, Ralf --- a/tests/stresstest.at +++ b/tests/stresstest.at @@ -93,29 +93,35 @@ AT_DATA(main.c, -extern int v9(void); [...] +LIBA_SCOPE_VAR int v9(void); Why does this one need annotation? If functions need this, then the naming of the #define is certainly suboptimal. My mistake, removed in the patch I pushed. [...] LIBA_SCOPE int (*const v12) (void); Why doesn't this one need LIBA_SCOPE_VAR annotation only? (I guess I'm to search for the answer to this one in Brian's post) That I don't know. It's the same in export.at (probably copied one way or the other). I just left it as is, and changing it is orthogonal to this, so should be a separate patch anyway, right? Likewise for both in the other hunk: Same treatment. I also pushed the link-order.at patch as shown in http://www.mail-archive.com/libtool-patches@gnu.org/msg04063.html Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Wed, Aug 13, 2008 at 10:12:23PM CEST: 24: link-order.at:26 Link order test. Exporting int c variable. With MSVC, you can declare any variable with __decspec(dllimport), even if you are not actually importing it. The only thing that happens is that you get an extra indirection in the generated code. This is a small price to pay, The relative cost of extra indirection quite depends on the way it is used. To give you an extreme, but real-world example, using Autoconf with the master branch of GNU m4 is 15% slower with PIC code than without (for an example package; this amounts to 4 seconds), on GNU/Linux. That's basically the overhead of having to go through the GOT indirection. (Disclaimer: I haven't tried to use PIC objects in a static link.) I don't know whether the dllimport indirection is as costly though. Of course for our examples in the test suite it's not the overhead that matters. when the gain is that you don't need to compile things differently depending on how you are going to link with the library. The situation is quite similar to pic/non-pic, but the trouble is that the difference is in the library consumer and not when producing the library. Yep. So, ignoring the runtime performance penalty, patch things up like this: Thanks, please apply. Cheers, Ralf 2008-08-13 Peter Rosin [EMAIL PROTECTED] * tests/link-order.at [MSVC]: Always dllimport exported variables.
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Peter, * Peter Rosin wrote on Wed, Aug 13, 2008 at 09:40:17PM CEST: 72: stresstest.at:31 Link option thorough search test Automatic path conversion in MSYS doesn't kick in for the argument -OUT:/some/absolute/path so lib.exe barfs. Commenting out absolute paths from the stress test reveals a couple of other problems... Who'd have thought that. ;-) First, when l3='-rpath /nonexistent' and st='-no-install', I see no reason for linking main using main-static.lo, so clear the mst variable for this case. I'm not sure whether I understand the logic behind this reasoning. If l3='-rpath /nonexistent', then liba.la will be an uninstalled shared library. That means that import semantics must be used, right? 2008-08-13 Peter Rosin [EMAIL PROTECTED] * tests/stresstest.at: Link with main.lo when liba is shared and linking main with -no-install. Ahh, the actual commit message makes this much clearer. :-) IOW, I only had problems parsing the paragraph above, the actual patch is fine with me, although it might do with some comment at the case matching logic which doesn't look trivial any more (like: if -static is not passed, and the library is shared, then we have to use -DLIBA_DLL_IMPORT, thus main.lo). 2008-08-13 Peter Rosin [EMAIL PROTECTED] * tests/stresstest.at [MSVC]: dllimport all imported variables. This is also ok with nits below addressed/explained. Thanks, Ralf --- a/tests/stresstest.at +++ b/tests/stresstest.at @@ -93,29 +93,35 @@ AT_DATA(main.c, -extern int v9(void); [...] +LIBA_SCOPE_VAR int v9(void); Why does this one need annotation? If functions need this, then the naming of the #define is certainly suboptimal. [...] LIBA_SCOPE int (*const v12) (void); Why doesn't this one need LIBA_SCOPE_VAR annotation only? (I guess I'm to search for the answer to this one in Brian's post) Likewise for both in the other hunk: @@ -131,26 +137,32 @@ AT_DATA(dlself.c, -extern int v9(void); +LIBA_SCOPE_VAR int v9(void); LIBA_SCOPE int (*const v12) (void);
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: * Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST: Ralf Wildenhues skrev: * Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST: Peter Rosin skrev: 16: duplicate_conv.at:25 duplicate convenience archive names MS link doesn't have reloadable objects (i.e. like ld -r). Should be fixed by at-file support I hope. Unfortunately not, the test tries to link with -o cee.$OBJEXT which triggers some different code path using -r. I don't think's it's possible to have link.exe output an object file. Ah yes, I didn't look at the test. In this case, the test should just be skipped for systems where reload_cmds does not work. Speaking of which, I think you should set reload_cmds to 'false' or so, so that it's clear things fail. That could then be tested for as a SKIP criterion in the testsuite. Right, I'll prepare a patch later... Side note, the mainfest could perhaps be used to support some version of hardcode_libdir? I guess. Patches welcome, as they say. ;-) 30: static.at:357 ccache -all-static cl.exe spews out a banner on stderr which isn't [ignore]d I think that banner should just be ignored. Me too. Is the patch below sufficient? Yes, please push. Thanks! 46: lt_dladvise.at:28 lt_dlopenadvise library loading -avoid-version causes the names of the import lib and the static lib to be the same. But something elseTM also seems bad... Several issues: - the test is somewhat broken (also on other systems) - maybe we need to forbid enabling both static and shared at the same time - Or come up with a naming scheme that doesn't conflict with itself, but I don't know if that's possible... Not sure whether I understand this. With MSVC and -avoid-version, libtool will create both the import library and the old (static) libarary with the same name (at least when both static and shared are enabled at the same time). The current naming is: Shared library: foo-version.dll Import library: foo-version.lib Static library: foo.lib But naming the import library e.g. foo-imp.lib or something (the -version part isn't really needed), it wouldn't collapse into the name of the static lib when the -avoid-version option is given. But just tagging on -imp to the name will of course conflict with any library name ending with -imp. Don't know if that's a real problem... But pdemo still fails due to an exported variable. Sigh. Why does each and every damn test (well, almost) have to export a variable when that's listed as not portable in the docs? Because it can be done on most systems, and w32 is not supported anyway for many packages. Seems masochistic to me... Well, the testsuite is intended to test each possible code path. That doesn't mean things have to be tested more often than necessary, but there could be for example a bug with exporting variables in the ltmain code that is exercises by pdemo. It's just very hard to see other failures when so much stumbles on this issue. From my point of view, you may push the ltmain part of the patch. I'll test any improved m4 code when you have settled on how to enable it. However, your idea to check the help output will not work, dumpbin -? doesn't indicate any support whatsoever for @. Oh, I didn't mean to try 'dumpbin -?' Sorry, I should have been clearer: GNU binutils nm understands @FILE since fairly recently; more precisely, all binutils tools understand this syntax since version 2.17. It would be nice to also enable this for binutils. That would enable most real-world uses of 'ld -r' for good. Proposed patch below. However, we need to avoid enabling this for older GNU binutils. That could be done with a feature check or a check of --help output. Probably a feature check is more reliable. Part of my confusion here stemmed from the fact that, while on unixy systems, at-file support is a per-tool thing, on Windows it is actually a system feature (at least I think that it is that way). No, it's not a system feature as such, it's just that many tools implement it. My guess is that it is needed since the shell quoting is so b0rked :-) Proposed patch below. I changed my mind again and moved the nm_file_list_spec setting out from LT_PATH_NM. OK? Looks perfectly reasonable, but I'd change fi;if into elif, no need to run $NM --help when nm_file_list_spec is already '@'. But I don't care all that much... So, please push with or w/o elif. Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: - (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err) + (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21) Hi Ralf, Is there a reason for this, I thought the log was there to help diagnose what went wrong, and that more information is better? Granted, the above cmd will produce a number of perhaps annoying lines of usage instructions on stderr on most systems. But hey, compare that to tossing the error message when you have a lib.exe that unexpectedly fails. All that said, I realize that lib.exe is fairly exotic, and I understand if you don't want the ar usage in the log, I just wanted to highlight that this is not the only thing you are cutting out. Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Wed, Aug 13, 2008 at 11:00:33AM CEST: Ralf Wildenhues skrev: - (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err) + (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21) Is there a reason for this, Yes, file 21 is completely equivalent to file except that the latter syntax is bash-specific and the former supported by all POSIX-compatible shells. I was testing with dash last night and saw ugly noise on (undirected) stderr when running configure. Cheers, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: * Peter Rosin wrote on Wed, Aug 13, 2008 at 11:00:33AM CEST: Ralf Wildenhues skrev: - (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err) + (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21) Is there a reason for this, Yes, file 21 is completely equivalent to file except that the latter syntax is bash-specific and the former supported by all POSIX-compatible shells. I was testing with dash last night and saw ugly noise on (undirected) stderr when running configure. Oops, and *blush* :-) Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Ralf Wildenhues skrev: * Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST: Ralf Wildenhues skrev: * Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST: Peter Rosin skrev: 16: duplicate_conv.at:25 duplicate convenience archive names MS link doesn't have reloadable objects (i.e. like ld -r). Should be fixed by at-file support I hope. Unfortunately not, the test tries to link with -o cee.$OBJEXT which triggers some different code path using -r. I don't think's it's possible to have link.exe output an object file. Ah yes, I didn't look at the test. In this case, the test should just be skipped for systems where reload_cmds does not work. Speaking of which, I think you should set reload_cmds to 'false' or so, so that it's clear things fail. That could then be tested for as a SKIP criterion in the testsuite. Right, I'll prepare a patch later... Attached... 2008-08-13 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw, pw32, cegcc] cl*: Indicate that reloadable objects does not work. * tests/duplicate_conv.at: Skip last test if reloadable objects does not work. Cheers, Peter diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 7ceec66..5149a45 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -4821,6 +4821,7 @@ _LT_EOF mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL PROTECTED]; $RM @[EMAIL PROTECTED]; fi' + reload_cmds=false ;; *) # Assume MSVC wrapper diff --git a/tests/duplicate_conv.at b/tests/duplicate_conv.at index ac5643b..be04005 100644 --- a/tests/duplicate_conv.at +++ b/tests/duplicate_conv.at @@ -25,6 +25,8 @@ AT_SETUP([duplicate convenience archive names]) AT_KEYWORDS([libtool]) +eval `$LIBTOOL --config | sed -n '/^reload_cmds=/,/^$/p'` + # We create two convenience archives with the same name, and _also_ # containing an object with the same name. This is necessary to detect # the failure with both 1.5.22 and HEAD, since the latter does not (did @@ -75,6 +77,8 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o main main.$OBJEXT ./libce LT_AT_EXEC_CHECK([./main],[0],[ignore],[ignore]) $LIBTOOL --mode=clean rm -f libcee.la +AT_CHECK([test x$reload_cmds = xfalse exit 77], [1]) + # Test whether this works with reloadable objects as well. AT_CHECK([$LIBTOOL --mode=link --tag=CC $CC $CFLAGS $LDFLAGS -o cee.$OBJEXT c.lo a/liba.la b/liba.la], [0], [ignore], [ignore])
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
*snip*
72: stresstest.at:31 Link option thorough search test
Automatic path conversion in MSYS doesn't kick in for the argument
-OUT:/some/absolute/path so lib.exe barfs.
Commenting out absolute paths from the stress test reveals a couple of
other problems...
First, when l3='-rpath /nonexistent' and st='-no-install', I see no
reason for linking main using main-static.lo, so clear the mst variable
for this case.
So, fixing that, like this:
2008-08-13 Peter Rosin [EMAIL PROTECTED]
* tests/stresstest.at: Link with main.lo when liba is shared
and linking main with -no-install.
Second, there are the inevitable variables that need importing, like
this:
2008-08-13 Peter Rosin [EMAIL PROTECTED]
* tests/stresstest.at [MSVC]: dllimport all imported
variables.
Cheers,
Peter
diff --git a/tests/stresstest.at b/tests/stresstest.at
index 27e7ee9..8eadf10 100644
--- a/tests/stresstest.at
+++ b/tests/stresstest.at
@@ -253,7 +253,8 @@ do
for st in '' '-static' '-no-install'
do
case $st,$l3 in
- ,-rpath*) mst= ;;
+ -static,*) mst=-static ;;
+ *,-rpath*) mst= ;;
*) mst=-static ;;
esac
diff --git a/tests/stresstest.at b/tests/stresstest.at
index 27e7ee9..8eadf10 100644
--- a/tests/stresstest.at
+++ b/tests/stresstest.at
@@ -93,29 +93,35 @@ AT_DATA(main.c,
#if defined(LIBA_DLL_IMPORT)
# if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__)
#define LIBA_SCOPE extern __declspec(dllimport)
+#if defined(_MSC_VER)
+# define LIBA_SCOPE_VAR LIBA_SCOPE
+#endif
# endif
#endif
#if !defined(LIBA_SCOPE)
# define LIBA_SCOPE extern
#endif
+#if !defined(LIBA_SCOPE_VAR)
+# define LIBA_SCOPE_VAR extern
+#endif
#ifdef __cplusplus
extern C {
#endif
-extern int v1;
-extern int v3, v4;
+LIBA_SCOPE_VAR int v1;
+LIBA_SCOPE_VAR int v3, v4;
LIBA_SCOPE const int v5, v6;
-extern const char* v7;
-extern const char v8[];
-extern int v9(void);
-extern int (*v10) (void);
-extern int (*v11) (void);
+LIBA_SCOPE_VAR const char* v7;
+LIBA_SCOPE_VAR const char v8[];
+LIBA_SCOPE_VAR int v9(void);
+LIBA_SCOPE_VAR int (*v10) (void);
+LIBA_SCOPE_VAR int (*v11) (void);
LIBA_SCOPE int (*const v12) (void);
#ifdef __cplusplus
}
#endif
typedef struct { int arr[1000]; } large;
-extern large v13, v14, v15;
+LIBA_SCOPE_VAR large v13, v14, v15;
int main(void)
{
@@ -131,26 +137,32 @@ AT_DATA(dlself.c,
#if defined(LIBA_DLL_IMPORT)
# if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__)
#define LIBA_SCOPE extern __declspec(dllimport)
+#if defined(_MSC_VER)
+# define LIBA_SCOPE_VAR LIBA_SCOPE
+#endif
# endif
#endif
#if !defined(LIBA_SCOPE)
# define LIBA_SCOPE extern
#endif
+#if !defined(LIBA_SCOPE_VAR)
+# define LIBA_SCOPE_VAR extern
+#endif
#ifdef __cplusplus
extern C {
#endif
-extern int v1;
-extern int v3, v4;
+LIBA_SCOPE_VAR int v1;
+LIBA_SCOPE_VAR int v3, v4;
LIBA_SCOPE const int v5, v6;
-extern const char* v7;
-extern const char v8[];
-extern int v9(void);
-extern int (*v10) (void);
-extern int (*v11) (void);
+LIBA_SCOPE_VAR const char* v7;
+LIBA_SCOPE_VAR const char v8[];
+LIBA_SCOPE_VAR int v9(void);
+LIBA_SCOPE_VAR int (*v10) (void);
+LIBA_SCOPE_VAR int (*v11) (void);
LIBA_SCOPE int (*const v12) (void);
typedef struct { int arr[1000]; } large;
-extern large v13, v14, v15;
+LIBA_SCOPE_VAR large v13, v14, v15;
extern int w1;
extern int w3, w4;
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
*snip*
24: link-order.at:26 Link order test.
Exporting int c variable.
With MSVC, you can declare any variable with __decspec(dllimport), even
if you are not actually importing it. The only thing that happens is
that you get an extra indirection in the generated code. This is a
small price to pay, when the gain is that you don't need to compile
things differently depending on how you are going to link with the
library. The situation is quite similar to pic/non-pic, but the trouble
is that the difference is in the library consumer and not when
producing the library.
So, ignoring the runtime performance penalty, patch things up like
this:
2008-08-13 Peter Rosin [EMAIL PROTECTED]
* tests/link-order.at [MSVC]: Always dllimport exported
variables.
diff --git a/tests/link-order.at b/tests/link-order.at
index ce52cc9..8791df8 100644
--- a/tests/link-order.at
+++ b/tests/link-order.at
@@ -48,13 +48,29 @@ for i in old new; do
mkdir src
cat src/a_$i.c EOF
-extern int c;
+/* w32 fun, MSVC supports dllimport even if importing is not needed (static
+ * case). gnu has auto import.
+ */
+#ifdef _MSC_VER
+# define LIBCEE_SCOPE __declspec(dllimport)
+#else
+# define LIBCEE_SCOPE extern
+#endif
+LIBCEE_SCOPE int c;
extern int b_$i();
int a_$i() { return c + b_$i(); }
EOF
cat src/b_$i.c EOF
-extern int c;
+/* w32 fun, MSVC supports dllimport even if importing is not needed (static
+ * case). gnu has auto import.
+ */
+#ifdef _MSC_VER
+# define LIBCEE_SCOPE __declspec(dllimport)
+#else
+# define LIBCEE_SCOPE extern
+#endif
+LIBCEE_SCOPE int c;
int b_$i() { return 1 + c; }
EOF
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Peter Rosin skrev: Ralf Wildenhues skrev: *snip* Please try the patch below for simplistic at-file support with $NM. While testing, I set nm_file_list_spec to '@' and always_export_symbols to yes on GNU/Linux, and saw no test failure, probably because my nm also understands '@'. :-) (IOW, we could enable that for when 'nm --help' lists @FILE.) Probably the setting of nm_file_list_spec should be moved to where $NM is set; not sure, as this is actually a Windows feature, not a $NM one. I tried the patch and it fixes the old testsuite pdemo test, excellent! But pdemo still fails due to an exported variable. Sigh. Why does each and every damn test (well, almost) have to export a variable when that's listed as not portable in the docs? Seems masochistic to me... From my point of view, you may push the ltmain part of the patch. I'll test any improved m4 code when you have settled on how to enable it. However, your idea to check the help output will not work, dumpbin -? doesn't indicate any support whatsoever for @. Maybe hook into the existing AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_... and add if test $lt_cv_nm_interface = MS dumpbin; then _LT_TAGVAR(nm_file_list_spec, $1)='@' fi to the end of LT_PATH_NM? But I don't know it's too early to use _LT_DECL/_LT_TAGVAR? It works to have it in LT_PATH_NM, so that's where I'd put it. Like the attached patch... Also, I tested the patch on the new testsuite and with this patch I get the desired behaviour in the cmdline_wrap.at test (73). I pushed the other patches[1][2], but this one is also on the list of things I like. Ok to push to the msvc branch? Cheers, Peter [1] http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00018.html [2] http://lists.gnu.org/archive/html/libtool-patches/2008-08/msg00019.html
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Tue, Aug 12, 2008 at 10:38:45AM CEST: Peter Rosin skrev: It works to have it in LT_PATH_NM, so that's where I'd put it. Like the attached patch... That's a good idea. Also, I tested the patch on the new testsuite and with this patch I get the desired behaviour in the cmdline_wrap.at test (73). I pushed the other patches[1][2], but this one is also on the list of things I like. Ok to push to the msvc branch? Sorry for the delay. I pushed that patch to the msvc branch. Cheers, Ralf 2008-08-13 Ralf Wildenhues [EMAIL PROTECTED] Peter Rosin [EMAIL PROTECTED] Support for response files with $NM. * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) nm_file_list_spec: New tag variable. [ cygwin, mingw, cegcc ] cl*: Set to '@'. (_LT_LANG_CXX_CONFIG): Likewise. * libltdl/config/ltmain.m4sh (func_mode_link): When nm_file_list_spec is nonempty, use it to avoid skipped_export.
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Ralf Wildenhues wrote on Wed, Aug 13, 2008 at 07:21:07AM CEST:
Sorry for the delay. I pushed that patch to the msvc branch.
2008-08-13 Ralf Wildenhues [EMAIL PROTECTED]
Peter Rosin [EMAIL PROTECTED]
Support for response files with $NM.
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) nm_file_list_spec:
New tag variable.
[ cygwin, mingw, cegcc ] cl*: Set to '@'.
(_LT_LANG_CXX_CONFIG): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): When
nm_file_list_spec is nonempty, use it to avoid skipped_export.
And obviously I didn't think before committing. Sorry about that.
Cheers,
Ralf
2008-08-13 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_PROG_AR, LT_PATH_NM): Fix bogus
uses of _LT_TAGVAR. Hide `ar' error message escape from command
line.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 0b88f76..7ceec66 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1367,7 +1367,7 @@ AC_CACHE_CHECK([the archiver ($AR)
interface],[lt_cv_ar_interface],
(eval echo \\$as_me:__oline__: $ac_compile\ AS_MESSAGE_LOG_FD)
(eval $ac_compile 2conftest.err)
cat conftest.err AS_MESSAGE_LOG_FD
- (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err)
+ (eval $AR -NOLOGO -OUT:conftest.lib conftest.$ac_objext conftest.err 21)
ac_status=$?
cat conftest.err AS_MESSAGE_LOG_FD
test $ac_status = 0 test -f conftest.lib lt_cv_ar_interface=lib
@@ -1379,16 +1379,16 @@ ar)
: ${AR_TFLAGS=t}
: ${AR_XFLAGS=x}
test -z $AR_SEP AR_SEP=' '
- _LT_TAGVAR(ar_extract_one_by_one, $1)=no
- _LT_TAGVAR(archiver_list_spec, $1)=
+ ar_extract_one_by_one=no
+ archiver_list_spec=
;;
lib)
: ${AR_FLAGS=-NOLOGO -OUT:}
: ${AR_TFLAGS=-NOLOGO -LIST }
: ${AR_XFLAGS=-NOLOGO -EXTRACT:}
test -z $AR_SEP AR_SEP=''
- _LT_TAGVAR(ar_extract_one_by_one, $1)=yes
- _LT_TAGVAR(archiver_list_spec, $1)='@'
+ ar_extract_one_by_one=yes
+ archiver_list_spec='@'
# Don't use ranlib
: ${RANLIB=:}
;;
@@ -3346,7 +3346,7 @@ AC_CACHE_CHECK([the name lister ($NM) interface],
[lt_cv_nm_interface],
rm -f conftest*])
if test $lt_cv_nm_interface = MS dumpbin; then
- _LT_TAGVAR(nm_file_list_spec, $1)='@'
+ nm_file_list_spec='@'
fi
_LT_DECL([], [nm_file_list_spec], [1],
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Wed, Aug 06, 2008 at 09:47:28AM CEST:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects (i.e. like ld -r).
Should be fixed by at-file support I hope.
Unfortunately not, the test tries to link with -o cee.$OBJEXT which
triggers some different code path using -r. I don't think's it's
possible to have link.exe output an object file.
Ah yes, I didn't look at the test. In this case, the test should just
be skipped for systems where reload_cmds does not work. Speaking of
which, I think you should set reload_cmds to 'false' or so, so that it's
clear things fail. That could then be tested for as a SKIP criterion in
the testsuite.
Side note, the mainfest could perhaps be used to support some version
of hardcode_libdir?
I guess. Patches welcome, as they say. ;-)
30: static.at:357 ccache -all-static
cl.exe spews out a banner on stderr which isn't [ignore]d
I think that banner should just be ignored.
Me too.
Is the patch below sufficient?
46: lt_dladvise.at:28 lt_dlopenadvise library loading
-avoid-version causes the names of the import lib and the static
lib to be the same. But something elseTM also seems bad...
Several issues:
- the test is somewhat broken (also on other systems)
- maybe we need to forbid enabling both static and shared at the same
time
- Or come up with a naming scheme that doesn't conflict with itself,
but I don't know if that's possible...
Not sure whether I understand this.
But pdemo still fails due to an exported variable. Sigh. Why does each and
every damn test (well, almost) have to export a variable when that's listed
as not portable in the docs?
Because it can be done on most systems, and w32 is not supported anyway
for many packages.
Seems masochistic to me...
Well, the testsuite is intended to test each possible code path. That
doesn't mean things have to be tested more often than necessary, but
there could be for example a bug with exporting variables in the ltmain
code that is exercises by pdemo.
From my point of view, you may push the ltmain part of the patch. I'll test
any improved m4 code when you have settled on how to enable it. However,
your idea to check the help output will not work, dumpbin -? doesn't
indicate any support whatsoever for @.
Oh, I didn't mean to try 'dumpbin -?' Sorry, I should have been
clearer: GNU binutils nm understands @FILE since fairly recently; more
precisely, all binutils tools understand this syntax since version 2.17.
It would be nice to also enable this for binutils. That would enable
most real-world uses of 'ld -r' for good. Proposed patch below.
However, we need to avoid enabling this for older GNU binutils. That
could be done with a feature check or a check of --help output.
Probably a feature check is more reliable.
Part of my confusion here stemmed from the fact that, while on unixy
systems, at-file support is a per-tool thing, on Windows it is actually
a system feature (at least I think that it is that way).
Proposed patch below. I changed my mind again and moved the
nm_file_list_spec setting out from LT_PATH_NM. OK?
Cheers,
Ralf
2008-08-13 Ralf Wildenhues [EMAIL PROTECTED]
* tests/static.at (ccache -all-static): Ignore compiler stderr.
Reported by Peter Rosin.
diff --git a/tests/static.at b/tests/static.at
index b5e9946..08b202f 100644
--- a/tests/static.at
+++ b/tests/static.at
@@ -370,7 +370,7 @@ AT_DATA([a.c],
[[int main(void) { return 0; }
]])
-AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore])
+AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c], [], [ignore], [ignore])
AT_CHECK([$LIBTOOL --mode=link --tag=CC ./ccache $CC $CFLAGS $LDFLAGS
-all-static a.$OBJEXT -o a],
[], [ignore], [ignore])
2008-08-13 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (LT_PATH_NM): Move setting of
nm_file_list_spec ...
(_LT_CMD_GLOBAL_SYMBOLS): ... here. Also enable for GNU nm if
supported.
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 7ceec66..9129896 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3344,13 +3344,6 @@ AC_CACHE_CHECK([the name lister ($NM) interface],
[lt_cv_nm_interface],
lt_cv_nm_interface=MS dumpbin
fi
rm -f conftest*])
-
-if test $lt_cv_nm_interface = MS dumpbin; then
- nm_file_list_spec='@'
-fi
-
-_LT_DECL([], [nm_file_list_spec], [1],
-[Specify filename containing input files for $NM])
])# LT_PATH_NM
# Old names:
@@ -3628,6 +3621,14 @@ else
AC_MSG_RESULT(ok)
fi
+# Response file support.
+if test $lt_cv_nm_interface = MS dumpbin; then
+ nm_file_list_spec='@'
+fi
+if $NM --help 2/dev/null | grep '[EMAIL PROTECTED]' /dev/null; then
+ nm_file_list_spec='@'
+fi
+
_LT_DECL([global_symbol_pipe], [lt_cv_sys_global_symbol_pipe], [1],
[Take
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Sat, Aug 09, 2008 at 10:43:26AM CEST: Ralf Wildenhues skrev: * Peter Rosin wrote on Thu, Aug 07, 2008 at 02:10:41PM CEST: 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD): Disable nocase handling for cross compiles. +file_magic_glob= +want_nocaseglob=no +if test $build = $host; then + case $host_os in + cygwin* | mingw* | pw32*) What if build is cygwin* and host is mingw*, for example? I expect that you will not need the nocase search in that case. Just use the exact names as they appear in the w32api. I.e. we define that from a libtool p.o.w. the canonical name of the ddraw import library is -lddraw. The nocase stuff is then *only* needed for MSVC, and using MSVC from cygwin isn't supported atm anyway, so nothing is lost. Oh, I didn't remember that MSVC wasn't supported from Cygwin anyway. Hmm, that makes me wonder why the above enables caseglobbing for the cygwin non-cross case. Are you saying we should aim for more? Naah, just checking to make sure we haven't forgotten anything inadvertently. Thanks, and I guess you can go ahead and apply this, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Sat, Aug 09, 2008 at 11:03:50AM CEST: Ralf Wildenhues skrev: Does this BTW mean that the manifest file ends up being part of the .exe and thus needs not be explicitly installed and uninstalled? That would be nice. Yes, the mt command embeds the manifest as a resource, so nothing extra to install. Cool. 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds: New tag variable. [ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a resource. (_LT_LANG_CXX_CONFIG): Likewise. * libltdl/config/ltmain.m4sh (func_mode_link): After linking a program, replace @OUTPUT@ in $postlink_cmds and then execute the commands. Not so bad; can we rely on 'mt' being present on all systems that have cl? Have you tried this patch on a setup where the program is relinked at install time (does this ever happen with cl)? No, the manifest was introduced in MSVC 7 or 8 or something. MSVC 6 doesn't generate any manifests. That's one reason for the postlink_cmds to have if test -f @[EMAIL PROTECTED]; Alright. That way, mt is only tried if there is a manifest file to embed, which also covers the case when the manifest file isn't needed (and thus not generated). If MSVC has generated a manifest, it better also have mt. OK. It might be a problem if you build inside the src tree and a foo.exe.manifest is part of the source tree, and the .exe isn't generated in the .libs subdir. I guess you just shouldn't do that. Doctor, it hurts when I etc... Good enough for me ATM. Please go ahead and apply this on the branch, thanks. Cheers, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues wrote:
Oh well; if somebody digs out the auto-import semantics from the list
archives/manuals, feel free to add a note to export.at so that the next
person won't be confused again. (Extra score for putting it in the new
w32 chapter. ;-)
The first issue here is that the auto-import mechanism requires that the
reference to the imported data item be in a writable section, because it
tricks the OS loader into making the fixup to the data address as if it
were fixing up an address of a dllimported function call.
The second issue is whether --enable-auto-import was specified to the
linker. This is a tri-state setting:
(A) If --disable-auto-import is specified, no auto-import functionality
is attempted and link errors will result unless __declspec(dllimport) is
used with all data references.
(B) If --enable-auto-import is specified then the feature is enabled and
the link script is modified to place the contents of .rdata into .data,
in effect making all read-only data writable.
(C) If neither of the above are specified then the auto-import feature
is still enabled, but the link script is unchanged, and anything in
.rdata stays read-only.
The important point here is where the reference to the data item is
located. Whether the data item itself is const doesn't matter, what
matters is the location from which it's referenced. For the vast
majority of cases, the reference is in code, and so the linker can just
mark .text as writable -- it can do this without modifying the link
script so this works with both (B) and (C).
And this is the case with v8 in export.at, which can be reduced more or
less to the following, which simply shows that the reference to _v8 is
in .text:
$ echo 'extern const char v8[]; char foo() { return v8[0]; }' | \
gcc -x c - -c -S -o - -fomit-frame-pointer
.file
.text
.globl _foo
.def_foo; .scl2; .type 32; .endef
_foo:
movsbl _v8,%eax
ret
In fact the constness of v8 is irrelevant, you get the same output if
you remove 'const'. What does matter is if the reference to it is
const:
$ echo 'extern char v8[]; const struct { char *ref; } s = { v8 };' |\
gcc -x c - -c -S -o - -fomit-frame-pointer
.file
.globl _s
.section .rdata,dr
.align 4
_s:
.long _v8
Here you have the _v8 reference inside this struct that lives in .rdata,
so if you want to auto-import v8 you need to pessimize .rdata to be
writable, and thus you need (B). The nasty part is that auto-import
will still try to do its job in case (C), and the link will succeed, but
you will get an inscrutable STATUS_ACCESS_VIOLATION (0xC005)
exception at runtime from the operating system before the process even
starts. This is what the linker is trying to warn about with the
following diagnostic:
warning: auto-importing has been activated without --enable-auto-import
specified on the command line.
This should work unless it involves constant data structures referencing
symbols from auto-imported DLLs.
N.B. The tri-state behavior is new as of approx 2007-10-01. Prior to
that, passing --enable-auto-import didn't really have much of an effect
other than suppressing info messages that the linker printed. And if
you did have the case where you wanted to auto-import a reference in
.rdata as in the last example, you had no choice but to manually hack
your linker script or remove the 'const'. This changed with the patch
for binutils PR4844:
http://sourceware.org/bugzilla/show_bug.cgi?id=4844.
It's also worth noting that if you do declare v8 as
__declspec(dllimport) then the compiler refuses (with a compile time
error) to let you use its address as a constant initializer as in the
last example. Since this does work on other platforms like ELF, I
suppose you can view this as another portability tradeoff: you gain the
abililty to port this software as-is without having to modify it, albeit
at the cost of essentially making all const data writable and unable to
be shared with other process instances.
On this subject of the politics of declspec markup vs. auto-import, I
guess it breaks down to this:
For auto-import:
Pro: headers need not be modified/uglified to cater to win32-isms
Con: those headers may already have #defines for declarations using ELF
symbol visibility, in which case it's easy to hook in the equivalent
Win32 declspecs
Pro: support ELFisms like using a var from a shared lib as a const
initializer
Con: at the cost of making .rdata writable and unsharable (and a small
startup penalty)
For explicit __declspec(dllimport)
Pro: for function imports, saves an extra jump through the __imp_foo
thunk
Pro: for data imports, retains compatibility with MSVC as well as .text
remaining readonly and shareable
Brian
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Peter,
* Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST:
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not __declspec(dllimport)ing all
these variables?
Yes: the auto-dll-import feature (was it named that?) from GCC on Cygwin
and MinGW is happy to import all these variables automatically.
I would like to somehow ensure that we expose this auto-import feature;
IOW, that we don't explicitly dllimport these variables. That way code
that is not portable to MSVC anyway, can rely on not needing these
annotations. Sorry to be such a pain on this point, but the GNU Coding
Standards explicitly allow developers to not go out of their way in
making stuff work on w32, and as such they come to expect that things
work smoothly without these kinds of annotations (and I for one would
like to be able to pinpoint where exactly the limits are).
So can we do something like this in the test, what do you think?
/* w32 fun. With GCC, you can have auto-import, which will work for
* functions and non-const variables. With MSVC, you have to explicitly
* import all variables. Depending on the amount of portability, you
* need these annotations: LIBA_SCOPE for GCC, and also LIBA_SCOPE_VAR
* for MSVC. Of course you can merge both to one, this test only avoids
* that in order to expose the auto-import feature on Cygwin.
*
* For users, it's best tor realize that they should not provide any
* non-function API at all.
*/
#if defined(LIBA_DLL_IMPORT)
# if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__)
#define LIBA_SCOPE extern __declspec(dllimport)
# if defined(_MSVC)
#define LIBA_SCOPE_VAR LIBA_SCOPE
# endif
# endif
#endif
#if !defined(LIBA_SCOPE)
# define LIBA_SCOPE extern
#endif
#if !defined(LIBA_SCOPE_VAR)
# define LIBA_SCOPE_VAR extern
#endif
and then add only LIBA_SCOPE_VAR annotations? If you agree, then
a patch to the pr-msvc-support branch to this end is preapproved
(you know how to push changes to a branch?)
I haven't yet decided for myself whether I would like to see this
split-up in the other test failures too, but I would definitely like
to see it in export.at. Maybe in stresstest.at too, but not in the
old-style testsuite. I'm open to suggestions here though.
Cheers, and thanks,
Ralf
2008-08-08 Peter Rosin [EMAIL PROTECTED]
* tests/export.at [cygwin, mingw]: dllimport all imported
variables.
diff --git a/tests/export.at b/tests/export.at
index 73fb45f..4f9d012 100644
--- a/tests/export.at
+++ b/tests/export.at
@@ -104,21 +104,21 @@ AT_DATA(main.c,
#ifdef __cplusplus
extern C {
#endif
-extern int v1;
-extern int v3, v4;
+LIBA_SCOPE int v1;
+LIBA_SCOPE int v3, v4;
LIBA_SCOPE const int v5, v6;
-extern const char* v7;
-extern const char v8[];
+LIBA_SCOPE const char* v7;
+LIBA_SCOPE const char v8[];
extern int v9(void);
-extern int (*v10) (void);
-extern int (*v11) (void);
+LIBA_SCOPE int (*v10) (void);
+LIBA_SCOPE int (*v11) (void);
LIBA_SCOPE int (*const v12) (void);
#ifdef __cplusplus
}
#endif
typedef struct { int arr[1000]; } large;
-extern large v13, v14, v15;
+LIBA_SCOPE large v13, v14, v15;
int main (void)
{
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Tue, Aug 05, 2008 at 08:38:28AM CEST: Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught me. Again. What in the world is msvc doing in there? Somebody (Brian Dessent?) explained it nicely, recently on some mailing list that I skim; I forgot where, though, sorry. IIRC it denotes the MSVCRT runtime as opposed to the older CRTDLL one. Cheers, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Peter, * Peter Rosin wrote on Thu, Aug 07, 2008 at 02:10:41PM CEST: Peter Rosin skrev: To fix the test failure on the MinGW cross compile, it might be enough to disable the nocase stuff in libtool.m4 for cross compiles (take the default branch in the case $host_os statement, near the end of _LT_CHECK_MAGIC_METHOD). This should cause a skip of the offending test. Like this patch. Can you verify if it works for i586-mingw32msvc-gcc? Yes it works but ... 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD): Disable nocase handling for cross compiles. +file_magic_glob= +want_nocaseglob=no +if test $build = $host; then + case $host_os in + cygwin* | mingw* | pw32*) What if build is cygwin* and host is mingw*, for example? Thanks, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Peter, * Peter Rosin wrote on Thu, Aug 07, 2008 at 10:10:29AM CEST: The previous patch was not enough, program linking happened in more than one place. Here's a new patch that fixes that and also adds the postlink_cmds variable as mentioned above. This patch actually fixes all mainfest problems. Tests 39 and 40 now succeed, but 29 still fails, but 29 now stumbles later when the MSVC toolchain can't handle static/shared linking of non-libtool libraries. (The static library is always selected for non-libtool libs, as it gets the preferred name, foo.lib. The import lib gets the name foo-0.lib and is only found if there is a libfoo.la) That's definitely better than what we had before. Does this BTW mean that the manifest file ends up being part of the .exe and thus needs not be explicitly installed and uninstalled? That would be nice. 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds: New tag variable. [ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a resource. (_LT_LANG_CXX_CONFIG): Likewise. * libltdl/config/ltmain.m4sh (func_mode_link): After linking a program, replace @OUTPUT@ in $postlink_cmds and then execute the commands. Not so bad; can we rely on 'mt' being present on all systems that have cl? Have you tried this patch on a setup where the program is relinked at install time (does this ever happen with cl)? Thanks, Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: * Peter Rosin wrote on Tue, Aug 05, 2008 at 08:38:28AM CEST: Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught me. Again. What in the world is msvc doing in there? Somebody (Brian Dessent?) explained it nicely, recently on some mailing list that I skim; I forgot where, though, sorry. IIRC it denotes the MSVCRT runtime as opposed to the older CRTDLL one. That would be this list... :-) BTW, thanks to Brian for the explanation (I never responded, sorry about that). Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: Hi Peter, * Peter Rosin wrote on Thu, Aug 07, 2008 at 10:10:29AM CEST: The previous patch was not enough, program linking happened in more than one place. Here's a new patch that fixes that and also adds the postlink_cmds variable as mentioned above. This patch actually fixes all mainfest problems. Tests 39 and 40 now succeed, but 29 still fails, but 29 now stumbles later when the MSVC toolchain can't handle static/shared linking of non-libtool libraries. (The static library is always selected for non-libtool libs, as it gets the preferred name, foo.lib. The import lib gets the name foo-0.lib and is only found if there is a libfoo.la) That's definitely better than what we had before. Does this BTW mean that the manifest file ends up being part of the .exe and thus needs not be explicitly installed and uninstalled? That would be nice. Yes, the mt command embeds the manifest as a resource, so nothing extra to install. 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds: New tag variable. [ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a resource. (_LT_LANG_CXX_CONFIG): Likewise. * libltdl/config/ltmain.m4sh (func_mode_link): After linking a program, replace @OUTPUT@ in $postlink_cmds and then execute the commands. Not so bad; can we rely on 'mt' being present on all systems that have cl? Have you tried this patch on a setup where the program is relinked at install time (does this ever happen with cl)? Hi Ralf, No, the manifest was introduced in MSVC 7 or 8 or something. MSVC 6 doesn't generate any manifests. That's one reason for the postlink_cmds to have if test -f @[EMAIL PROTECTED]; That way, mt is only tried if there is a manifest file to embed, which also covers the case when the manifest file isn't needed (and thus not generated). If MSVC has generated a manifest, it better also have mt. It might be a problem if you build inside the src tree and a foo.exe.manifest is part of the source tree, and the .exe isn't generated in the .libs subdir. I guess you just shouldn't do that. Doctor, it hurts when I etc... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: Hi Peter, * Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST: Peter Rosin skrev: 31: export.at:25 Export test Exporting variables. This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are still happy. Is there any reason for not __declspec(dllimport)ing all these variables? Yes: the auto-dll-import feature (was it named that?) from GCC on Cygwin and MinGW is happy to import all these variables automatically. I would like to somehow ensure that we expose this auto-import feature; IOW, that we don't explicitly dllimport these variables. That way code that is not portable to MSVC anyway, can rely on not needing these annotations. Sorry to be such a pain on this point, but the GNU Coding Standards explicitly allow developers to not go out of their way in making stuff work on w32, and as such they come to expect that things work smoothly without these kinds of annotations (and I for one would like to be able to pinpoint where exactly the limits are). So can we do something like this in the test, what do you think? /* w32 fun. With GCC, you can have auto-import, which will work for * functions and non-const variables. With MSVC, you have to explicitly * import all variables. Depending on the amount of portability, you * need these annotations: LIBA_SCOPE for GCC, and also LIBA_SCOPE_VAR * for MSVC. Of course you can merge both to one, this test only avoids * that in order to expose the auto-import feature on Cygwin. * * For users, it's best tor realize that they should not provide any * non-function API at all. */ #if defined(LIBA_DLL_IMPORT) # if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__) #define LIBA_SCOPE extern __declspec(dllimport) # if defined(_MSVC) #define LIBA_SCOPE_VAR LIBA_SCOPE # endif # endif #endif #if !defined(LIBA_SCOPE) # define LIBA_SCOPE extern #endif #if !defined(LIBA_SCOPE_VAR) # define LIBA_SCOPE_VAR extern #endif and then add only LIBA_SCOPE_VAR annotations? If you agree, then a patch to the pr-msvc-support branch to this end is preapproved (you know how to push changes to a branch?) I'm sure I can read up on that in a number of git resources on the web. Is there anything I should be aware of that is special for libtool? But feel free to recommended a git tutorial... I haven't yet decided for myself whether I would like to see this split-up in the other test failures too, but I would definitely like to see it in export.at. Maybe in stresstest.at too, but not in the old-style testsuite. I'm open to suggestions here though. dllimport is only needed on variables, functions work just fine to import on MSVC as well (at least I think so). So the naming LIBA_SCOPE and LIBA_SCOPE_VAR is perhaps a bit misleading since they are both used for variables. Also, in what cases do you need the dllimport for gcc? I don't seen any pattern. Sure, const seems to be involved, but if not dllimporting variables doesn't always work, isn't it a support nightmare to only recommend dllimport when it's desperately needed? Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Ralf Wildenhues skrev: Hi Peter, * Peter Rosin wrote on Fri, Aug 08, 2008 at 11:42:11AM CEST: Peter Rosin skrev: 31: export.at:25 Export test Exporting variables. This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are still happy. Is there any reason for not __declspec(dllimport)ing all these variables? Yes: the auto-dll-import feature (was it named that?) from GCC on Cygwin and MinGW is happy to import all these variables automatically. I would like to somehow ensure that we expose this auto-import feature; IOW, that we don't explicitly dllimport these variables. That way code that is not portable to MSVC anyway, can rely on not needing these annotations. Sorry to be such a pain on this point, but the GNU Coding Standards explicitly allow developers to not go out of their way in making stuff work on w32, and as such they come to expect that things work smoothly without these kinds of annotations (and I for one would like to be able to pinpoint where exactly the limits are). So can we do something like this in the test, what do you think? /* w32 fun. With GCC, you can have auto-import, which will work for * functions and non-const variables. With MSVC, you have to explicitly * import all variables. Depending on the amount of portability, you * need these annotations: LIBA_SCOPE for GCC, and also LIBA_SCOPE_VAR * for MSVC. Of course you can merge both to one, this test only avoids * that in order to expose the auto-import feature on Cygwin. * * For users, it's best tor realize that they should not provide any * non-function API at all. */ #if defined(LIBA_DLL_IMPORT) # if defined(_WIN32) || defined(WIN32) || defined(__CYGWIN__) #define LIBA_SCOPE extern __declspec(dllimport) # if defined(_MSVC) #define LIBA_SCOPE_VAR LIBA_SCOPE # endif # endif #endif #if !defined(LIBA_SCOPE) # define LIBA_SCOPE extern #endif #if !defined(LIBA_SCOPE_VAR) # define LIBA_SCOPE_VAR extern #endif and then add only LIBA_SCOPE_VAR annotations? If you agree, then a patch to the pr-msvc-support branch to this end is preapproved (you know how to push changes to a branch?) I'm sure I can read up on that in a number of git resources on the web. Is there anything I should be aware of that is special for libtool? But feel free to recommended a git tutorial... Ok, managed to push this patch. I think anyway... I haven't yet decided for myself whether I would like to see this split-up in the other test failures too, but I would definitely like to see it in export.at. Maybe in stresstest.at too, but not in the old-style testsuite. I'm open to suggestions here though. dllimport is only needed on variables, functions work just fine to import on MSVC as well (at least I think so). So the naming LIBA_SCOPE and LIBA_SCOPE_VAR is perhaps a bit misleading since they are both used for variables. Also, in what cases do you need the dllimport for gcc? I don't seen any pattern. Sure, const seems to be involved, but if not dllimporting variables doesn't always work, isn't it a support nightmare to only recommend dllimport when it's desperately needed? I was confused by const char v8[] which is apparently dll-auto-imported by gcc even if it's const. Oh well, I thought a bit about it and you can view it as if LIBA_SCOPE_VAR is used for variables that truely are variable (i.e. non-const). Please let me know if I got anything wrong in the push. Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev:
31: export.at:25 Export test
Exporting variables.
This patch fixes the above failure for MSVC. Cygwin/gcc and MinGW are
still happy. Is there any reason for not __declspec(dllimport)ing all
these variables?
Cheers,
Peter
2008-08-08 Peter Rosin [EMAIL PROTECTED]
* tests/export.at [cygwin, mingw]: dllimport all imported
variables.
diff --git a/tests/export.at b/tests/export.at
index 73fb45f..4f9d012 100644
--- a/tests/export.at
+++ b/tests/export.at
@@ -104,21 +104,21 @@ AT_DATA(main.c,
#ifdef __cplusplus
extern C {
#endif
-extern int v1;
-extern int v3, v4;
+LIBA_SCOPE int v1;
+LIBA_SCOPE int v3, v4;
LIBA_SCOPE const int v5, v6;
-extern const char* v7;
-extern const char v8[];
+LIBA_SCOPE const char* v7;
+LIBA_SCOPE const char v8[];
extern int v9(void);
-extern int (*v10) (void);
-extern int (*v11) (void);
+LIBA_SCOPE int (*v10) (void);
+LIBA_SCOPE int (*v11) (void);
LIBA_SCOPE int (*const v12) (void);
#ifdef __cplusplus
}
#endif
typedef struct { int arr[1000]; } large;
-extern large v13, v14, v15;
+LIBA_SCOPE large v13, v14, v15;
int main (void)
{
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev:
Peter Rosin skrev:
Ralf Wildenhues skrev:
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
29: static.at:68 static linking flags for programs
m-all-static.exe.manifest isn't installed
What does the manifest file do?
The manifest is an XML file that describes how the executable should
be run. In this case it contains a hint where the side-by-side (SxS)
assembly containing the C runtime (msvcrt80.dll) is. The manifest can
also specify if a file should be executed with elevated priviliges (or
not).
I'm no manifest guru, so the above is perhaps not 100% accurate.
Side note, the mainfest could perhaps be used to support some version
of hardcode_libdir?
The crude fix is to (un)install the mainfest file, the nice fix
is to embed it as a resource in the executable using the manifest
tool (mt.exe).
Here's a patch to fix the manifest failures. Maybe this should be
wrapped up in a postlink_cmds variable instead to match the existing
prelink_cmds?
Replying to self as usual, sorry about the mail flood...
The previous patch was not enough, program linking happened in more than
one place. Here's a new patch that fixes that and also adds the
postlink_cmds variable as mentioned above.
This patch actually fixes all mainfest problems. Tests 39 and 40 now
succeed, but 29 still fails, but 29 now stumbles later when the MSVC
toolchain can't handle static/shared linking of non-libtool libraries.
(The static library is always selected for non-libtool libs, as it gets
the preferred name, foo.lib. The import lib gets the name foo-0.lib and
is only found if there is a libfoo.la)
2008-08-07 Peter Rosin [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) postlink_cmds:
New tag variable.
[ cygwin, mingw, cegcc ] cl*: Embed the manifest file as a
resource.
(_LT_LANG_CXX_CONFIG): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): After linking
a program, replace @OUTPUT@ in $postlink_cmds and then execute
the commands.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 35ae02f..b78d7ac 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7340,6 +7340,11 @@ EOF
exit_status=0
func_show_eval $link_command 'exit_status=$?'
+ if test -n $postlink_cmds; then
+ postlink_cmds=`$ECHO X$postlink_cmds | $Xsed -e '[EMAIL
PROTECTED]@%'$output'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
# Delete the generated files.
if test -f $output_objdir/${outputname}S.${objext}; then
func_show_eval '$RM $output_objdir/${outputname}S.${objext}'
@@ -7385,6 +7390,12 @@ EOF
$opt_dry_run || $RM $output
# Link the executable and exit
func_show_eval $link_command 'exit $?'
+
+ if test -n $postlink_cmds; then
+ postlink_cmds=`$ECHO X$postlink_cmds | $Xsed -e '[EMAIL
PROTECTED]@%'$output'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
exit $EXIT_SUCCESS
fi
@@ -7418,6 +7429,11 @@ EOF
func_show_eval $link_command 'exit $?'
+ if test -n $postlink_cmds; then
+ postlink_cmds=`$ECHO X$postlink_cmds | $Xsed -e '[EMAIL
PROTECTED]@%'$output_objdir/$outputname'%g'`
+ func_execute_cmds $postlink_cmds 'exit $?'
+ fi
+
# Now create the wrapper script.
func_verbose creating $output
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 37c0f71..bd71b88 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4812,6 +4812,10 @@ _LT_EOF
_LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
_LT_TAGVAR(compile_tag, $1)=-TC
_LT_TAGVAR(dashl_xform, $1)='s/\(.*\)/\1.lib/'
+ _LT_TAGVAR(postlink_cmds, $1)='if test -e @[EMAIL PROTECTED]; then
+ mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL
PROTECTED];
+ $RM @[EMAIL PROTECTED];
+ fi'
;;
*)
# Assume MSVC wrapper
@@ -5356,6 +5367,8 @@ _LT_TAGDECL([], [include_expsyms], [1],
[Symbols that must always be exported])
_LT_TAGDECL([], [prelink_cmds], [2],
[Commands necessary for linking programs (against libraries) with
templates])
+_LT_TAGDECL([], [postlink_cmds], [2],
+[Commands necessary for finishing linking programs])
_LT_TAGDECL([], [file_list_spec], [1],
[Specify filename containing input files])
_LT_TAGDECL([], [dashL_envvar], [1],
@@ -5803,6 +5816,10 @@ if test $_lt_caught_CXX_error != yes; then
_LT_TAGVAR(old_postinstall_cmds, $1)='chmod 644 $oldlib'
_LT_TAGVAR(compile_tag, $1)=-TP
_LT_TAGVAR(dashl_xform, $1)='s/\(.*\)/\1.lib/'
+ _LT_TAGVAR(postlink_cmds, $1)='if test -e @[EMAIL PROTECTED]; then
+ mt -manifest @[EMAIL PROTECTED] -outputresource:@[EMAIL
PROTECTED];
+ $RM @[EMAIL PROTECTED];
+ fi'
;;
*)
# g++
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Ralf Wildenhues skrev: * Peter Rosin wrote on Mon, Aug 04, 2008 at 03:51:29PM CEST: Ralf Wildenhues skrev: I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs because the test fails for me on a GNU/Linux - MinGW cross compile (using i586-mingw32msvc-gcc): libFOO is found but -lfoo is not rewritten to -lFoo. I don't know if it should be, but either the test or the implementation needs fixing. Test works fine on the MSYS/MSVC pair. I suspect if fails bacause the build system FS is case sensitive? Cross compile is not my top priority. Well, I certainly don't think we need to put much work in supporting a cross compile setup where MSVC is the compiler. However, that is not what I was writing about: the above is a (quite widely used) GCC cross that runs on GNU/Linux and produces code for w32, using MSYS stub libraries and so on. It's not nice to introduce a new test failure for this setup. That being said, I'm open to whether the code or the test should be fixed, or the test should simply be skipped in this case. Ideally we should take into account that Windows shares may be mounted on unixy systems as well, such that maybe there is some benefit to be had from nocase support. (OTOH, I have little experience with such setups; maybe the testsuite test would actually succeed there? Then a skip on a case-sensitive system seems appropriate to me) Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught me. Again. What in the world is msvc doing in there? Just to reiterate the underlying reason for this code, MSVC has a bunch of system libs named e.g. DDRAW.LIB, while MinGW has the corresponding import library as libddraw.dll.a. So, the libtool user can't use a single canonical name (-lDDRAW and -lddraw are equally correct). At the same time libtool has code that needs to find the exact file, this code needs to be made case insensitive for things to work smoothly. So, I don't think the benefit is all that great on unixy systems, since there wouldn't be any question as to whether -lFoo or -lfoo is correct. To fix the test failure on the MinGW cross compile, it might be enough to disable the nocase stuff in libtool.m4 for cross compiles (take the default branch in the case $host_os statement, near the end of _LT_CHECK_MAGIC_METHOD). This should cause a skip of the offending test. Like this patch. Can you verify if it works for i586-mingw32msvc-gcc? Cheers, Peter 2008-08-07 Peter Rosin [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD): Disable nocase handling for cross compiles. diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 37c0f71..ccd541a 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -3237,21 +3237,19 @@ tpf*) esac ]) -case $host_os in -cygwin* | mingw* | pw32*) - if ( shopt | grep nocaseglob ) /dev/null 21; then -file_magic_glob= -want_nocaseglob=yes - else -file_magic_glob=`echo aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ | $SED -e s/\(..\)/s\/[[\1]]\/[[\1]]\/g;/g` -want_nocaseglob=no - fi - ;; -*) - file_magic_glob= - want_nocaseglob=no - ;; -esac +file_magic_glob= +want_nocaseglob=no +if test $build = $host; then + case $host_os in + cygwin* | mingw* | pw32*) +if ( shopt | grep nocaseglob ) /dev/null 21; then + want_nocaseglob=yes +else + file_magic_glob=`echo aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ | $SED -e s/\(..\)/s\/[[\1]]\/[[\1]]\/g;/g` +fi +;; + esac +fi file_magic_cmd=$lt_cv_file_magic_cmd deplibs_check_method=$lt_cv_deplibs_check_method
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev:
Ralf Wildenhues skrev:
*snip*
Please try the patch below for simplistic at-file support with $NM.
While testing, I set nm_file_list_spec to '@' and always_export_symbols
to yes on GNU/Linux, and saw no test failure, probably because my nm
also understands '@'. :-)
(IOW, we could enable that for when 'nm --help' lists @FILE.)
Probably the setting of nm_file_list_spec should be moved to where $NM
is set; not sure, as this is actually a Windows feature, not a $NM one.
I tried the patch and it fixes the old testsuite pdemo test, excellent!
But pdemo still fails due to an exported variable. Sigh. Why does each and
every damn test (well, almost) have to export a variable when that's listed
as not portable in the docs? Seems masochistic to me...
From my point of view, you may push the ltmain part of the patch. I'll
test
any improved m4 code when you have settled on how to enable it. However,
your idea to check the help output will not work, dumpbin -? doesn't
indicate any support whatsoever for @.
Maybe hook into the existing
AC_CACHE_CHECK([the name lister ($NM) interface], [lt_cv_...
and add
if test $lt_cv_nm_interface = MS dumpbin; then
_LT_TAGVAR(nm_file_list_spec, $1)='@'
fi
to the end of LT_PATH_NM?
But I don't know it's too early to use _LT_DECL/_LT_TAGVAR?
It works to have it in LT_PATH_NM, so that's where I'd put it. Like
the attached patch...
Also, I tested the patch on the new testsuite and with this patch
I get the desired behaviour in the cmdline_wrap.at test (73).
Cheers,
Peter
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 35ae02f..29f7fba 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6613,14 +6613,30 @@ EOF
$opt_dry_run || $RM $export_symbols
cmds=$export_symbols_cmds
save_ifs=$IFS; IFS='~'
- for cmd in $cmds; do
+ for cmd1 in $cmds; do
IFS=$save_ifs
- eval cmd=\$cmd\
+ eval cmd=\$cmd1\
func_len $cmd
len=$func_len_result
if test $len -lt $max_cmd_len || test $max_cmd_len -le -1;
then
func_show_eval $cmd 'exit $?'
skipped_export=false
+ elif test -n $nm_file_list_spec; then
+ output_la=`$ECHO X$output | $Xsed -e $basename`
+ save_libobjs=$libobjs
+ save_output=$output
+ output=${output_objdir}/${output_la}.nm
+ libobjs=$nm_file_list_spec$output
+ delfiles=$delfiles $output
+ func_verbose creating $NM input file list: $output
+ for obj in $save_libobjs; do
+ $ECHO $obj
+ done $output
+ eval cmd=\$cmd1\
+ func_show_eval $cmd 'exit $?'
+ output=$save_output
+ libobjs=$save_libobjs
+ skipped_export=false
else
# The command line is too long to execute in one step.
func_verbose using reloadable object file for export list...
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 37c0f71..10a8c95 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -3346,6 +3346,13 @@ AC_CACHE_CHECK([the name lister ($NM) interface],
[lt_cv_nm_interface],
lt_cv_nm_interface=MS dumpbin
fi
rm -f conftest*])
+
+if test $lt_cv_nm_interface = MS dumpbin; then
+ _LT_TAGVAR(nm_file_list_spec, $1)='@'
+fi
+
+_LT_DECL([], [nm_file_list_spec], [1],
+[Specify filename containing input files for $NM])
])# LT_PATH_NM
# Old names:
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin wrote: Ah, ok. That's bad. The misleading name i586-mingw32msvc-gcc caught me. Again. What in the world is msvc doing in there? I believe this is to denote that it defaults to the MSVCRT runtime, as opposed to the very old CRTDLL one, which the MinGW toolchain still provides components for: startup object for executable: crt1.o (CRTDLL) vs. crt2.o (MSVCRT) startup object for shared library: dllcrt1.o (CRTDLL) vs. dllcrt2.o (MSVCRT) import lib for runtime: libcrtdll.a vs. libmsvcrt.a lib supplying aliases of common ANSI functions without underscores: libcoldname.a vs. libmoldname.a So I guess they are just being explicit in their target name so that if they ever wanted or needed to offer a toolchain that defaults to CRTDLL it would not clash. Not that I can imagine anyone wanting that. Brian
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Peter Rosin skrev: Attached, I'll work through all the failures to try to find out why they fail... 16: duplicate_conv.at:25 duplicate convenience archive names MS link doesn't have reloadable objects (i.e. like ld -r). 24: link-order.at:26 Link order test. Exporting int c variable. 25: link-order2.at:46 Link order of deplibs. Don't know. Should defbindir=`pwd`/lib be defbindir=`pwd`/bin in link-order2.at? Maybe the MSVC fixup of -L options is too coarse? 29: static.at:68 static linking flags for programs m-all-static.exe.manifest isn't installed 30: static.at:357 ccache -all-static cl.exe spews out a banner on stderr which isn't [ignore]d 31: export.at:25 Export test Exporting variables. 37: localization.at:25 localized compiler messages CR in stdout and CR/NL in expected-stdout 39: destdir.at:48 Simple DESTDIR install m.exe.manifest isn't installed 40: destdir.at:75 DESTDIR with in-package deplibs m.exe.manifest isn't installed 46: lt_dladvise.at:28 lt_dlopenadvise library loading -avoid-version causes the names of the import lib and the static lib to be the same. But something elseTM also seems bad... 47: need_lib_prefix.at:25 enforced lib prefix -avoid-version problem from 46, but also needs -no-undefined. 72: stresstest.at:31 Link option thorough search test Automatic path conversion in MSYS doesn't kick in for the argument -OUT:/some/absolute/path so lib.exe barfs. 73: cmdline_wrap.at:28 Run tests with low max_cmd_len I just ran out of steam... Cheers, Peter
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Tue, Aug 05, 2008 at 10:38:14AM CEST:
Peter Rosin skrev:
Attached, I'll work through all the failures to try to find out why
they fail...
16: duplicate_conv.at:25 duplicate convenience archive names
MS link doesn't have reloadable objects (i.e. like ld -r).
Should be fixed by at-file support I hope.
25: link-order2.at:46 Link order of deplibs.
Don't know. Should defbindir=`pwd`/lib be defbindir=`pwd`/bin in
link-order2.at? Maybe the MSVC fixup of -L options is too coarse?
Forget about this failure for now. The link-order tests all suffer a
bit from being too system-specific.
29: static.at:68 static linking flags for programs
m-all-static.exe.manifest isn't installed
What does the manifest file do?
30: static.at:357 ccache -all-static
cl.exe spews out a banner on stderr which isn't [ignore]d
I think that banner should just be ignored.
46: lt_dladvise.at:28 lt_dlopenadvise library loading
-avoid-version causes the names of the import lib and the static
lib to be the same. But something elseTM also seems bad...
Several issues:
- the test is somewhat broken (also on other systems)
- maybe we need to forbid enabling both static and shared at the same
time
47: need_lib_prefix.at:25 enforced lib prefix
-avoid-version problem from 46, but also needs -no-undefined.
Sigh.
72: stresstest.at:31 Link option thorough search test
Automatic path conversion in MSYS doesn't kick in for the argument
-OUT:/some/absolute/path so lib.exe barfs.
Not the biggest problem.
73: cmdline_wrap.at:28 Run tests with low max_cmd_len
I just ran out of steam...
That's where I hope most of the failures are either
- failing for the same reason the non-low test is failing,
- and/or fixed with at-file support.
Please try the patch below for simplistic at-file support with $NM.
While testing, I set nm_file_list_spec to '@' and always_export_symbols
to yes on GNU/Linux, and saw no test failure, probably because my nm
also understands '@'. :-)
(IOW, we could enable that for when 'nm --help' lists @FILE.)
Probably the setting of nm_file_list_spec should be moved to where $NM
is set; not sure, as this is actually a Windows feature, not a $NM one.
Cheers,
Ralf
2008-08-05 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) nm_file_list_spec:
New tag variable.
[ cygwin, mingw, cegcc ] cl*: Set to '@'.
(_LT_LANG_CXX_CONFIG): Likewise.
* libltdl/config/ltmain.m4sh (func_mode_link): When
nm_file_list_spec is nonempty, use it to avoid skipped_export.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 35ae02f..29f7fba 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -6613,14 +6613,30 @@ EOF
$opt_dry_run || $RM $export_symbols
cmds=$export_symbols_cmds
save_ifs=$IFS; IFS='~'
- for cmd in $cmds; do
+ for cmd1 in $cmds; do
IFS=$save_ifs
- eval cmd=\$cmd\
+ eval cmd=\$cmd1\
func_len $cmd
len=$func_len_result
if test $len -lt $max_cmd_len || test $max_cmd_len -le -1;
then
func_show_eval $cmd 'exit $?'
skipped_export=false
+ elif test -n $nm_file_list_spec; then
+ output_la=`$ECHO X$output | $Xsed -e $basename`
+ save_libobjs=$libobjs
+ save_output=$output
+ output=${output_objdir}/${output_la}.nm
+ libobjs=$nm_file_list_spec$output
+ delfiles=$delfiles $output
+ func_verbose creating $NM input file list: $output
+ for obj in $save_libobjs; do
+ $ECHO $obj
+ done $output
+ eval cmd=\$cmd1\
+ func_show_eval $cmd 'exit $?'
+ output=$save_output
+ libobjs=$save_libobjs
+ skipped_export=false
else
# The command line is too long to execute in one step.
func_verbose using reloadable object file for export list...
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 37c0f71..c8b29ce 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4785,6 +4785,7 @@ _LT_EOF
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=yes
_LT_TAGVAR(file_list_spec, $1)='@'
+ _LT_TAGVAR(nm_file_list_spec, $1)='@'
# Tell ltmain to make .lib files, not .a files.
libext=lib
# Tell ltmain to make .dll files, not .so files.
@@ -5358,6 +5359,8 @@ _LT_TAGDECL([], [prelink_cmds], [2],
[Commands necessary for linking programs (against libraries) with
templates])
_LT_TAGDECL([], [file_list_spec], [1],
[Specify filename containing input files])
+_LT_DECL([], [nm_file_list_spec], [1],
+[Specify filename containing input
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Ralf Wildenhues skrev: Hi Peter, yeah, replying to a mail that's 5 months old: * Peter Rosin wrote on Tue, Mar 04, 2008 at 11:23:48AM CET: I have no problems with this patch series on either mingw, nor cygwin. Great. I've rebased your patches against current git Libtool, and put them in a git branch, named pr-msvc-support, which I pushed to savannah's git repo. You should be able to get it with git clone git://git.sv.gnu.org/libtool.git git branch pr-msvc-support origin/pr-msvc-support git checkout pr-msvc-support NOTE! This git branch may be rewound at times, rebased against a newer master, or whatnot else. I don't think that in practice it will need rewinding a lot, and I hope we can get by with only reworking patches incrementally in order to get patches cherry picked into master. But all bets are off, and I don't want anybody to come back crying later. That being said, of course I won't rewind the branch without prior notification or asking, depending on who else wants to work on the branch. Great, thanks! I've fixed a couple of trivial typos in the patches, a couple of instances of test $foo == $bar (needs to be = instead of ==). + if shopt | grep nocaseglob 21 /dev/null; then I changed this to: + if ( shopt | grep nocaseglob ) /dev/null 21; then to really drop stderr, and silence ash as well. I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs because the test fails for me on a GNU/Linux - MinGW cross compile (using i586-mingw32msvc-gcc): libFOO is found but -lfoo is not rewritten to -lFoo. I don't know if it should be, but either the test or the implementation needs fixing. Test works fine on the MSYS/MSVC pair. I suspect if fails bacause the build system FS is case sensitive? Cross compile is not my top priority. Annotated testsuite with these patches: On MSYS and MSVC 12.00.8804 (MSVC 6) with: ../configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM=dumpbin -symbols AR=lib STRIP=: RANLIB=: F77=no FC=no The problems with the exported variables can be solved with the right amount of declspecs. I will not work on the other problems until basic MSVC support is commited. I think there have been various patches floating around for the exported variables things. You can probably search the list archives for them. Maybe you've even written some of them. What I'd ideally like to see here is a patch that - isn't ugly (yeah ;-) - keeps system-specifics abstracted away as much as possible, - but still allows the intermediate (non-expert) user to understand that these annotations are needed for plain MSVC support only (i.e., for packages which are deeply rooted in unixy land, that may be ported to Cygwin but never to MinGW or MSVC, there is no need for these annotations). Right... PASS: tests/demo-conf.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) FAIL: tests/demo-deplibs.test (assumes oldlibs are named lib???.a) Let's not worry about this for now; this is clearly a testsuite issue. (Of course the corresponding real-world issue exists, but may be worked around using libtool libraries everywhere). Speaking of which, maybe a manual chapter for Windows specifics is in order? Probably. FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r)) That indicates a bug in libtool.m4: file_list_spec isn't working right. With too many files on the command line, it should use an at file (@) to specify them. (Maybe the corresponding code in ltmain needs adjustment, I don't know.) No, I don't think this is as simple as a libtool.m4 bug. This is something that's not implemented in ltmain. What's going on is that a cmd is too long during the preparation of the list of exported symbols. This causes skipped_export=: which is bad on MSVC, since it unconditionally ends up in the func_verbose creating reloadable object files... branch. The functionallity behind ld -r is not available in MS link, so $reload_cmds may not be used at all but is used in this branch and everything goes belly up. And MSVC needs the list of exported symbols, or it doesn't export anything. Well, it will obviously export stuff marked with declspecs, but that's what we're trying to avoid (and it works fine for functions, but not variables, as long as the the $reload_cmds branch isn't taken as above). This issue should be fixed before the patches go to master. Ok. SKIP: tests/demo-hardcode.test (...but fails here, using $CC w/o going through libtool) Don't worry about this for now. Could you run make check-local (you may have to set TESTSUITEFLAGS=CC=cl ... accordingly) and post tests/testsuite.log? Attached, I'll work through all the failures to try to find out why they fail... Cheers, Peter testsuite.log.gz Description: GNU Zip compressed data
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
* Peter Rosin wrote on Mon, Aug 04, 2008 at 03:51:29PM CEST: Ralf Wildenhues skrev: I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs because the test fails for me on a GNU/Linux - MinGW cross compile (using i586-mingw32msvc-gcc): libFOO is found but -lfoo is not rewritten to -lFoo. I don't know if it should be, but either the test or the implementation needs fixing. Test works fine on the MSYS/MSVC pair. I suspect if fails bacause the build system FS is case sensitive? Cross compile is not my top priority. Well, I certainly don't think we need to put much work in supporting a cross compile setup where MSVC is the compiler. However, that is not what I was writing about: the above is a (quite widely used) GCC cross that runs on GNU/Linux and produces code for w32, using MSYS stub libraries and so on. It's not nice to introduce a new test failure for this setup. That being said, I'm open to whether the code or the test should be fixed, or the test should simply be skipped in this case. Ideally we should take into account that Windows shares may be mounted on unixy systems as well, such that maybe there is some benefit to be had from nocase support. (OTOH, I have little experience with such setups; maybe the testsuite test would actually succeed there? Then a skip on a case-sensitive system seems appropriate to me) FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r)) That indicates a bug in libtool.m4: file_list_spec isn't working right. With too many files on the command line, it should use an at file (@) to specify them. (Maybe the corresponding code in ltmain needs adjustment, I don't know.) No, I don't think this is as simple as a libtool.m4 bug. This is something that's not implemented in ltmain. What's going on is that a cmd is too long during the preparation of the list of exported symbols. This causes skipped_export=: which is bad on MSVC, since it unconditionally ends up in the func_verbose creating reloadable object files... branch. The functionallity behind ld -r is not available in MS link, so $reload_cmds may not be used at all but is used in this branch and everything goes belly up. And MSVC needs the list of exported symbols, or it doesn't export anything. Well, it will obviously export stuff marked with declspecs, but that's what we're trying to avoid (and it works fine for functions, but not variables, as long as the the $reload_cmds branch isn't taken as above). Ah, ok; thanks. Then maybe ltmain should not skip export in the first place if we have the needed at-file support. This could fix some of your test failures, too. Thanks! Ralf
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
Hi Peter, yeah, replying to a mail that's 5 months old: * Peter Rosin wrote on Tue, Mar 04, 2008 at 11:23:48AM CET: I have no problems with this patch series on either mingw, nor cygwin. Great. I've rebased your patches against current git Libtool, and put them in a git branch, named pr-msvc-support, which I pushed to savannah's git repo. You should be able to get it with git clone git://git.sv.gnu.org/libtool.git git branch pr-msvc-support origin/pr-msvc-support git checkout pr-msvc-support NOTE! This git branch may be rewound at times, rebased against a newer master, or whatnot else. I don't think that in practice it will need rewinding a lot, and I hope we can get by with only reworking patches incrementally in order to get patches cherry picked into master. But all bets are off, and I don't want anybody to come back crying later. That being said, of course I won't rewind the branch without prior notification or asking, depending on who else wants to work on the branch. I've fixed a couple of trivial typos in the patches, a couple of instances of test $foo == $bar (needs to be = instead of ==). + if shopt | grep nocaseglob 21 /dev/null; then I changed this to: + if ( shopt | grep nocaseglob ) /dev/null 21; then to really drop stderr, and silence ash as well. I've reformatted tests/nocase.at a bit, and sprinkled in more AT_CHECKs because the test fails for me on a GNU/Linux - MinGW cross compile (using i586-mingw32msvc-gcc): libFOO is found but -lfoo is not rewritten to -lFoo. I don't know if it should be, but either the test or the implementation needs fixing. Annotated testsuite with these patches: On MSYS and MSVC 12.00.8804 (MSVC 6) with: ../configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM=dumpbin -symbols AR=lib STRIP=: RANLIB=: F77=no FC=no The problems with the exported variables can be solved with the right amount of declspecs. I will not work on the other problems until basic MSVC support is commited. I think there have been various patches floating around for the exported variables things. You can probably search the list archives for them. Maybe you've even written some of them. What I'd ideally like to see here is a patch that - isn't ugly (yeah ;-) - keeps system-specifics abstracted away as much as possible, - but still allows the intermediate (non-expert) user to understand that these annotations are needed for plain MSVC support only (i.e., for packages which are deeply rooted in unixy land, that may be ported to Cygwin but never to MinGW or MSVC, there is no need for these annotations). PASS: tests/demo-conf.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) FAIL: tests/demo-deplibs.test (assumes oldlibs are named lib???.a) Let's not worry about this for now; this is clearly a testsuite issue. (Of course the corresponding real-world issue exists, but may be worked around using libtool libraries everywhere). Speaking of which, maybe a manual chapter for Windows specifics is in order? FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r)) That indicates a bug in libtool.m4: file_list_spec isn't working right. With too many files on the command line, it should use an at file (@) to specify them. (Maybe the corresponding code in ltmain needs adjustment, I don't know.) This issue should be fixed before the patches go to master. SKIP: tests/demo-hardcode.test (...but fails here, using $CC w/o going through libtool) Don't worry about this for now. Could you run make check-local (you may have to set TESTSUITEFLAGS=CC=cl ... accordingly) and post tests/testsuite.log? Cheers, and thanks a lot, Ralf
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #4, patch #6448 (project libtool): Peter, I've installed that patched libtool system-wide on gentoo/x86_64 laptop on which I'm doing my current gstreamer development, I'll be re-libtool everything with it and will report any issues. ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #2, patch #6448 (project libtool): Hi, I'd like to give my feedback on these 7 patches (applied against trunk svn). They work amazingly well, I have been compiling gstreamer and dependencies under msys using msvc... and I had to remove all the 'hacks' I previously added to the makefiles to make it compile properly. Apart from being libtool-ized, they don't require ANY makefile/configure modification to be compiled with msvc under msys (thanks for fixing all the cygwin vs msys issues also). Awesome work ! I don't know what more is needed to push these patches in, if you need more feedback, logs, etc... please ask. ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
Re: [patch #6448] [MSVC 7/7] Add MSVC Support
On Sat, 8 Mar 2008, Edward Hervey wrote: Hi, I'd like to give my feedback on these 7 patches (applied against trunk svn). Thanks for the useful feedback. This is good news. Awesome work ! I don't know what more is needed to push these patches in, if you need more feedback, logs, etc... please ask. The current plan is to address remaining issues found in the 2.2 release before any new functionality is added. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #3, patch #6448 (project libtool): Thanks very much for the feedback, I'm glad to hear about the success! Previously there has been requests to test how this patch series behaves on other systems (which are not supposed to be affected). So, you can help by checking for regressions on whatever other systems you have available. In particular, testing for regressions using the cccl script was requested, but I failed to get cccl to do anything useful in the libtool context. So, any cccl user out there could also help with testing. I think the lib-as-archiver patches (i.e. 1/7 and 6/7) are the most intrusive in the series and they should perhaps be held back. IIRC, the patches work well with AR=ar as well, so that would not hinder using MSVC as the compiler/linker. You can test that as well, if you like. Leaving out AR=lib should be equivalent to saying AR=ar. Cheers, Peter ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #1, patch #6448 (project libtool): I have no problems with this patch series on either mingw, nor cygwin. I have not found a functioning cccl to test with. I have tried both cccl 0.03 as found on sf.net and cccl 0.05 as found on http://tsunanet.net/~tsuna/cccl Niether cccl can even build libtool. I have tried to patch around the first few problems in cccl, but I can't see why I should fix cccl in order to check if it these patches break cccl. cccl is seriously broken, or please point me to a version of cccl that I should use. (I used cygwin and ../configure CC=cccl CXX=cccl LD=cccl F77=no FC=no GCJ=no) Annotated testsuite with these patches: On MSYS and MSVC 12.00.8804 (MSVC 6) with: ../configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM=dumpbin -symbols AR=lib STRIP=: RANLIB=: F77=no FC=no The problems with the exported variables can be solved with the right amount of declspecs. I will not work on the other problems until basic MSVC support is commited. PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/sh.test PASS: tests/suffix.test SKIP: tests/tagtrace.test PASS: tests/cdemo-static.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-static.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/depdemo-static.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/mdemo-static.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-conf.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-conf.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-unst.test FAIL: tests/demo-deplibs.test (assumes oldlibs are named lib???.a) PASS: tests/depdemo-conf.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-conf.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/mdemo-dryrun.test PASS: tests/mdemo2-conf.test PASS: tests/mdemo2-make.test PASS: tests/mdemo2-exec.test PASS: tests/pdemo-conf.test FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r)) SKIP: tests/pdemo-exec.test SKIP: tests/pdemo-inst.test PASS: tests/demo-nofast.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-unst.test PASS: tests/depdemo-nofast.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/demo-pic.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test PASS: tests/demo-nopic.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test PASS: tests/cdemo-shared.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-shared.test FAIL: tests/demo-make.test (exported variable, remove it fixes it...) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-hardcode.test (...but fails here, using $CC w/o going through libtool) SKIP: tests/demo-relink.test SKIP: tests/demo-noinst-link.test SKIP: tests/demo-unst.test PASS: tests/depdemo-shared.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-relink.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-shared.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-undef.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/tagdemo-static.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-conf.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-shared.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-undef.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test 10 of 79 tests failed (27 tests were not run) Please report to [EMAIL PROTECTED] ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
