libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Windows Line Endings


From: Peter Rosin
Subject: Re: Windows Line Endings
Date: Sat, 06 Oct 2012 01:20:12 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1

On 2012-10-05 22:01, Peter Rosin wrote:
> The remaining fallout is libtool.at, mdemo.at, f77demo.at and fcdemo.at.
> I'll see what I can dig out...

My guess is that f77demo.at and fcdemo.at fails because of
different stdio streams in their mixed mode programs.

Tests 159 and 162 (static library) fails because different
parts of the output has different style line endings with
\n from the C code and \r\n from the Fortran code. With
LT_AT_HOST_DATA all line endings are supposed to by \r\n
and it blows up.

That's strange I guess, but normalizing stdout with
LT_AT_UNIFY_NL instead of using LT_AT_HOST_DATA reveals
another stdio difference in tests 160, 161, 163 and 164.
In these tests the output from the Fortran code appears
at the end of the output, not in the middle as expected.

I thing the cause of this is different usages of the
stdio libraries. I believe the MinGW gcc is using some
wrappers around printf to make up for broken stuff in
the MSVCRT.dll printf and my guess is that MinGW fortran
is hammering directly on the MSVCRT.dll printf.

It is perhaps possible to fix this by adding fflush calls
(and equivalent for Fortran) before switching to the other
language.

I don't have enough mingwfuu to fix this. I also don't
understand why the tests used to work in the old setting?


Over to mdemo.at. It fails on MinGW because I do not have
any installed libltdl in MinGW. Temporarily moving the
installed Cygwin libltdl out of the lib search path makes
the test fail on Cygwin as well. So, I believe this is
a generic failure. Without an installed libltdl, I get this
during configure:

checking where to find libltdl headers... -I$(top_srcdir)/libltdl
checking where to find libltdl library... $(top_build_prefix)libltdl/libltdlc.la

and this when making:

../../libtool-msvc/tests/mdemo.at:646: $unset LIBTOOL LIBTOOLIZE; $MAKE $target 
stderr:
Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
Makefile:1090: warning: overriding commands for target `libltdl/libltdlc.la'
Makefile:573: warning: ignoring old commands for target `libltdl/libltdlc.la'
libtool: link: cannot find the library `libltdl/libltdlc.la' or unhandled 
argument `libltdl/libltdlc.la'
make[1]: *** [libmlib.la] Error 1

On Cygwin, with the installed libltdl intact, I get this during
configure:

checking where to find libltdl headers... 
checking where to find libltdl library... -lltdl

(and the test is ok, in so far one can consider using the
installed libltdl ok...)

I'm also noting that some time ago, mdemo had this in it's
Makefile.am:

## use @LIBLTDL@ because some broken makes do not accept macros in targets
## we can only do this because our LIBLTDL does not contain ${top_builddir}
top_distdir = ../..
@LIBLTDL@: $(top_distdir)/libtool \
    $(top_distdir)/config.h $(srcdir)/$(top_distdir)/libltdl/ltdl.c \
    $(srcdir)/$(top_distdir)/libltdl/ltdl.h
        (cd $(top_distdir); $(MAKE) `echo $(LIBLTDL) | sed 
's,.*\.\./libltdl/,libltdl/,g'`)

but somewhere along the way, that comment was removed, probably at
the same time @LIBLTDL@ was converted into $(LIBLTDL). Anyway,
mdemo.at has this:

\$(LIBLTDL): ${top_build_prefix}libtool \
    ${top_build_prefix}config.h $top_srcdir/libltdl/ltdl.c \
    $top_srcdir/libltdl/ltdl.h
        cd $top_build_prefix; \$(MAKE) \`echo \$(LIBLTDL) | sed 
's|.*\.\./\.\./libltdl/|libltdl/|g'\`

But the second line of the removed comment seems crucial and
as our $(LIBLTDL) is not the expected "libltdl/libltdlc.la",
Automake is fooled into creating two targets for the same
file. Or something.

Also, the old mdemo had LTDL_CONVENIENCE([../../libltdl]), and the
new mdemo.at have LT_CONFIG_LTDL_DIR([libltdl]) and
LTDL_INIT([nonrecursive]), which does not seem entirely equivalent?

I don't have enough autofuu to fix this.


And lastly libtool.at. It is only \' that is a problem. If I take
that char out of the backslashified list, the test is ok.
Another data point is that if I replace the grep on line 110 like
this:
-LT_AT_CHECK([$EGREP 
"$mode:.*$match_preflag\"?$flag\\\\\\$mchar:test\\\\\\$mchar\"? " stdout], [0], 
[ignore])
+LT_AT_CHECK([$EGREP 
"$mode:.*$match_preflag\"?$flag\\\\$mchar:test\\\\$mchar\"? " stdout], [0], 
[ignore])
it is ok for \" and \', but not for \$ and \\.

Looking at LT_ESCAPE in testsuite.at (which is expanded as part of
LT_AT_CHECK), it seems to handle \"` specially, but not $.

My $EGREP is GNU grep 2.6.3 on Cygwin, and GNU grep 2.5.4 on MinGW.

I don't have enough quotefuu to fix this.

Cheers,
Peter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]