Make modified libtool script executable in cwrapper.at test
Hi! As reported by Roumen Petrov [1], the cwrapper test is somewhat disfunctional. Ok to push the attached? Cheers, Peter [1] http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00201.html 2009-01-29 Peter Rosin p...@lysator.liu.se Make modified libtool script in cwrapper test executable * tests/cwrapper.at: Make modified libtool script executable. Report by Roumen Petrov. diff --git a/ChangeLog b/ChangeLog index e823ff7..f7fd4d1 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-01-29 Peter Rosin p...@lysator.liu.se + + Make modified libtool script in cwrapper test executable + * tests/cwrapper.at: Make modified libtool script executable. + Report by Roumen Petrov. + 2009-01-28 Akim Demaille demai...@gostai.com Clean space uses. diff --git a/tests/cwrapper.at b/tests/cwrapper.at index ce4572e..42f8d0f 100644 --- a/tests/cwrapper.at +++ b/tests/cwrapper.at @@ -58,6 +58,7 @@ orig_LIBTOOL=$LIBTOOL for restrictive_flags in '-Wall -Werror' '-std=c89 -Wall -Werror' '-std=c99 -Wall -Werror'; do CFLAGS=$orig_CFLAGS $restrictive_flags sed s/LTCFLAGS=.*/' $restrictive_flags'/ $orig_LIBTOOL ./libtool + chmod +x libtool LIBTOOL=./libtool # make sure $restrictive_flags do not cause a failure
Re: Make modified libtool script executable in cwrapper.at test
* Peter Rosin wrote on Thu, Jan 29, 2009 at 09:02:57AM CET: 2009-01-29 Peter Rosin p...@lysator.liu.se Make modified libtool script in cwrapper test executable * tests/cwrapper.at: Make modified libtool script executable. Report by Roumen Petrov. This is obvious, thanks.
Re: Status of the MSYS/MSVC port
Den 2009-01-28 23:44 skrev Peter Rosin:
Den 2009-01-28 16:13 skrev Charles Wilson:
Peter Rosin wrote:
Maybe, here are the errors:
So, I guess these declarations should do it (untested):
int _setmode (int, int);
int _spawnv (int, const char *, const char * const *);
#ifndef _P_WAIT /* just in case */
# define _P_WAIT0
#endif
_P_WAIT is guarded in MSVC's process.h by #ifndef _POSIX_ (as opposed to
__STRICT_ANSI__). In MinGW's process.h, it is not guarded at all (but
P_WAIT is guarded by _NO_OLDNAMES).
#ifndef _STAT_DEFINED
struct _stat
{
_dev_tst_dev;/* Equivalent to drive number 0=A 1=B
... */
_ino_tst_ino;/* Always zero ? */
_mode_tst_mode;/* See above constants */
shortst_nlink;/* Number of links. */
shortst_uid;/* User: Maybe significant on NT ? */
shortst_gid;/* Group: Ditto */
_dev_tst_rdev;/* Seems useless (not even filled in) */
_off_tst_size;/* File size in bytes */
time_tst_atime;/* Accessed date (always 00:00 hrs local
* on FAT) */
time_tst_mtime;/* Modified time */
time_tst_ctime;/* Creation time */
};
#endif /* _STAT_DEFINED */
Something is not right here. I took a look at the pre-preocessed output
from mingw-gcc -std=c89 -E lt-foo.c, and both 'struct stat' and 'struct
_stat' were declared. Further, looking at the MinGW sys/stat.h, I can't
see where any of the compile flags we are using -- even the restrictive
ones -- would exclude those declarations.
Are you using the MSVC include files here? I thought the test case was:
I don't think I do...
I was right.
I'll get back when I have inspected some preprocessor output...
I have:
$ gcc -v
Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java
--disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
gcc -std=c89 -E on lt-usea.c has exactly one occurence of stat.h:
# 1 C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/stat.h 1 3
No declaration from it though.
That file is like this:
/*
* stat.h
*
* Symbolic constants for opening and creating files, also stat, fstat and
* chmod functions.
*
* This file is part of the Mingw32 package.
*
* Contributors:
* Created by Colin Peters co...@bird.fu.is.saga-u.ac.jp
*
* THIS SOFTWARE IS NOT COPYRIGHTED
*
* This source code is offered for use in the public domain. You may
* use, modify or distribute it freely.
*
* This code is distributed in the hope that it will be useful but
* WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
* DISCLAIMED. This includes but is not limited to warranties of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*
* $Revision: 1.5 $
* $Author: earnie $
* $Date: 2003/02/21 21:19:52 $
*
*/
#ifndef __STRICT_ANSI__
/*stuff*/
#endif /* Not __STRICT_ANSI__ */
So, no struct _stat or anything like it for me...
Cheers,
Peter
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: I have: $ gcc -v Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.2 (mingw-special) gcc -std=c89 -E on lt-usea.c has exactly one occurence of stat.h: # 1 C:/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/sys/stat.h 1 3 No declaration from it though. That file is like this: That's...quite different than mine. I'm running a slightly patched version of mingw's gcc: $ gcc -v Reading specs from C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5-20060117-3csw/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) But the real kicker is sys/stat.h: /* * stat.h * This file has no copyright assigned and is placed in the Public Domain. * This file is a part of the mingw-runtime package. * No warranty is given; refer to the file DISCLAIMER within the package. * * Symbolic constants for opening and creating files, also stat, fstat and * chmod functions. * */ #ifndef _STAT_H_ #define _STAT_H_ /* All the headers include this file. */ #include _mingw.h #define __need_size_t #define __need_wchar_t #ifndef RC_INVOKED #include stddef.h #endif /* Not RC_INVOKED */ #include sys/types.h /* * Constants for the stat st_mode member. */ ... #endif /* Not _STAT_H_ */ What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). -- Chuck
Re: Status of the MSYS/MSVC port
Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... Cheers, Peter [1] http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/include/sys/stat.h.diff?r1=1.5r2=1.6cvsroot=src
Re: Status of the MSYS/MSVC port
On Thu, 29 Jan 2009, Peter Rosin wrote: Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... My own MinGW install dates from the 2002/2003 time frame. :-) At the time MinGW/MSYS was a simple install. Nowadays it seems to be all jumbled up so I have not tried to cross the hurdle of an update. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Fix distcc/ccache interferences with the test suite
Hi Akim, * Akim Demaille wrote on Tue, Jan 06, 2009 at 09:24:32AM CET: Le 6 janv. 09 à 07:48, Ralf Wildenhues a écrit : Are those the only distcc/ccache-induced failures? Yes, I had no other failures. Thanks, and sorry for the delay. In the meantime, the localization code has seen some output normalization already; I'm adding another macro in the same vein, and using your suggested code for it, and pushing the result. Can you check that it still fixes the issue? Thanks! Ralf commit 3e0beef8eb35a734514d5c4871f19a32c5edb145 Author: Akim Demaille demai...@gostai.com Date: Thu Jan 29 18:39:58 2009 +0100 Normalize compiler output due to compiler wrappers. * tests/testsuite.at (LT_AT_NORMALIZE_COMPILER_OUTPUT): New macro, to normalize ccache and distcc output. * tests/localization.at (localized compiler messages): Use it. Signed-off-by: Ralf Wildenhues ralf.wildenh...@gmx.de diff --git a/ChangeLog b/ChangeLog index f7fd4d1..3c2871d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2009-01-29 Akim Demaille demai...@gostai.com + Ralf Wildenhues ralf.wildenh...@gmx.de + + Normalize compiler output due to compiler wrappers. + * tests/testsuite.at (LT_AT_NORMALIZE_COMPILER_OUTPUT): New + macro, to normalize ccache and distcc output. + * tests/localization.at (localized compiler messages): Use it. + 2009-01-29 Peter Rosin p...@lysator.liu.se Make modified libtool script in cwrapper test executable diff --git a/tests/localization.at b/tests/localization.at index 92b19ac..119b38d 100644 --- a/tests/localization.at +++ b/tests/localization.at @@ -43,15 +43,13 @@ AT_CHECK([$CC $CPPFLAGS $CFLAGS -c b.c || exit 77], [], [stdout], [stderr]) # Find out about expected output. AT_CHECK([$CC $CPPFLAGS $CFLAGS -c a.c || exit 1], [1], [stdout], [stderr]) -LT_AT_UNIFY_NL([stdout], [expected-stdout]) -LT_AT_UNIFY_NL([stderr], [expected-stderr]) +LT_AT_NORMALIZE_COMPILER_OUTPUT([stdout], [expected-stdout]) +LT_AT_NORMALIZE_COMPILER_OUTPUT([stderr], [expected-stderr]) AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c || exit 1], [1], [stdout], [stderr]) -LT_AT_UNIFY_NL([stderr]) -AT_CHECK([diff expected-stderr stderr]) -LTBASE=`$ECHO $LIBTOOL | sed 's,^.*/,,'` -grep -v ^$LTBASE: compile stdout libtool-stdout -LT_AT_UNIFY_NL([libtool-stdout]) +LT_AT_NORMALIZE_COMPILER_OUTPUT([stdout], [libtool-stdout]) +LT_AT_NORMALIZE_COMPILER_OUTPUT([stderr], [libtool-stderr]) +AT_CHECK([diff expected-stderr libtool-stderr]) AT_CHECK([diff expected-stdout libtool-stdout]) # check that we get our quoting right. diff --git a/tests/testsuite.at b/tests/testsuite.at index 24e8174..92e786e 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -218,6 +218,20 @@ m4_define([LT_AT_UNIFY_NL], esac]) +# LT_AT_NORMALIZE_COMPILER_OUTPUT(FILE, [RESULT-FILE]) +# +# Normalize differences in compiler output stemming from, e.g., +# - distcc process numbers, +# - ccache file location, +# - newline encoding, +# - location of the libtool script. +m4_define([LT_AT_NORMALIZE_COMPILER_OUTPUT], +[_ltbase=`$ECHO $LIBTOOL | sed 's,^.*/,,'` +[sed /^distcc\[[0-9]*\]/d; /^$_ltbase: compile/d $1 $1.t] +LT_AT_UNIFY_NL([$1.t], [m4_default([$2], [$1])])[]dnl +]) + + # LT_AT_EXEC_CHECK(EXECUTABLE, [STATUS = 0], [STDOUT], [STDERR], # [ARGS-OR-STATUS-ADJUST]) # --
Re: Status of the MSYS/MSVC port
Den 2009-01-29 18:26 skrev Bob Friesenhahn: On Thu, 29 Jan 2009, Peter Rosin wrote: Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... My own MinGW install dates from the 2002/2003 time frame. :-) At the time MinGW/MSYS was a simple install. Nowadays it seems to be all jumbled up so I have not tried to cross the hurdle of an update. But maybe, just maybe, you don't have a desperate need to do -std=c89 -Werror :-) Cheers, Peter
Re: Status of the MSYS/MSVC port
Den 2009-01-29 18:56, skrev Ralf Wildenhues: * Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET: But maybe, just maybe, you don't have a desperate need to do -std=c89 -Werror :-) Guys, if all you're working around is -Werror, then stop right now. Just eliminate -Werror from $LTCC $LTCFLAGS and be done with it. The cwrapper machinery, if it needs anything, then become simpler and less work to maintain, not more. I just realized that -Werror is not needed though, -std=c89 is enough to make it fail. E.g. ./.libs/lt-usea.c:429: error: `S_IXUSR' undeclared (first use in this function) and ./.libs/lt-usea.c:439: error: storage size of 'st' isn't known etc So, we'd need to also kick out -std=c89, -std=c99, -ansi (I think). Etc... Cheers, Peter
Re: Pings
Hi Akim, * Akim Demaille wrote on Wed, Jan 28, 2009 at 04:43:56PM CET: Some of my patches are waiting for approvals or comments. I do understand that it requires time to process them, I just want to make sure they aren't forgotten :) Thanks for the reminder. I think I had them all on my radar. - dynamic logs http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00064.html here I will probably make a single call to the logs to list the supported loaders, which requires a dynamic string. Is there any lt_string somewhere I missed? I have seen placed where libltdl has to maintain dynamic strings, that would be useful. Still on my TODO-review list. - distcc nuisances in the test suite http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00017.html I've pushed an equivalent fix now. - nuke warnings in the wrappers The patch at the end of http://lists.gnu.org/archive/html/libtool/2008-12/msg00069.html For this one I'd prefer if Charles and/or Peter took care of it, they have a bunch of changes in this area and some discussion going on. Actually, I'd prefer to just be able to say go! once y'all have agreed on a common set of changes. :-) - Bootstrap failures http://lists.gnu.org/archive/html/bug-libtool/2008-11/msg00098.html I suggest adding the following macros to lt~obsolete.m4 to stop the boostrap nightmare. I agree that this needs fixing, and in fact this is the single most important issue to be addressed before 2.2.8. However, I really want to be able to reproduce it and thus understand the failure, and I haven't so far. I want to ensure that we cannot make this mistake again. +m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], + [AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])]) +m4_ifndef([_LT_AC_PROG_CXXCPP], + [AC_DEFUN([_LT_AC_PROG_CXXCPP])]) I have also the following patch that I don't remember if I sent it. I don't remember you having sent it. Subject: [PATCH] Fix func_exec_init. * tests/defs.m4sh (func_exec_init): Instead of using the undefined my_dir, call func_dirname_and_basename and use its result. (func_make): For consistency, don't use the useless local variable my_dir. This is ok, please push. Thanks, Ralf
Re: [PATCH] func_version copes with multi-line copyright headers.
* Ralf Wildenhues wrote on Mon, Jan 19, 2009 at 09:47:54PM CET: The long line in ltmain.m4sh is actually necessary in order for libtool --version to work correctly. Will address in a followup patch. OK to push? I've pushed this now. Cheers, Ralf func_version copes with multi-line copyright headers. * libltdl/config/getopt.m4sh (func_version): Slurp in copyright lines until a period is found. * libltdl/config/ltmain.m4sh: Multi-line copyright is ok to use now. * tests/help.at (standard command line options): New file, new tests. Make this test group the first one for libtool tests, moving the banner ... * tests/duplicate_members.at: ... from here. * Makefile.am (TESTSUITE_AT): Add tests/help.at.
test mode short-hands (was: libtool --mode=execute gdb)
* Ralf Wildenhues wrote on Sat, Jan 24, 2009 at 03:52:49PM CET:
Please note that there is an alternative short-hand, in that you
can use (among others) the following equivalently:
libtool --mode=execute PROG [ARGS]...
libtoolexecute PROG [ARGS]...
libtoolexe PROG [ARGS]...
libtoole PROG [ARGS]...
S'pose I'll be adding testsuite exposure to this feature.
As follows.
Cheers,
Ralf
Document --mode short-hands better, and test them.
* doc/libtool.texi (Invoking libtool): Give examples for using
the `--mode=MODE' short-hand `MODE', or abbreviations thereof.
* libltdl/config/ltmain.m4sh: Mention the short-hand for MODE
in the --help output.
* tests/help.at (mode short-hands): New test group.
Suggestion by Bruno Haible.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index c3a2906..02340d9 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1161,8 +1161,16 @@ operation mode, and exit.
Use @var{mode} as the operation mode. When using libtool from the
command line, you can give just @var{mode} (or a unique abbreviation
of it) as the first argument as a shorthand for the full
-...@option{--mode=@var{mode}}.
+...@option{--mode=@var{mode}}. For example, the following are equivalent:
+...@example
+$ @kbd{libtool --mode=execute --dry-run gdb prog.exe}
+$ @kbd{libtoolexecute --dry-run gdb prog.exe}
+$ @kbd{libtoolexe --dry-run gdb prog.exe}
+$ @kbd{libtoole --dry-run gdb prog.exe}
+...@end example
+
+...@noindent
@var{mode} must be set to one of the following:
@table @option
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 83bfaf4..de63a83 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -59,7 +59,8 @@ m4_divert_push([SCRIPT])# @configure_input@
# link create a library or an executable
# uninstall remove libraries from an installed directory
#
-# MODE-ARGS vary depending on the MODE.
+# MODE-ARGS vary depending on the MODE. When passed as first option,
+# `--mode=MODE' may be abbreviated as `MODE' or a unique abbreviation of that.
# Try `$progname --help --mode=MODE' for a more detailed description of MODE.
#
# When reporting a bug, please describe a test case to reproduce it and
diff --git a/tests/help.at b/tests/help.at
index f0e7e94..3460a2b 100644
--- a/tests/help.at
+++ b/tests/help.at
@@ -36,3 +36,55 @@ AT_CHECK([$LIBTOOL --version], [], [stdout])
AT_CHECK([grep 'Copyright.*Free Software Foundation' stdout], [], [ignore])
AT_CLEANUP
+
+
+AT_SETUP([mode short-hands])
+
+AT_DATA([a.c],
+[[int a () { return 0; }
+]])
+
+AT_DATA([main.c],
+[[extern int a ();
+int main () { return a (); }
+]])
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+AT_CHECK([$LIBTOOL compile $CC $CPPFLAGS $CFLAGS -c a.c],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL co $CC $CPPFLAGS $CFLAGS -c main.c],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL co $CC $CPPFLAGS $CFLAGS -c main.c],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL link $CC $CFLAGS $LDFLAGS -o liba.la a.lo ]dnl
+[-no-undefined -rpath $libdir], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL l $CC $CFLAGS $LDFLAGS -o main$EXEEXT main.lo ]dnl
+[liba.la], [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL execute --dry-run ./main$EXEEXT],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL exe --dry-run ./main$EXEEXT],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL e --dry-run ./main$EXEEXT],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL install cp liba.la $libdir],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL i cp main$EXEEXT $bindir],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL finish $libdir],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL f $libdir],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL uninstall rm -f $libdir/liba.la],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL u rm -f $bindir/main$EXEEXT],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL clean rm -f main$EXEEXT],
+[], [ignore], [ignore])
+AT_CHECK([$LIBTOOL cl liba.la],
+[], [ignore], [ignore])
+
+AT_CLEANUP
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: Den 2009-01-29 18:56, skrev Ralf Wildenhues: * Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET: But maybe, just maybe, you don't have a desperate need to do -std=c89 -Werror :-) Guys, if all you're working around is -Werror, then stop right now. Just eliminate -Werror from $LTCC $LTCFLAGS and be done with it. The cwrapper machinery, if it needs anything, then become simpler and less work to maintain, not more. I just realized that -Werror is not needed though, -std=c89 is enough to make it fail. E.g. ./.libs/lt-usea.c:429: error: `S_IXUSR' undeclared (first use in this function) and ./.libs/lt-usea.c:439: error: storage size of 'st' isn't known etc So, we'd need to also kick out -std=c89, -std=c99, -ansi (I think). Etc... Cheers, Peter For flags -ansi and -std=c89 compiler internals (defines) are same. With -ansi flag mingw 1.15 and 1.15.1 has to fail in stdlib.h ( inline ... strtod ). This is fixed in 1.15.2. Roumen
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: Den 2009-01-29 00:45 skrev Roumen Petrov: snip I'm sure that I test libtool in mingw-cross env. after Charles add cwrapper test. Now I repeat the test N# 37(cwrapper) in verbose mode and the results is: ... /at-groups/37/test-source: line 73: ./libtool: Permission denied ... 37. cwrapper.at:25: ok 1 test was successful. Ooops Indeed. I'll post a patch in a new thread... Cheers, Peter Now 39. cwrapper.at pass mingw runtime v 1.15.2 Roumen
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: Den 2009-01-29 11:49 skrev Charles Wilson: What version of mingw-runtime are you using? (I'm not sure which version I have; its from a bundle I put together about a year ago; I can get to the docu for that bundler later today. It's probably mingw-runtime-3.14). Something prior to [1] obviously. 3.1 or 3.2 perhaps, ca 2003 it seems? Maybe we should just ignore this (ancient) problem... Yes. Doctor, it hurts when I use -std=c89 and my grandfather's mingw-runtime. Okay, then either DON'T use -std=c89 (and live with cwrapper.test failing, because it /will/ use that flag), OR upgrade your mingw-runtime. Problem solved. -- Chuck
Re: Status of the MSYS/MSVC port
Bob Friesenhahn wrote: My own MinGW install dates from the 2002/2003 time frame. :-) At the time MinGW/MSYS was a simple install. Nowadays it seems to be all jumbled up so I have not tried to cross the hurdle of an update. Yes, the MinGW download site is a disaster, thanks to SF improvements. However, TDM has done a lot of the grunt work, and written a custom installer program. It can install his custom MinGW distribution, OR it can also install the official MinGW. I haven't tried it, but it's worth a look (and beats the unmaintained official installer hands down... http://www.tdragon.net/recentgcc/ -- Chuck
Re: Status of the MSYS/MSVC port
Roumen Petrov wrote: I think that we has to be careful about structure _stat and version of msvcrt (=8.0) - it depend from definition of time_t 32/64 bit and the size is deferent depending from an another macro. May be wrapper has to include MSVC headers. This is all moot. We (libtool's cwrapper) have no business defining struct stat. With modern mingw-runtime (or MSVC headers), we will get the right one when we #include sys/stat.h, regardless of any -std=c89 or -std=c99 flags. So no worries. -- Chuck
Re: Pings
Akim Demaille wrote: Le 29 janv. 09 à 19:22, Ralf Wildenhues a écrit : For this one I'd prefer if Charles and/or Peter took care of it, they have a bunch of changes in this area and some discussion going on. Actually, I'd prefer to just be able to say go! once y'all have agreed on a common set of changes. :-) Maybe there are other means to address these warnings. At some other place of our project, it seems that #defining _CRT_SECURE_NO_DEPRECATE, _CRT_NONSTDC_NO_DEPRECATE, _AFX_SECURE_NO_WARNINGS, and _ATL_SECURE_NO_WARNINGS might suffice. Well, we should do our best to make the libtool cwrapper as invisible as possible. So, if a client's code is _CRT_SECURE_NO_DEPRECATE clean, such that they don't need to define that macro, we shouldn't require them to change their entire build settings CFLAGS just to make our little wrapper compile silently. However, there is no WAY we're going to use MS's improved functions like StringCchLength() or StringCbCat(). So, *we* ought to #define those shaddup, MS, I'm not using your 'safe' but proprietary replacements for standard libc functions macros. However, the only ones that matter for the cwrapper is _CRT_SECURE_NO_DEPRECATE (and perhaps _CRT_NONSTDC_NO_DEPRECATE [*]). [*] except that we are already addressing that via the typical port-to-MSVC method of '#define foo _foo' for all posix functions we use. Whatever the choice, this (msvc) is a real nuisance. You can say that again. And again. And several more times. -- Chuck
Re: Pings
Ralf Wildenhues wrote: * Akim Demaille wrote on Wed, Jan 28, 2009 at 04:43:56PM CET: - nuke warnings in the wrappers The patch at the end of http://lists.gnu.org/archive/html/libtool/2008-12/msg00069.html For this one I'd prefer if Charles and/or Peter took care of it, they have a bunch of changes in this area and some discussion going on. Actually, I'd prefer to just be able to say go! once y'all have agreed on a common set of changes. :-) My set of changes were already pushed (0aef3579..6631e515) 2009-01-24 Charles Wilson ... [cygwin|mingw] cwrapper cleanups. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability macros. Avoid oldnames on MINGW32 and MSVC for setmode/stat/chmod/getcwd/putenv. Declare _putenv on MINGW32 when -ansi. Use namespaced macro LT_DEBUGWRAPPER. This patch ALSO takes care of all but the _CRT_SECURE_NO_DEPRECATE part of Akim's. See earlier reply in this thread for why we don't need to worry about any other magic MSVC macros. So, I think the only remaining cleanup-warnings patch for the cwrapper is this: diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 1c745f4..308a89a 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3110,6 +3110,9 @@ func_emit_cwrapperexe_src () */ EOF cat EOF +#ifdef _MSC_VER +# define _CRT_SECURE_NO_DEPRECATE 1 +#endif #include stdio.h #include stdlib.h #ifdef _MSC_VER OK to push? -- Chuck
Re: Status of the MSYS/MSVC port
Ralf Wildenhues wrote: * Peter Rosin wrote on Thu, Jan 29, 2009 at 06:53:48PM CET: But maybe, just maybe, you don't have a desperate need to do -std=c89 -Werror :-) Guys, if all you're working around is -Werror, then stop right now. Just eliminate -Werror from $LTCC $LTCFLAGS and be done with it. The cwrapper machinery, if it needs anything, then become simpler and less work to maintain, not more. Err...you're missing the point. We're trying to eliminate warnings under std=c89 and std=c99 (and, for that matter, under normal conditions). The way to detect whether we have successfully done so is to use std=c89 + -Werror, and detect the failure. stripping out -Werror...kinda makes eliminating warnings in cwrapper a little difficult, Now, I'm okay with just letting cwrapper.test fail if MSVC, or if your mingw-runtime is extremely old. All that means is that your *normal* compilation experience (without /WX, or -Werror) will be a little noisier than you might like (or might even fail, if you insist on using -std=c89 with a mingw-runtime that doesn't fully support c89 compliance). So, we don't have to make cwrapper -Werror clean right away, all at once, under all possible configurations. For instance: of the problems reported by Peter yesterday: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00195.html stat: missing decl - update your mingw-runtime; problem goes away P_WAIT: missing def - ditto _setmode: missing decl - ditto _spawnv: missing decl - ditto S_IXUSR: missing def - ditto _chmod: missing decl - ditto _getcwd: missing decl - ditto In fact, it looks to me like ALL of the problems Peter reported were caused by using an 2003-era mingw-runtime package (and these were actual errors, not -Werror warnings turned into errors). Well, ok then: libtool's cwrapper might not work with -std=c89 and a very very old mingw-runtime. Client should either (a) stop telling us -std=c89, or (b) update mingw-runtime. Either way, it's not *our* problem. And, as Roumen Petrov pointed out, the strtod failure was a bug in mingw-runtime, now fixed. So, again, no need for us to do anything about it. More in my followup in Akim's Ping? thread. -- Chuck
Re: Pings
Hi Charles, * Charles Wilson wrote on Fri, Jan 30, 2009 at 05:34:08AM CET: See earlier reply in this thread for why we don't need to worry about any other magic MSVC macros. So, I think the only remaining cleanup-warnings patch for the cwrapper is this: diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index 1c745f4..308a89a 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -3110,6 +3110,9 @@ func_emit_cwrapperexe_src () */ EOF cat EOF +#ifdef _MSC_VER +# define _CRT_SECURE_NO_DEPRECATE 1 +#endif #include stdio.h #include stdlib.h #ifdef _MSC_VER OK to push? Fine with me. Thanks for working through this! Cheers, Ralf
