Re: MSVC status

[Christopher Hulbert]

On Fri, Aug 13, 2010 at 7:09 AM, Peter Rosin <address@hidden> wrote:
> Hi Chris,
>
> Den 2010-08-13 12:26 skrev Christopher Hulbert:
>> On Mon, Aug 9, 2010 at 3:55 PM, Peter Rosin <address@hidden> wrote:
>>> Hi!
>>>
>>> Christopher Hulbert asked for some MSVC status in a private message,
>>> but I figured more people might be interested. So, I'm posting a
>>> testsuite log from libtool master.
>>>
>>> It was configured with:
>>>
>>> ../configure \
>>> CC="/c/cygwin/home/peda/automake/git/automake/lib/compile cl" CFLAGS="-MD
>>> -Zi -EHsc" \
>>> CXX="/c/cygwin/home/peda/automake/git/automake/lib/compile cl" CXXFLAGS="-MD
>>> -Zi -EHsc" \
>>> LD=link NM="dumpbin -symbols" STRIP=: \
>>> AR="/c/cygwin/home/peda/automake/git/automake/lib/archive lib" RANLIB=:
>>> F77=no FC=no GCJ=no
>>>
>>> Don't be fooled by /c/cygwin in the above paths, or in the log for that
>>> matter. This was all using MSYS/MSVC. /c/cygwin is just where the files
>>> live on my system.
>>>
>>> I do not have automake installed in my MSYS environment, so there are
>>> a fair number of skips caused by that. I also did not run the old
>>> testsuite as it has to many variables that are not imported correctly
>>> from dlls.
>>>
>>> The compile script above is from the master branch of automake, and
>>> the archive script is from this pending automake patch:
>>> http://www.mail-archive.com/address@hidden/msg02374.html
>>>
>>> (Note that the final name of the latter script might not be 'archive')
>>>
>>> Further, there are two things left todo, that were done in the old
>>> pr-msvc-support branch that I have identified so far.
>>>
>>> 1. libtool needs to support archivers with @FILE support, since
>>> libtool currently falls back to piecewise linking for long
>>> command lines. MSVC doesn't support piecewise linking. I have a
>>> patch sitting on disk that I fiddle with from time to time, expect
>>> it to appear on a list near you when the above pending automake
>>> patch is commited, if not sooner.
>>>
>>> 2. Support for other C++ file extensions, MSVC only handles .cpp
>>> files as C++ code without feeding it a hint. But this change is
>>> best done in the compile script so it's a thing for automake...
>>>
>>> Anyway, I have attached a full testsuite log.
>>
>> Attached are my logs. I am building from cygwin. I have not yet looked
>> into any of the failures. I believe your logs had 28 failures with 22
>> expected. I don't think all of our failures line up though. Note that
>> I ran it once without setting --host (testsuite.log.bz2), and once
>> setting --host=i686-pc-mingw32 (testsuite_cross.log.bz2).
>
> You will not get comparable results on Cygwin. MSYS has automatic
> path conversion when it invokes Windows binaries that simply isn't
> there in Cygwin.  So, you are in unsupported territory.  As an
> example, test 38 "Link order test" fails for you like this (quoting
> the interesting lines):
>
>
> libtool: link:  /apps/autotools/automake/lib/compile cl -o src/.libs/b-0.dll  
> src/.libs/b.obj      
> -L/apps/autotools/libtool/tests/testsuite.dir/038/old/lib 
> /apps/autotools/libtool/tests/testsuite.dir/038/old/lib/cee-0.lib 
> @src/.libs/b-0.dll.exp -Wl,-DLL
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 
> 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl -link -EXPORT:b_old
>
> cl : Command line warning D9002 : ignoring unknown option 
> '/apps/autotools/libtool/tests/testsuite.dir/038/old/lib/cee-0.lib'
> Microsoft (R) Incremental Linker Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> /out:src/.libs/b-0.dll
> -EXPORT:b_old
> -LIBPATH:C:/cygwin/apps/autotools/libtool/tests/testsuite.dir/038/old/lib
> -DLL
> src/.libs/b.obj
>   Creating library src/.libs/b-0.lib and object src/.libs/b-0.exp
> b.obj : error LNK2001: unresolved external symbol __imp__c
> src/.libs/b-0.dll : fatal error LNK1120: 1 unresolved externals
>
>
> Notice how MSVC can't find the absolute path:
> /apps/autotools/libtool/tests/testsuite.dir/038/old/lib/cee-0.lib
> MSYS would have converted that for you. Corresponding snippet when
> I run under MSYS:

Is there interest (besides mine) in libtool being able to use native
Windows compilers from cygwin. I just find cygwin easier to
use/maintain than mingw/msys.

In the branch I had been working on, I defined the libtool variable
link_search_path_spec=-LIBPATH: for native Windows compilers when host
was cygwin/mingw, and empty otherwise. Then in the -L flag parsing of
the libtool script, it would use $link_search_path_spec if non-empty,
and -L otherwise.

If it's interesting to others, I would like to get it to work with
current libtool and hopefully merged in, but I need help on how it
should be done (otherwise it will never be merged in). Is what I
previously did a good approach to this?

Peter: I think you are targeting mingw correct? I am targeting purely
native Windows. Is there actually any difference in these? Would it
make sense to have a windows host type (e.g. i686-pc-windows and
x86_64-pc-windows)?

Chris

>
>
> libtool: link:  /c/cygwin/home/peda/automake/git/automake/lib/compile cl -o 
> src/.libs/b-0.dll  src/.libs/b.obj      
> -L/c/cygwin/home/peda/libtool/git/libtool-msvc/msvc/tests/testsuite.dir/038/old/lib
>  
> /c/cygwin/home/peda/libtool/git/libtool-msvc/msvc/tests/testsuite.dir/038/old/lib/cee-0.lib
>  @src/.libs/b-0.dll.exp -Wl,-DLL
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 
> 80x86
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> cl -link -EXPORT:b_old
>
> Microsoft (R) Incremental Linker Version 8.00.50727.762
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> /out:src/.libs/b-0.dll
> -EXPORT:b_old
> -LIBPATH:c:/cygwin/home/peda/libtool/git/libtool-msvc/msvc/tests/testsuite.dir/038/old/lib
> -DLL
> src/.libs/b.obj
> c:/cygwin/home/peda/libtool/git/libtool-msvc/msvc/tests/testsuite.dir/038/old/lib/cee-0.lib
>   Creating library src/.libs/b-0.lib and object src/.libs/b-0.exp
>
>
> And then the test proceeds to successful completion. Notice how cl
> lists c:/cygwin/..../038/old/lib/cee-0.lib as input even if libtool
> never did anything with /c/cygwin/..../038/old/lib/cee-0.lib
>
> I expect many of your failures to be similar. In short, you need
> to use MSYS instead of Cygwin to get matching behaviour.
>
> Cheers,
> Peter
>