On Fri, Aug 13, 2010 at 7:09 AM, Peter Rosin <p...@lysator.liu.se> wrote: > Hi Chris, > > Den 2010-08-13 12:26 skrev Christopher Hulbert: >> On Mon, Aug 9, 2010 at 3:55 PM, Peter Rosin <p...@lysator.liu.se> 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/automake-patc...@gnu.org/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 >
