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
Pings
Hi friends,
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 :)
- 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.
- distcc nuisances in the test suite
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00017.html
- nuke warnings in the wrappers
The patch at the end of
http://lists.gnu.org/archive/html/libtool/2008-12/msg00069.html
- 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.
diff --git a/libltdl/m4/lt-dummies.m4 b/libltdl/m4/lt-dummies.m4
new file mode 100644
index 000..7914928
--- /dev/null
+++ b/libltdl/m4/lt-dummies.m4
@@ -0,0 +1,4 @@
+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.
From 64080437c46f605b76917c03aec528884451dbf8 Mon Sep 17 00:00:00 2001
From: Akim Demaille
Date: Mon, 5 Jan 2009 11:56:24 +0100
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.
---
tests/defs.m4sh | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/tests/defs.m4sh b/tests/defs.m4sh
index 27c6f77..58296da 100644
--- a/tests/defs.m4sh
+++ b/tests/defs.m4sh
@@ -2,7 +2,7 @@ AS_INIT[]m4_divert_push([HEADER-COPYRIGHT])dnl
# @configure_input@
# defs -- Defines for Libtool testing environment.
#
-# Copyright (C) 2003, 2004, 2005, 2007, 2008 Free Software
+# Copyright (C) 2003, 2004, 2005, 2007, 2008, 2009 Free Software
# Foundation, Inc.
# Written by Gord Matzigkeit, 1996
# Rewritten by Gary V. Vaughan, 2003
@@ -102,7 +102,7 @@ func_get_config ()
my_build_regex=false
fi
my_first=:
-
+
for my_varname in $my_varname_list; do
if $my_build_regex; then
$my_first || my_regex="$my_regex|"
@@ -247,9 +247,7 @@ func_make ()
$opt_debug
my_args=${1+"$@"}
func_dirname_and_basename "`pwd`"
-my_dir=$func_basename_result
-
-func_msg "Running \`$MAKE $my_args' in $my_dir"
+func_msg "Running \`$MAKE $my_args' in $func_basename_result"
eval $MAKE $my_args || exit $EXIT_FAIL
}
@@ -288,7 +286,8 @@ func_make_uninstall ()
func_exec_init ()
{
$opt_debug
-func_msg "Executing $1 programs in $my_dir"
+func_dirname_and_basename "`pwd`"
+func_msg "Executing $1 programs in $func_basename_result"
# Windows hosts search for dlls in the command path
PATH=$prefix/lib:$PATH
@@ -359,4 +358,3 @@ func_msg "Running $progname"
# sh-indentation:2
# End:
]])
-
--
1.6.0.4.790.gaa14a
Thanks!
Re: Status of the MSYS/MSVC port
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
Roumen
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: 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
