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: 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: 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: 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: Status of the MSYS/MSVC port
Den 2009-01-28 04:25 skrev Charles Wilson:
Peter Rosin wrote:
On MSYS/MinGW, stresstest.at now passes when Run tests with low
max_cmd_len, that fails on git master. On the other hand, cwrapper for
uninstalled executables fails at cwrapper.at:78 (both with and without
low max_cmd_len). It's the second time through the loop that fails, when
restrictive_flags='-std=c89 -Wall -Werror' (an attempt to execute the
missing usea.exe). The root cause is that when linking, the compile of
the wrapper fails with various implicitly declared (or undeclared)
identifiers - usea.exe goes MIA. But that test behaves the exact same
way on a pure libtool from git master, so move on, nothing to see
here...
Odd. I thought one of my recent patches (git diff 0aef3579..6631e515)
fixed those. Do we need to add more stuff
/* declarations of non-ANSI functions */
#if defined(__MINGW32__)
# ifdef __STRICT_ANSI__
HERE?
Maybe, here are the errors:
../../tests/cwrapper.at:76: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o
usea$EXEEXT usea.$OBJEXT liba.la
stderr:
./.libs/lt-usea.c: In function `main':
./.libs/lt-usea.c:221: warning: implicit declaration of function `_setmode'
./.libs/lt-usea.c:370: warning: implicit declaration of function `_spawnv'
./.libs/lt-usea.c:370: error: `_P_WAIT' undeclared (first use in this function)
./.libs/lt-usea.c:370: error: (Each undeclared identifier is reported only once
./.libs/lt-usea.c:370: error: for each function it appears in.)
./.libs/lt-usea.c: In function `check_executable':
./.libs/lt-usea.c:421: error: storage size of 'st' isn't known
./.libs/lt-usea.c:428: warning: implicit declaration of function `_stat'
./.libs/lt-usea.c:429: error: `S_IXUSR' undeclared (first use in this function)
./.libs/lt-usea.c:421: warning: unused variable `st'
./.libs/lt-usea.c: In function `make_executable':
./.libs/lt-usea.c:439: error: storage size of 'st' isn't known
./.libs/lt-usea.c:448: warning: implicit declaration of function `_chmod'
./.libs/lt-usea.c:448: error: `S_IXUSR' undeclared (first use in this function)
./.libs/lt-usea.c:439: warning: unused variable `st'
./.libs/lt-usea.c: In function `find_executable':
./.libs/lt-usea.c:521: warning: implicit declaration of function `_getcwd'
./.libs/lt-usea.c:521: warning: comparison between pointer and integer
./.libs/lt-usea.c:546: warning: comparison between pointer and integer
C:\MinGW\bin\strip.exe: ./usea.exe: No such file or directory
./libtool: $func_ltwrapper_scriptname_result: ambiguous redirect
stdout:
libtool: link: gcc -g -O2 -std=c89 -Wall -Werror -o .libs/usea.exe usea.o
./.libs/liba.dll.a -L/foo
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
#ifndef _STAT_DEFINED
struct _stat
{
_dev_t st_dev; /* Equivalent to drive number 0=A 1=B ... */
_ino_t st_ino; /* Always zero ? */
_mode_t st_mode;/* See above constants */
short st_nlink; /* Number of links. */
short st_uid; /* User: Maybe significant on NT ? */
short st_gid; /* Group: Ditto */
_dev_t st_rdev;/* Seems useless (not even filled in) */
_off_t st_size;/* File size in bytes */
time_t st_atime; /* Accessed date (always 00:00 hrs local
* on FAT) */
time_t st_mtime; /* Modified time */
time_t st_ctime; /* Creation time */
};
#endif /* _STAT_DEFINED */
int _stat (const char *, struct _stat *);
#ifndef S_IXUSR /* just in case */
# defineS_IXUSR _S_IXUSR
#endif
int _chmod (const char *, int);
char * _getcwd (char *, int);
But IMHO, the struct _stat declaration is horrible to have in the
code. Shouldn't we just #undef __STRICT_ANSI__ before we include
anything or something? It's not as if that define helps...
Cheers,
Peter
Re: Status of the MSYS/MSVC port
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:
On MSYS/MinGW, stresstest.at now passes when Run tests with low
max_cmd_len, that fails on git master. On the other hand, cwrapper for
uninstalled executables fails at cwrapper.at:78 (both with and without
low max_cmd_len).
MSYS/MinGW, *not* msvc?
Now, if there are MSVC problems, we'll have to fix those, too. But I
want to be clear on exactly what we're discussing...
int _stat (const char *, struct _stat *);
#ifndef S_IXUSR /* just in case */
# defineS_IXUSR_S_IXUSR
#endif
int _chmod (const char *, int);
char * _getcwd (char *, int);
But IMHO, the struct _stat declaration is horrible to have in the
code. Shouldn't we just #undef __STRICT_ANSI__ before we include
anything or something? It's not as if that define helps...
Well, it's not just __STRICT_ANSI__, it's also _POSIX_ sometimes. Maybe
you're right, and we should #undef __STRICT_ANSI__ and #def _POSIX_
before including headers. However, adding a few more function
declarations is not so bad...so I could go either way, so long as we
figure out why you're not getting the struct _stat declaration.
--
Chuck
Re: Status of the MSYS/MSVC port
Den 2009-01-28 23:36, skrev Roumen Petrov:
Peter Rosin wrote:
Den 2009-01-28 04:25 skrev Charles Wilson:
Peter Rosin wrote:
[SNIP]
#ifndef _STAT_DEFINED
struct _stat
{
[SNIP]
};
#endif /* _STAT_DEFINED */
int _stat (const char *, struct _stat *);
[SNIP]
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.
According to MSDN:
Function _stat is linked to __stat64i32 or __stat32 if _USE_32BIT_TIME_T
is defined. I post initial version of a patch as feature request to
mingw tracker that implement 64 bit time if __MSVCRT_VERSION__ =
0x0800. My patch need independent tests and confirmation but this is
mingw issue.
time_t = 32 for = MSVC NET(?), i.e. msvcrt 8.0
time_t = 64/32 for MSVC 2003, i.e msvcrt = 8.0
This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e.
compatible with MSVC 6, so we're safe. I think. Famous last words...
Cheers,
Peter
Re: Status of the MSYS/MSVC port
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'll get back when I hace inspected some preprocessor output...
On MSYS/MinGW, stresstest.at now passes when Run tests with low
max_cmd_len, that fails on git master. On the other hand, cwrapper for
uninstalled executables fails at cwrapper.at:78 (both with and without
low max_cmd_len).
MSYS/MinGW, *not* msvc?
Yes.
Now, if there are MSVC problems, we'll have to fix those, too. But I
want to be clear on exactly what we're discussing...
No problems on MSVC (perhaps because we're not trying its -Werror switch,
i.e. -WX).
Cheers,
Peter
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: [SNIP] This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e. compatible with MSVC 6, so we're safe. I think. Famous last words... It seems to me that I misunderstood report failure and the case. It start for ms compiler why #ifdef __MINGW32__ is now involved ? Cheers, Peter 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 Roumen
Re: Status of the MSYS/MSVC port
Roumen Petrov wrote: Peter Rosin wrote: [SNIP] This was all inside #ifdef __MINGW32__, which assumes msvcrt.dll, i.e. compatible with MSVC 6, so we're safe. I think. Famous last words... It seems to me that I misunderstood report failure and the case. It start for ms compiler why #ifdef __MINGW32__ is now involved ? Peter included three different topics in his original post that began this thread. #1 was Status of the MSYS/MSVC port. #2 was a single sentcence: make check-local on Cygwin/gcc is clean with this flavor of libtool. #3 was On MSYS/MinGW, stresstest.at now passes when Run tests with low max_cmd_len, that fails on git master. On the other hand, cwrapper for uninstalled executables fails at cwrapper.at:78 We are currently on a subthread concerning #3 (although there is some confusion about /that/, too -- which is why Peter is inspecting his pre-processed source code right now...) -- Chuck
Re: Status of the MSYS/MSVC port
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
Status of the MSYS/MSVC port
Hi! With a bunch of pending patches [1] applied, the status of the pr-msvc-support branch is as follows, when bootstrapped on Cygwin (autoconf 2.63, automake 1.10.1) and configured on MSYS (autoconf 2.61, automake 1.10) in a subdir with: ../configure CC=cl CFLAGS='-MD -Zi' CXX=cl CXXFLAGS='-MD -Zi' LD=link \ NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: F77=no FC=no I also have a MinGW install accessible from the MSYS tree, and I think some tool(s) from it (objdump?) might still be used at some point. cl, link, lib and friends are from MSVC 8 (2005). Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 It *should* work for MSVC 6 as well, and I see no reason why it shouldn't also work for MSVC 7, 7.1 and 9 (famous last words). It's been a while since I tested on MSVC 6 though, and the other versions are virtually untested in this context. ## -- ## ## libtool 2.2.7a test suite. ## ## -- ## Libtoolize operation. 1: libtoolize macro installation ok 2: libtoolize macro directory mismatch error ok 3: libtoolize macro serial update ok 4: libtoolize config files serial update ok 5: diagnose missing LT_CONFIG_LTDL_DIR ok 6: copy ltdl.m4 with shared macro directoryok 7: correctly parse LTDL_INIT from configure.ac ok 8: diagnose missing LTDL_INIT invocation ok 9: upgrading verbatim style aclocal.m4 ok 10: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR ok 11: nonrecursive ltdl with AC_CONFIG_MACRO_DIR ok 12: subproject ltdl with non-shared directories ok 13: LIBTOOLIZE_OPTIONS ok 14: cleanup old installationok Testing libtool functions. 15: duplicate members in archive tests ok 16: duplicate convenience archive names skipped (duplicate_conv.at:80) 17: preserve duplicate convenience deps skipped (duplicate_deps.at:66) 18: inherited_linker_flags ok 19: C convenience archives ok 20: C++ convenience archivesok 21: F77 convenience archivesskipped (convenience.at:110) 22: FC convenience archives skipped (convenience.at:170) 23: Java convenience archives skipped (convenience.at:230) 24: Link order test ok 25: Link order of deplibs ok 26: Failure tests ok 27: shlibpath_overrides_runpath skipped (shlibpath.at:54) 28: Runpath in libtool library filesok 29: static linking flags for programs FAILED (static.at:197) 30: ccache -all-static ok 31: Export test ok 32: sys_lib_search_path skipped (search-path.at:57) 33: indirect convenienceok 34: indirect uninstalledok 35: static library contains static library UNEXPECTED PASS 36: both of -o prog and -o prog$EXEEXT work ok 37: execute modeok 38: cwrapper for uninstalled executablesok 39: inferred tagok 40: CXX inferred tagok 41: F77 inferred tagskipped (infer-tag.at:56) 42: FC inferred tag skipped (infer-tag.at:70) 43: GCJ inferred tagskipped (infer-tag.at:84) 44: localized compiler messages ok 45: nocase library search ok 46: Install tests ok DESTDIR tests 47: Simple DESTDIR install ok 48: DESTDIR with in-package deplibs ok Support for older m4 interface. 49: AM_PROG_LIBTOOL ok 50: AC_WITH_LTDLok Libtool subdir-objects support. 51: C subdir-objectsok 52: C++ subdir-objects FAILED (am-subdir.at:148) Libltdl functionality. 53: lt_dlexit unloading libsok 54: lt_dlopenadvise library loading ok 55: ltdl APIok 56: enforced lib prefix ok Standalone Libltdl. 57: compiling softlinked libltdlok 58: compiling copied libltdlok 59: installable libltdl ok 60: linking libltdl without autotools ok Subproject Libltdl. 61: compiling softlinked libltdlok 62: compiling copied libltdlok 63:
Re: Status of the MSYS/MSVC port
Peter Rosin wrote: On MSYS/MinGW, stresstest.at now passes when Run tests with low max_cmd_len, that fails on git master. On the other hand, cwrapper for uninstalled executables fails at cwrapper.at:78 (both with and without low max_cmd_len). It's the second time through the loop that fails, when restrictive_flags='-std=c89 -Wall -Werror' (an attempt to execute the missing usea.exe). The root cause is that when linking, the compile of the wrapper fails with various implicitly declared (or undeclared) identifiers - usea.exe goes MIA. But that test behaves the exact same way on a pure libtool from git master, so move on, nothing to see here... Odd. I thought one of my recent patches (git diff 0aef3579..6631e515) fixed those. Do we need to add more stuff /* declarations of non-ANSI functions */ #if defined(__MINGW32__) # ifdef __STRICT_ANSI__ HERE? -- Chuck
