RE: MSYS+MSVC for libtool branch-2-0, take 7

[Peter Ekberg]

Ralf Wildenhues wrote:
> Hi Peter,
> 
> Something beforehand, I forgot to mention it earlier:
> You called successful `configure' without options the
> holy grail.  Please move away from this thought.

Ok.

*snip*

> * Peter Ekberg wrote on Mon, Aug 15, 2005 at 12:28:14PM CEST:
> > Ralf Wildenhues wrote:
> > > 
> > > Hrmpf.  We can do the -TC/-TP munging inside the libtool script,
> > > but people expect to be able to use $CXX as done in the tests.
> > > See, not everybody uses Automake, and these people cannot be 
> > > expected to use libtool for compilation of code which does not
> > > end up in a shared library.
> *snip*
> > > For the general case, I'm not certain which way is good:
> > > Set -TC in CXX, and override CXXLD, or set -TC in 
> per-target CPPFLAGS?
> > > The latter still won't work for mixed C/C++ code.  In any 
> > > case, the user
> > > will have to manually adapt if the package author did not 
> use .cpp.
> > 
> > Well, I didn't know about those tests when I figured fixing it
> > in the compile mode was the easiest.
> 
> That's one of the reasons I made you try the new test suite.

Yes, I figured as much when I tripped on it...

> > And since people apparently
> > also expect to link without libtool (see tests/demo-hardcode.test),
> 
> Well, look at this: there is an installed library by some random
> package, I write a program which uses it.  Why should the fact that
> the package author uses Libtool influence my use or non-use of it?
> (There is a difference to some extent, surely, but we don't want
> to force people to do one or the other.)

I don't see how the use of -TC and -TP in Libtool influences
the library user? The library user is very welcome to overcome
all compatibility problems solved by Libtool by some other means.
Isn't the bottom line that if they don't use Libtool, they will
not be as portable? So, if Libtool throws in an extra option in
compile mode to make it work more reliably, that can't be a bad
thing. And if Libtool strips those same flags in link mode to
make it work more reliably, that can't be bad either.

Then, if there is a way to solve a problem w/o depending on magic
in Libtool, all the better. And the way to do that in this case
is to rename your sources to .cpp and be done with it.

So, there is a way forward for non-Libtool users and for Libtool
users there is extra compatibilty magic.

That said, it's just that linking is so damn odd using MSVC, i.e.
no -L and no -l options, so linking w/o Libtool (or other wrapper)
is not likely to work anyway for the non-trivial case, (see above
demo-hardcode test).

> > there is as you say no easy way out here. Looks like my first
> > assessment was correct, -TC/-TP are useless. I suppose one
> > approach does not contradict the other, we can both add -TC/-TP
> > in compile mode and zap them in link mode. But, since there is no
> > perfect solution, I kind of think it should just be required that
> > sources are named *.cpp if you want to be portable. Wonder if
> > there is some other braindead C++ compiler that only understands
> > *.cc or something. That would be ... fun.
> 
> The link I already posted about this issue:
> http://lists.gnu.org/archive/html/bug-autoconf/2005-05/msg00001.html
> sounds rather assuring.

Indeed.

> > You lost me in the last paragraph. What is CXXLD? The linker used
> > to link C++ stuff? What do you mean by "per-target CPPFLAGS"?
> > The whole paragraph does not make sence to me, I just don't get
> > what you are trying to say...
> 
> I am thinking about Automake.
> 
> Let's take another step back first and view the whole problem space:
> Libtool may be used in conjunction with Autoconf and Automake (the
> most common situation), but Libtool may just as well be used with
> Automake only and some other means to produce Makefile.in (the most
> common situation here being a hand-written Makefile.in).  
> Alternatively,
> a package author may want to rely on a preinstalled `libtool' script
> (read: as opposed to a libtoolized package, where libtool.m4 and
> ltmain.sh are present) and call that from whatever other 
> build software
> (make, ...) she employs.
> 
> We want Libtool to work well in conjunction with Automake, but we also
> want it to work in any situation.  The non-Automake 
> situations are less
> under our control, but also usually easier to adapt by 
> package authors.
> 
> Let's focus on Libtool+Automake+Autoconf now:
> Right now, there are packages which create libraries both with Libtool
> and (usually static ones) without.  This works so-so, it certainly is
> buggy when the former are linked against the latter (build tree
> references in installed .la files are a common result).  Now, 
> even with
> this bug (which eventually needs fixing in some way), I still 
> don't want
> to kill this possibility off in general.  For package supposed to be
> buildable with MSVC, I don't mind killing that option too much[1].
> However, since the time Automake makes merging (sub-)packages 
> into trees
> of packages easier, it is becoming a rather common issue.

I guess you are trying to say that anything Libtool wants in
$CC, $CXX, etc should not make it more difficult for non-Libtool
users (or rather users that sometimes use Libtool, sometimes
don't)? In that case, it seems cleaner to add -TP/-TC in
compile mode and don't do anything else. That way, in the non-
Libtool case, the user simply has to name C files .c and C++
files .cpp (or add suitable flags themsleves for MSVC).

> Now to CXXLD:
> One workaround for the /TP issue would be to configure with
>   CXX='cl /TP'  CXXLD=cl
> (when Automake is in use).  I don't know, however, whether this breaks
> many configure tests in other packages.  Does it work for Libtool?

I'll test this later (when bootstrap works again).

> > Regarding those tests in the new testsuite, they are using both
> > the -c and the -o flags, without regard to the outcome of the
> > _LT_COMPILER_C_O macro. Not that I suffer from this and I guess
> > you where aware of it, but it is a tiny tiny point in favour
> > of using the libtool compile mode :-)
> 
> Ahh, thanks, I missed that one, too.  Must've been because MSVC is
> the only compiler I know and have used in the last couple of years
> that barfs over `-c -o'.  See patch below.

*snip*

> > > Meanwhile, I installed these patches below.  If 
> inherited_flags still
> > > fails, at least we should now be able to see why.
> > 
> > Thanks!
> 
> OK, it still fails.  Does it succeed with the proposed patch below?
> (Use TESTSUITE_FLAGS='-v -d N-M' and similar to only run test numbers
> N-M, --list gives you the numbers).
> 
> OK to apply to HEAD?
> 
> [1] After all, you're not very likely to want to build GCC with MSVC,
> for example.
> 
>         * tests/inherited_flags.at: Weaken for MSVC.
>         * tests/early-libtool.at, tests/template.at: Fix for compiler
>         that do not understand `-c -o'.
> 
> Index: tests/inherited_flags.at
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/tests/inherited_flags.at,v
> retrieving revision 1.5
> diff -u -r1.5 inherited_flags.at
> --- tests/inherited_flags.at  13 Aug 2005 07:26:52 -0000      1.5
> +++ tests/inherited_flags.at  19 Aug 2005 09:21:27 -0000
> @@ -57,11 +57,15 @@
>  
>  AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS 
> $LDFLAGS -o libbaz.la baz.lo -no-undefined -rpath 
> /usr/local/lib ./libfoo.la ./libbar.la],
>        [ignore],[stdout],[ignore])
> -AT_CHECK([grep 
> 'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_li
> b' stdout],
> +# We used to grep for
> +# 'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_lib'
> +# here.  This fails on win32/MSVC because the generated 
> command lines have a
> +# different syntax.  So drop the first `l'.
> +AT_CHECK([grep 
> 'lt_[[ui]]nlikely_existing_lib.*lt_[[ui]]nlikely_existing_lib'
>  stdout],
>        [0],[ignore],[ignore])
>  AT_CHECK([${LIBTOOL} --mode=link --tag=CC $CC $CFLAGS 
> $LDFLAGS -o main main.lo -no-undefined -rpath /usr/local/lib  
> ./libfoo.la ./libbar.la],
>       [ignore],[stdout],[ignore])
> -AT_CHECK([grep 
> 'llt_[[ui]]nlikely_existing_lib.*llt_[[ui]]nlikely_existing_li
> b' stdout],
> +AT_CHECK([grep 
> 'lt_[[ui]]nlikely_existing_lib.*lt_[[ui]]nlikely_existing_lib'
>  stdout],
>        [0],[ignore],[ignore])
>  
>  AT_CLEANUP
> Index: tests//early-libtool.at
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/tests/early-libtool.at,v
> retrieving revision 1.1
> diff -u -r1.1 early-libtool.at
> --- tests//early-libtool.at   18 Aug 2005 17:07:17 -0000      1.1
> +++ tests//early-libtool.at   20 Aug 2005 08:57:55 -0000
> @@ -58,7 +58,7 @@
>  .SUFFIXES: .c .o .lo
>  
>  .c.o:
> -     $(COMPILE) -c -o $@ $<
> +     $(COMPILE) -c $<
>  .c.lo:
>       $(LTCOMPILE) -c -o $@ $<
>  ]])
> @@ -162,7 +162,7 @@
>  .SUFFIXES: .c .o
>  
>  .c.o:
> -     $(COMPILE) -c -o $@ $<
> +     $(COMPILE) -c $<
>  ]])
>  
>  AT_DATA([hello.c],
> Index: tests//template.at
> ===================================================================
> RCS file: /cvsroot/libtool/libtool/tests/template.at,v
> retrieving revision 1.4
> diff -u -r1.4 template.at
> --- tests//template.at        13 Aug 2005 06:45:36 -0000      1.4
> +++ tests//template.at        20 Aug 2005 08:57:55 -0000
> @@ -81,7 +81,7 @@
>  AT_CHECK($LIBTOOL --tag=CXX --mode=compile $CXX -I. 
> $CPPFLAGS $CXXFLAGS -c -o aclib.lo aclib.cpp, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS 
> $CXXFLAGS -o libaclib.la aclib.lo, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS 
> $CXXFLAGS -o libalib.la -rpath /usr/local/lib alib.lo 
> libaclib.la, [0], [ignore], [ignore])
> -AT_CHECK($CXX -I. $CPPFLAGS $CXXFLAGS -c -o prog.o prog.cpp, 
> [0], [ignore], [ignore])
> +AT_CHECK($CXX -I. $CPPFLAGS $CXXFLAGS -c prog.cpp, [0], 
> [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS 
> $CXXFLAGS -o prog prog.o libalib.la, [0], [ignore], [ignore])
>  
>  LT_AT_EXEC_CHECK([./prog], [0], [a sample prog
> @@ -125,6 +125,7 @@
>  LT_AT_TAG([CXX])
>  CPPFLAGS="$CPPFLAGS -I../src/lib -I../src/lib2"
>  
> +
>  mkdir src obj
>  ( cd src; mkdir lib lib2 sub )
>  ( cd obj; mkdir lib lib2 sub )
> @@ -199,36 +200,49 @@
>  
>  cd obj
>  
> +# If the compiler supports -c -o, we want to use it:
> +# it may make a difference for templates
> +eval `$LIBTOOL --tag=CXX --config | grep ^compiler_c_o=`
> +case $compiler_c_o in
> +yes)
> +  main_o=sub/main.o
> +  AT_CHECK($CXX $CPPFLAGS $CXXFLAGS -c -o $main_o 
> ../src/sub/main.cpp, [0], [ignore], [ignore])
> +  ;;
> +*)
> +  main_o=main.o

Sorry, MSVC creats main.obj. Perhaps this instead?
+  main_o=main.$OBJEXT

> +  AT_CHECK($CXX $CPPFLAGS $CXXFLAGS -c ../src/sub/main.cpp, 
> [0], [ignore], [ignore])
> +  ;;
> +esac
> +
>  AT_CHECK($LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS 
> $CXXFLAGS -c -o lib/a.lo ../src/lib/a.cpp, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS 
> $CXXFLAGS -c -o lib2/b.lo ../src/lib2/b.cpp, [0], [ignore], [ignore])
> -AT_CHECK($CXX $CPPFLAGS $CXXFLAGS -c -o sub/main.o 
> ../src/sub/main.cpp, [0], [ignore], [ignore])
>  # both convenience
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib/liba.la lib/a.lo, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo, [0], [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main], [ignore])
>  # lib convenience
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo -rpath /foo, [0], [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main])
>  # both installed
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib/liba.la lib/a.lo -rpath /foo, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo -rpath /bar, [0], [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la lib/liba.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main])
>  # both convenience, libb depending on liba
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib/liba.la lib/a.lo, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo lib/liba.la, [0], [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main])
>  # lib convenience
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo lib/liba.la -rpath /foo, [0], 
> [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main])
>  # both installed
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib/liba.la lib/a.lo -rpath /foo, [0], [ignore], [ignore])
>  AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> lib2/libb.la lib2/b.lo lib/liba.la -rpath /bar, [0], 
> [ignore], [ignore])
> -AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main sub/main.o lib2/libb.la, [0], [ignore], [ignore])
> +AT_CHECK($LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o 
> sub/main $main_o lib2/libb.la, [0], [ignore], [ignore])
>  LT_AT_EXEC_CHECK([./sub/main])
>  
>  cd ..
> 

Oh, what the hell, I've attached an updated patch...
I can't bootstrap after all the recent moves (should I send
a bugreport?), so it's against cvs from a couple of days ago
and not as well tested as I would like. E.g. your fix in
inherited_flags.at is untested.

Test 14 still fails, the reason could be that the output
from the "prog" program is warped from:

-----8<-----
a sample prog\r\n
f(3) = 6\r\n
cf(3) = 9\r\n
-----8<-----

into:
 
-----8<-----
a sample prog\r\n
f(3) = 6\r\n
cf(3) = 9\r\n
\n
-----8<-----

as seen in at-stdout.

I don't know if it's the extra newline (without carrige return!!!)
that's the problem or if it's the \r\n line endings in general...

Anyway, the output from autotest is this:
-----8<-----
../../tests/template.at:90: if ./prog; then :;
           elif test "X$host" != "X$build" && \
                { test -x "./prog" || test -x "./prog"$EXEEXT; }
           then (exit 77); fi
stderr:
--- -   Tue Aug 23 11:38:01 2005
+++
/c/cygwin/home/peda/libtool/head-msvc/libtool/msvc2/tests/testsuite.dir/
at-stdout   Tue Aug 23 11:38:01 2005
@@ -1,4 +1,4 @@
-a sample prog
-f(3) = 6
-cf(3) = 9
+a sample prog
+f(3) = 6
+cf(3) = 9
-----8<-----

My guess is the line ending mixup is the cause, since both
files have four "lines". But that's just a guess...

Cheers,
Peter

head-compiler_c_o.patch
Description: head-compiler_c_o.patch