Re: Windows Line Endings
Hi Peter,
On 6 Oct 2012, at 06:20, Peter Rosin wrote:
> 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.
Nice catch! And thanks for the analysis, that allowed me to get to the root
of the problem pretty quickly:
Legacy mdemo{,2} tests tricked their respective builds into reusing the main
project's libltdlc.la, where I tried to retool the replacement Autotest to
do what a user would do and use the project's own ltdl subproject. Only I
didn't remove all of the trickery while rewriting the test :-(
> 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
This means LTDL_INIT is finding the ltdl subtree, but I forgot to remove the
Makefile.am trickery to point $(LIBLTDL) back to $(top_srcdir)/libltdl.
> 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...)
And I also forgot to pass --with-included-ltdl to configure :(
> 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.
Something. This is the trickery I'm talking about, which needs removing
to let mdemo.at use it's own libltdl.
> 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?
Right, because I tried to convert from reusing top-level libltdlc.la to
actually building our own subproject libltdl per-test.
> I don't have enough autofuu to fix this.
I've pushed a patch that fixes all of the above. Pending as-yet-undiscovered
Windows madness, I think that should allow the test to work on your test
environments too.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: Windows Line Endings
Hi Peter, Thanks for the other fixes. On 6 Oct 2012, at 06:20, Peter Rosin wrote: > 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 thin[k] 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? The legacy testsuite didn't examine the output of the programs (in any of the *demo series), and simply assumed that if they linked and executed without error... then everything was fine. I had hoped that it would be safe to take advantage of the better facilities in Autotest, but even on Unix there are some weird things going on with output ordering in the fortran demos. I'm not a fortran programmer, so rather than try to futz with the (previously working) test cases themselves, I've weakened the Autotest pass criteria to grep for something sensible in the output rather than making assumptions about the entire output stream. I'm about to push these changes. Please let me know whether it fixes your fortran test failures -- It'll take me a few more days to find the time to build a Windows test environment. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: Windows Line Endings
On 10/5/2012 2:28 PM, Bob Friesenhahn wrote: I wouldn't recommend that anyone start with XP these days since it is 12 years old, patched beyond all repair, and quickly becoming defunct. Seconded. A virtual machine with "stock" XP will need several full days of running "Windows Update" to bring it up to SP3 + all latest patches. I know because I just re-created one a few weeks ago using an old XP install disk. On the other hand, $dayjob is still using XP. Corporate IT just okayed to transition to Win7 last month. The virtual machine images, even the one for XP, come fully patched as of their date of release. For the XP one I mentioned earlier, that'd be July 2012. -- Chuck
Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
On 10/5/2012 12:03 PM, Gary V. Vaughan wrote: > And thanks for looking into it. Is there a legal way to get access > to Windows and the various flavours of gcc and MSVC that libtool users > care about, without spending hundreds of dollars on software I would > never use for anything else? Yes. MS routinely provides virtual machine images for their OS's for testers to use. Naturally they are in VHD format for the windows-hosted VirtualPC product... WinXP, WinVista, Win7 (90 days [*]) http://www.microsoft.com/en-us/download/details.aspx?id=11575 [*] XP image has a hard-coded expiration date, and they usually upload a new version with a bumped expiry every so often. Current expiry is 13 Nov 2012. Vista and 7 are rolling expiration: 90 days from first activation. Windows Server 2012 (180 days) http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx?ocid=&wt.mc_id=MEC_110_1_33 Windows 8 (90 days) http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx ...but you can run them on linux using VirtualBox: http://www.geekpowers.com/?p=121 After that, you can install into the virtual environment the free (as in beer) Visual Studio Express of your choice; right now 2010 and 2012beta seem to be available. Requires "free" as in beer registration to use past 30 days. http://www.microsoft.com/visualstudio/eng/downloads Note that after installing VSexpress, you have to install separately the Windows SDK -- or at least that used to be required with the old 2005 and 2008 versions. Dunno about 2010/2012. http://www.microsoft.com/en-us/download/details.aspx?id=8442 The expiration thing causes an annoyance "redo" factor if you only mess with this stuff once every six months and find you have to recreate everything each time. But...it doesn't cost any money. -- Chuck
Re: Windows Line Endings
Hi Bob,
On 6 ต.ค. 2012, at 1:28, Bob Friesenhahn wrote:
> On Sat, 6 Oct 2012, Gary V. Vaughan wrote:
>>
>> I actually run a lot of virtual machines on my Mac, including a couple
>> of versions of Mac OS and Linux, and I certainly wouldn't want to
>> squander perfectly good hardware on an OS that I don't use, and wasn't
>> aware of the 180 days trials, so I'll take a look into that next time I
>> have half a day spare.
>
> I just forked out $350 for Windows 7 to support free software development.
> There just did not seem any way around it. The pain is severe.
Ouch! I can't think of anything I'd like to waste $350 on less
than a piece of paper from Microsoft authorizing me to
depress myself by using their software! My Dell Mini came with Windows
preinstalled, and cost only $255 from the Dell refurbished online store... of
course the very first thing I did after taking delivery was reformat the disk
and install a nicer OS. :-(
>> Do they also have similar trials for MSVC?
>
> There is "free" MSVC ("Visual Studio Express" in Google) available. It is
> really intended for .net/C# developers, but by following instructions on the
> net and adding downloadable "free" SDKs (requires manually editing some
> configuration files), one can create a Visual Studio capable of building C
> and C++ code without spending any money.
Thanks for the tip, I'll look into that :-)
>> Any idea what the least painful version of Windows for a VM is these days
>> (I'm guessing XP is still the best)?
>
> Windows 7 runs very well in VirtualBox. My wife has been running Windows 7
> in VirtualBox running on Ubuntu for almost a year now. I wouldn't recommend
> that anyone start with XP these days since it is 12 years old, patched beyond
> all repair, and quickly becoming defunct.
Apart from the number of years you quoted, isn't that true of every version of
Windows? I think I might go with XP despite your advice though, as I notice
that one of the stickers glued to my Dell Mini is an XP license number,
although curiously I didn't get any reinstall media with the netbook - not that
it contains a CD drive to reinstall from. I can probably find an XP disc at one
of the street vendor stalls in the center of town for a couple of dollars
though.
I will try to install it directly in Parallels, rather than in Virtual Box on
GNU/Linux in Parallels on Mac OS, and then type in the number from the sticker
on my netbook... and then I'll have to learn how to install mingw and MSYS.
> It is good that you are willing to suffer for the cause. The cmake build
> system is quickly becoming popular since it works well for Windows and it is
> a threat to the GNU build system (as we know it).
We might have better staying power if the Autotools shipped together as a
single project, and the integration was tight enough not to need a bootstrap
script just to get things going...
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: Windows Line Endings
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
Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
On 2012-10-05 18:03, Gary V. Vaughan wrote:
> Hi Peter,
>
> Apologies for having entirely forgotten about the old thread reviewing
> those patches first time around.
>
> And thanks for looking into it. Is there a legal way to get access
> to Windows and the various flavours of gcc and MSVC that libtool users
> care about, without spending hundreds of dollars on software I would
> never use for anything else? It pretty much sucks that everytime I
> push a well tested (on various Unix varieties) patch, that Windows likes
> to blow up gratuitously. I don't mind wasting a bit of time checking
> things on Windows, but I really don't want to also waste money on
> Microsoft.
Others have answered this, so I will stop at mentioning that it would be
fantastic if you could run smoke tests on MSYS/MinGW before commit!
The worst case is MSYS/MSVC I think, but I don't mind if you skip that.
Covering MSYS/MinGW would be plenty enough.
> On 5 Oct 2012, at 22:21, Peter Rosin wrote:
>>> I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
>>> appropriate.
>>
>> Unfortunately, the below is not enough since LT_AT_HOST_DATA
>> eats whitespace (" foo" -> "foo") which affects depdemo.at,
>> f77demo.at and fcdemo.at. mdemo.at also seems to have
>> more trouble that I need to look into...
>
> [[Patch snipped]]
Pushed with this ChangeLog
tests: fix line ending problems on MinGW
* tests/cdemo.at: Use LT_AT_HOST_DATA for expected output from
compiled programs.
* tests/demo.at: Likewise.
* tests/depdemo.at: Likewise.
* tests/f77demo.at: Likewise.
* tests/fcdemo.at: Likewise.
* tests/mdemo.at: Likewise.
* tests/tagdemo.at: Likewise.
Signed-off-by: Peter Rosin
> I appear to have arrived at the same patch, and it still passes
> make distcheck on Mac OS X. So LT_AT_HOST_DATA must only eat
> whitespace on Windows? So the fix must be in the windows loop to
> rewrite lines with \r\n. What's wrong with using awk or sed to
> inject the additional character rather than shell? That would seem
> to be the obvious solution to me:
>
> awk '{printf ("%s\r\n", $0);}' < $1 > $1.t && mv -f $1.t $1
>
> (untested on Windows, but doesn't mess with whitespace on Mac or Linux)
After hiding $0 from m4 with [$]0, it resolved the whitespace issues
I think. I pushed a patch with that m4-escape folded in.
tests: make LT_AT_HOST_DATA retain whitespace on MinGW
Fixes issues with depdemo.at, f77demo.at and fcdemo.at.
* tests/testsuite.at (LT_AT_HOST_DATA) [MinGW]: Keep leading
and trailing spaces and tabs when converting line endings.
---
tests/testsuite.at |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/tests/testsuite.at b/tests/testsuite.at
index 60ff5d5..2a55d04 100644
--- a/tests/testsuite.at
+++ b/tests/testsuite.at
@@ -256,8 +256,7 @@ AT_CHECK([test -z "$leftovers"])
m4_define([LT_AT_HOST_DATA],
[AT_DATA([$1], [$2])
case $host_os in mingw*)
- while read -r l; do printf "%s\r\n" "$l"; done < $1 > $1.t
- mv -f $1.t $1 ;;
+ awk '{printf ("%s\r\n", [$]0);}' < $1 > $1.t && mv -f $1.t $1 ;;
esac])
> Please do push patches that improve the situation for Windows rather
> than holding out for a fix-all mega-patch. This will allow us to
> keep each other informed of breakages on platforms the other doesn't
> have access to.
Done.
The remaining fallout is libtool.at, mdemo.at, f77demo.at and fcdemo.at.
I'll see what I can dig out...
Cheers,
Peter
Re: Windows Line Endings
On Sat, 6 Oct 2012, Gary V. Vaughan wrote:
I actually run a lot of virtual machines on my Mac, including a couple
of versions of Mac OS and Linux, and I certainly wouldn't want to
squander perfectly good hardware on an OS that I don't use, and wasn't
aware of the 180 days trials, so I'll take a look into that next time I
have half a day spare.
I just forked out $350 for Windows 7 to support free software
development. There just did not seem any way around it. The pain is
severe.
Do they also have similar trials for MSVC?
There is "free" MSVC ("Visual Studio Express" in Google) available.
It is really intended for .net/C# developers, but by following
instructions on the net and adding downloadable "free" SDKs (requires
manually editing some configuration files), one can create a Visual
Studio capable of building C and C++ code without spending any money.
Any idea what the least painful version of Windows for a VM is these days
(I'm guessing XP is still the best)?
Windows 7 runs very well in VirtualBox. My wife has been running
Windows 7 in VirtualBox running on Ubuntu for almost a year now. I
wouldn't recommend that anyone start with XP these days since it is 12
years old, patched beyond all repair, and quickly becoming defunct.
It is good that you are willing to suffer for the cause. The cmake
build system is quickly becoming popular since it works well for
Windows and it is a threat to the GNU build system (as we know it).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Windows Line Endings
Hi Eric, On 5 Oct 2012, at 23:42, Eric Blake wrote: > On 10/05/2012 10:03 AM, Gary V. Vaughan wrote: >> Is there a legal way to get access >> to Windows and the various flavours of gcc and MSVC that libtool users >> care about, without spending hundreds of dollars on software I would >> never use for anything else? It pretty much sucks that everytime I >> push a well tested (on various Unix varieties) patch, that Windows likes >> to blow up gratuitously. I don't mind wasting a bit of time checking >> things on Windows, but I really don't want to also waste money on >> Microsoft. > > If you are a fan of virtual machines, it is possible to set up qemu-kvm > under Linux to run a default-60-trial of various Windows versions > without having to pay for a license. Microsoft also has a documented > means of expanding that 60 days into 180 days, which means you can test > Microsoft products at no monetary cost at the expense of reinstalling > your virtual machine twice per year. Thanks for the tip. That's no different to a working Windows install anyway... when I worked for a company that forced me to use Windows 95 to connect to their exchange server, it needed to be reinstalled at least once a year even though all it did was run Out Look all day! I actually run a lot of virtual machines on my Mac, including a couple of versions of Mac OS and Linux, and I certainly wouldn't want to squander perfectly good hardware on an OS that I don't use, and wasn't aware of the 180 days trials, so I'll take a look into that next time I have half a day spare. Do they also have similar trials for MSVC? Any idea what the least painful version of Windows for a VM is these days (I'm guessing XP is still the best)? Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)
Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
On 10/05/2012 10:03 AM, Gary V. Vaughan wrote: > Hi Peter, > > Apologies for having entirely forgotten about the old thread reviewing > those patches first time around. > > And thanks for looking into it. Is there a legal way to get access > to Windows and the various flavours of gcc and MSVC that libtool users > care about, without spending hundreds of dollars on software I would > never use for anything else? It pretty much sucks that everytime I > push a well tested (on various Unix varieties) patch, that Windows likes > to blow up gratuitously. I don't mind wasting a bit of time checking > things on Windows, but I really don't want to also waste money on > Microsoft. If you are a fan of virtual machines, it is possible to set up qemu-kvm under Linux to run a default-60-trial of various Windows versions without having to pay for a license. Microsoft also has a documented means of expanding that 60 days into 180 days, which means you can test Microsoft products at no monetary cost at the expense of reinstalling your virtual machine twice per year. Unfortunately, I don't do this often enough myself (my time is more valuable than babysitting a full OS install twice per year, especially if I don't spend much time using that OS), so I don't really have a good link to the current URL for the Microsoft Windows trial versions. I also hear that the 'gnome-boxes' project is trying to make it easier to do this sort of thing (that is, turn it into a gui where you point-and-click on the request to install a Windows trial version, and then everything else from downloading the correct iso and installing it is all automated), but haven't tried that yet. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]
Hi Peter,
Apologies for having entirely forgotten about the old thread reviewing
those patches first time around.
And thanks for looking into it. Is there a legal way to get access
to Windows and the various flavours of gcc and MSVC that libtool users
care about, without spending hundreds of dollars on software I would
never use for anything else? It pretty much sucks that everytime I
push a well tested (on various Unix varieties) patch, that Windows likes
to blow up gratuitously. I don't mind wasting a bit of time checking
things on Windows, but I really don't want to also waste money on
Microsoft.
On 5 Oct 2012, at 22:21, Peter Rosin wrote:
>> The above looks just like a classic Windows failure. I.e. a line
>> ending mismatch between the expout file created by the posixy
>> shell (\n) and the Win32 program (\r\n) and I would guess that
>> this is a problem that caused failures for Chuck last year as
>> well.
>>
>> I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
>> appropriate.
>
> Unfortunately, the below is not enough since LT_AT_HOST_DATA
> eats whitespace (" foo" -> "foo") which affects depdemo.at,
> f77demo.at and fcdemo.at. mdemo.at also seems to have
> more trouble that I need to look into...
[[Patch snipped]]
I appear to have arrived at the same patch, and it still passes
make distcheck on Mac OS X. So LT_AT_HOST_DATA must only eat
whitespace on Windows? So the fix must be in the windows loop to
rewrite lines with \r\n. What's wrong with using awk or sed to
inject the additional character rather than shell? That would seem
to be the obvious solution to me:
awk '{printf ("%s\r\n", $0);}' < $1 > $1.t && mv -f $1.t $1
(untested on Windows, but doesn't mess with whitespace on Mac or Linux)
Please do push patches that improve the situation for Windows rather
than holding out for a fix-all mega-patch. This will allow us to
keep each other informed of breakages on platforms the other doesn't
have access to.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183
> The above looks just like a classic Windows failure. I.e. a line
> ending mismatch between the expout file created by the posixy
> shell (\n) and the Win32 program (\r\n) and I would guess that
> this is a problem that caused failures for Chuck last year as
> well.
>
> I think you need to use LT_AT_HOST_DATA instead of AT_DATA, where
> appropriate.
Unfortunately, the below is not enough since LT_AT_HOST_DATA
eats whitespace (" foo" -> "foo") which affects depdemo.at,
f77demo.at and fcdemo.at. mdemo.at also seems to have
more trouble that I need to look into...
Cheers,
Peter
diff --git a/Makefile.am b/Makefile.am
diff --git a/tests/cdemo.at b/tests/cdemo.at
index f50106c..885845c 100644
--- a/tests/cdemo.at
+++ b/tests/cdemo.at
@@ -117,7 +117,7 @@ int main ()
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool cdemo!
** This is libfoo **
hello returned: 57616
diff --git a/tests/demo.at b/tests/demo.at
index b79564a..b3d2532 100644
--- a/tests/demo.at
+++ b/tests/demo.at
@@ -339,7 +339,7 @@ int main ()
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU Hell!
cos (0.0) = 1
** This is not GNU Hello. There is no built-in mail reader. **
@@ -901,7 +901,7 @@ int foo2 (void) {
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU Hell!
cos (0.0) = 1
foo2 cos (0.0) = 1
diff --git a/tests/depdemo.at b/tests/depdemo.at
index 3c0666b..763bae4 100644
--- a/tests/depdemo.at
+++ b/tests/depdemo.at
@@ -240,7 +240,7 @@ for i in 1 2 3 4; do
done
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[dependencies:
l1 (0)
l2 (0)
diff --git a/tests/f77demo.at b/tests/f77demo.at
index 78da9a8..5978b3d 100644
--- a/tests/f77demo.at
+++ b/tests/f77demo.at
@@ -249,7 +249,7 @@ m4_define([_LT_CHECK_EXECUTE],
# on whether it is redirected to a file or sent to stdout, so we
# just check return status, and ignore output.
# Advice on this weirdness from a Fortran user much appreciated!
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[ Welcome to GNU libtool Fortran demo!
Real programmers write in FORTRAN.
fsub called
@@ -262,7 +262,7 @@ AT_DATA([expout],
]])
LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool mixed C/Fortran demo!
The C subroutine returned, claiming that 2*2 = 4
The C subroutine is ok!
@@ -294,7 +294,7 @@ _LT_SETUP
LT_AT_CHECK_CONFIG([--disable-shared],
[^build_old_libs=yes], [^build_libtool_libs=no])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[ Welcome to GNU libtool Fortran demo!
Real programmers write in FORTRAN.
fsub called
diff --git a/tests/fcdemo.at b/tests/fcdemo.at
index 3a545eb..0ade9bb 100644
--- a/tests/fcdemo.at
+++ b/tests/fcdemo.at
@@ -263,7 +263,7 @@ m4_define([_LT_CHECK_EXECUTE],
# on whether it is redirected to a file or sent to stdout, so we
# just check return status, and ignore output.
# Advice on this weirdness from a Fortran user much appreciated!
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[ Welcome to GNU libtool Fortran demo!
Real programmers write in FORTRAN.
fsub called
@@ -276,7 +276,7 @@ AT_DATA([expout],
]])
LT_AT_EXEC_CHECK([./fprogram], 0, [ignore])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool mixed C/Fortran demo!
The C subroutine returned, claiming that 2*2 = 4
The C subroutine is ok!
diff --git a/tests/mdemo.at b/tests/mdemo.at
index 40f89b4..5fa77f6 100644
--- a/tests/mdemo.at
+++ b/tests/mdemo.at
@@ -592,7 +592,7 @@ main (int argc, char **argv)
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU Hell!
cos (0.0) = 1
** This is not GNU Hello. There is no built-in mail reader. **
@@ -831,7 +831,7 @@ int main (int argc, char **argv)
}
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool mdemo2!
module name: foo1
module reference count: 1
diff --git a/tests/tagdemo.at b/tests/tagdemo.at
index 3909d56..d54a612 100644
--- a/tests/tagdemo.at
+++ b/tests/tagdemo.at
@@ -315,7 +315,7 @@ AT_DATA([conv.cpp],
int convenience (void) { return 1; }
]])
-AT_DATA([expout],
+LT_AT_HOST_DATA([expout],
[[Welcome to GNU libtool tagdemo C++!
** This is libfoo (tagdemo) **
foobar::hello returned: 57616
Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183
On 2012-10-05 13:15, Gary V. Vaughan wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "GNU Libtool".
ARRRGH!
I assume this is what you referred to when you talked about some stuff
stuck in the review queue? I can dig up this thread:
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00160.html
but from here it looks like it ended with Chuck complaining with:
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00184.html
http://lists.gnu.org/archive/html/libtool-patches/2011-11/msg00185.html
and then you went silent. Please tell me I'm missing something?
Here's the log from one of numerous failures on MinGW:
# -*- compilation -*-
33. demo.at:381: testing link against a preloaded static library ...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `build-aux'.
libtoolize: linking file `build-aux/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: linking file `m4/libtool.m4'
libtoolize: linking file `m4/ltoptions.m4'
libtoolize: linking file `m4/ltsugar.m4'
libtoolize: linking file `m4/ltversion.m4'
libtoolize: linking file `m4/lt~obsolete.m4'
../../libtool-msvc/tests/demo.at:385: $ACLOCAL -I m4
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOHEADER
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOMAKE --add-missing
stderr:
configure.ac:7: installing `build-aux/config.guess'
configure.ac:7: installing `build-aux/config.sub'
configure.ac:4: installing `build-aux/install-sh'
configure.ac:4: installing `build-aux/missing'
stdout:
../../libtool-msvc/tests/demo.at:385: $AUTOCONF
stderr:
stdout:
../../libtool-msvc/tests/demo.at:385: : ${CONFIG_SHELL=/bin/sh}; export
CONFIG_SHELL; $CONFIG_SHELL ./configure $configure_options
--prefix="$prefixdir" --disable-shared
stderr:
stdout:
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... c:/mingw/mingw32/bin/ld.exe
checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw/bin/nm
checking the name lister (/mingw/bin/nm) interface... BSD nm
checking whether ln -s works... no, using cp -p
checking the maximum length of command line arguments... 8192
checking how to convert i686-pc-mingw32 file names to i686-pc-mingw32 format...
(cached) func_convert_file_msys_to_w32
checking how to convert i686-pc-mingw32 file names to toolchain format...
(cached) func_convert_file_msys_to_w32
checking for c:/mingw/mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... file_magic ^x86 archive
import|^x86 DLL
checking for dlltool... dlltool
checking how to associate runtime and link libraries...
func_cygming_dll_for_implib
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for sysroot... no
checking for mt... :
checking if : is a manifest tool... no
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for as... as
checking for dlltool... (cached) dlltool
checking for objdump... (cached) objdump
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cac
Re: [PATCH] tests: feed -no-undefined when linking libtool libraries
Hi Peter,
On Oct 3, 2012, at 4:53 PM, Peter Rosin wrote:
> On 2012-10-03 05:45, Gary V. Vaughan wrote:
>> On Oct 3, 2012, at 12:32 AM, Peter Rosin wrote:
>>> I just fired up a test suite run...
>
> Good news! Clean runs on Cygwin, MSYS/MinGW and MSYS/MSVC.
Awesome.
I'll push the merge now, along with some other resurrected patches that
got stuck in the review queue last year.
> Now into nitpicking and other useless ramblings...
>
> The patch "libtool: unroll nested if into a single case statement" has
> whitespace issues (leading spaces instead of tabs on a few lines), and it
> should perhaps use a simple catch-all "*" (retaining the "fast_install is
> set to needless" comment) as the last case instead of "*,needless" that
> you have put there. But I guess it's harmless as $fast_install is not any
> random string, sans hacks, so no rereredo request from me, just a
> nitpick that I saw when reviewing the "libtool: ..." changes at the
> tip of gary/reredo-test-operand-order. Can always be cleaned up later,
> if someone has the energy.
Agreed on all counts. Having now split out all the unrelated patches has me
wondering how on earth all that extra crud got in there... especially since
every
review used to be like a few weeks on the rack.
> I also wonder about the relationship between "libtool: fold if into a
> compound OR statement when more readable" and the next commit "libtool:
> simplify multiple string tests". What I mean is that about half the
> tests from the later commit fit the pattern of the first, why did you
> for example not change
>
>if test yes,no = "$avoid_version,$need_version"; then
> major=
> versuffix=
> verstring=
>fi
>
> into
>
>test yes,no = "$avoid_version,$need_version" && {
> major=
> versuffix=
> verstring=
>}
>
> (or some such) when you where at it? (but to me it looks like churn)
Yep :( But, remember these changes are all to match the conflated original
changeset so that we end up with a useful diff showing errors in the original
that can be applied easily to the current tip of master. That said, your
comments are more than valid, and a lot of that stuff shouldn't really have
gotten in and/or should have been done consistently.
With my newly self appointed benevolent dictator hat on, and the commit
process being infinitely less arduous as a result, I hope to come back and
undo some of this damage prior to freezing for the next release.
> Anyway, to sum up, I'm ok with merging reredo branch into master.
> Lets put this to rest now, thanks!
And thanks to you too :)
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
