coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

...is anyone else trying to build on Tru64? I'm using 4.0G to build, and 
I have a LOT of problems.


For starters, things went badly until I removed the #define for intmax_t 
from config.h.


shuf builds, but the linker complains about 'ftello unresolved', and 
then *produces a file* (but without +x), with the result that 'make' 
then thinks it has nothing to do to for target 'shuf' and continues on 
to "success" if re-run.


'make check' bombed because it failed to find perl (despite it being in 
my path the whole time), although it looks like my perl may be broken 
(didn't find strict.pm after I forcibly pointed the Makefile's at it). 
Building perl is not going to happen; after an hour trying to get the 
POS Configure to run I gave up and deleted it with extreme prejudice.


Instead I ran the 'make check' on a 5.1 box, and then got memory faults 
all over the place (log attached; I also have the full verbose run, but 
it's ~45kb bzip2'd).


So... has anyone else tried Tru64?

--
Matthew
"I don't question your existence -- God" (seen on a church billboard)
***
NOTICE: Some tests may be run only as root.
  Do `make check-root' as `root' to run these tests.
***
Making check in chgrp
make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp'
make  check-TESTS
make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp'
./no-x: this test requires that you be a member of more than one group,
but running `id -G' either failed or found just one.  If you really
are a member of at least two groups, then rerun this test with
COREUTILS_GROUPS set in your environment to the space-separated list
of group names or numbers.  E.g.,

  env COREUTILS_GROUPS='users cdrom' make check

SKIP: no-x
./posix-H: this test requires that you be a member of more than one group,
but running `id -G' either failed or found just one.  If you really
are a member of at least two groups, then rerun this test with
COREUTILS_GROUPS set in your environment to the space-separated list
of group names or numbers.  E.g.,

  env COREUTILS_GROUPS='users cdrom' make check

SKIP: posix-H
./basic: this test requires that you be a member of more than one group,
but running `id -G' either failed or found just one.  If you really
are a member of at least two groups, then rerun this test with
COREUTILS_GROUPS set in your environment to the space-separated list
of group names or numbers.  E.g.,

  env COREUTILS_GROUPS='users cdrom' make check

SKIP: basic
./deref: this test requires that you be a member of more than one group,
but running `id -G' either failed or found just one.  If you really
are a member of at least two groups, then rerun this test with
COREUTILS_GROUPS set in your environment to the space-separated list
of group names or numbers.  E.g.,

  env COREUTILS_GROUPS='users cdrom' make check

SKIP: deref
./recurse: this test requires that you be a member of more than one group,
but running `id -G' either failed or found just one.  If you really
are a member of at least two groups, then rerun this test with
COREUTILS_GROUPS set in your environment to the space-separated list
of group names or numbers.  E.g.,

  env COREUTILS_GROUPS='users cdrom' make check

SKIP: recurse
==
All 0 tests passed
(5 tests were not run)
==
make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp'
make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chgrp'
Making check in chmod
make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod'
make  check-TESTS
make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chmod'
PASS: inaccessible
PASS: c-option
PASS: equal-x
PASS: equals
PASS: no-x
PASS: octal
PASS: setgid
PASS: umask-x
PASS: usage
==
All 9 tests passed
==
make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod'
make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chmod'
Making check in chown
make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown'
make  check-TESTS
make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/chown'
***
NOTICE:
./basic: This test is being skipped, since it works only
when run as root.
***
SKIP: basic
PASS: deref
PASS: separator
==
All 2 tests passed
(1 tests were not run)
==
make[2]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown'
make[1]: Leaving directory `/home/install/gnu/src/coreutils-6.3/tests/chown'
Making check in cp
make[1]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp'
make  check-TESTS
make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp'
PASS: src-base-dot
./sparse: 343414 Memory fault
./sparse: 343422 Memory fault
./sp

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Paul Eggert]

mwoehlke <[EMAIL PROTECTED]> writes:

> things went badly until I removed the #define for
> intmax_t from config.h.

That's not a good sign.  In what way did they go badly, exactly?  What
diagnostics did you get?

> shuf builds, but the linker complains about 'ftello unresolved', and
> then *produces a file* (but without +x), with the result that 'make'
> then thinks it has nothing to do to for target 'shuf' and continues on
> to "success" if re-run.

I'll address this via separate email.

> make[2]: Entering directory `/home/install/gnu/src/coreutils-6.3/tests/cp'
> PASS: src-base-dot
> ./sparse: 343414 Memory fault
> ./sparse: 343422 Memory fault
> ./sparse: failure in testing framework
> FAIL: sparse

To get more info for failures like this, please try this:

cd /home/install/gnu/src/coreutils-6.3/tests/cp
VERBOSE=yes make check TESTS=sparse


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Paul Eggert]

mwoehlke <[EMAIL PROTECTED]> writes:

> shuf builds, but the linker complains about 'ftello unresolved', and
> then *produces a file* (but without +x), with the result that 'make'
> then thinks it has nothing to do to for target 'shuf' and continues on
> to "success" if re-run.

I installed this patch to Autoconf to try to address this problem.

2006-10-04  Paul Eggert  <[EMAIL PROTECTED]>

* lib/autoconf/general.m4 (_AC_COMPILE_IFELSE, _AC_LINK_IFELSE):
Use a single call to AC_DO_TOKENS rather than multiple, for
efficiency.
(_AC_LINK_IFELSE): Test that resulting file is executable.
Problem reported by mwoehlke in
.

--- lib/autoconf/general.m4 26 Sep 2006 20:43:43 -  1.931
+++ lib/autoconf/general.m4 4 Oct 2006 19:07:02 -
@@ -2358,8 +2358,10 @@ m4_define([_AC_COMPILE_IFELSE],
 [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
 rm -f conftest.$ac_objext
 AS_IF([_AC_DO_STDERR($ac_compile) &&
-_AC_DO_TOKENS([test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" || test ! 
-s conftest.err]) &&
-_AC_DO_TOKENS([test -s conftest.$ac_objext])],
+_AC_DO_TOKENS([{
+ test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+ test ! -s conftest.err
+   } && test -s conftest.$ac_objext])],
   [$2],
   [_AC_MSG_LOG_CONFTEST
$3])
@@ -2398,8 +2400,12 @@ m4_define([_AC_LINK_IFELSE],
 [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
 rm -f conftest.$ac_objext conftest$ac_exeext
 AS_IF([_AC_DO_STDERR($ac_link) &&
-_AC_DO_TOKENS([test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" || test ! 
-s conftest.err]) &&
-_AC_DO_TOKENS([test -s conftest$ac_exeext])],
+   _AC_DO_TOKENS([{
+  test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+  test ! -s conftest.err
+} &&
+test -s conftest$ac_exeext &&
+AS_EXECUTABLE_P([conftest$ac_exeext])])],
   [$2],
   [_AC_MSG_LOG_CONFTEST
$3])


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Paul Eggert]

mwoehlke <[EMAIL PROTECTED]> writes:

> ...is anyone else trying to build on Tru64? I'm using 4.0G to build,
> and I have a LOT of problems.

Yes, people build coreutils on Tru64, though 4.0G (released 2000-05) is
getting a bit old.  Have you applied all the relevant patches?  See
.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:


shuf builds, but the linker complains about 'ftello unresolved', and
then *produces a file* (but without +x), with the result that 'make'
then thinks it has nothing to do to for target 'shuf' and continues on
to "success" if re-run.


I installed this patch to Autoconf to try to address this problem.
[snip]


Thanks! However, unless you also have a patched 'configure' for me also, 
I'll just take your word for it. :-)


--
Matthew
This message will self destruct in five millennia.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:

...is anyone else trying to build on Tru64? I'm using 4.0G to build,
and I have a LOT of problems.


Yes, people build coreutils on Tru64, though 4.0G (released 2000-05) is
getting a bit old.  Have you applied all the relevant patches?  See
.


This isn't exactly "my" box; applying patches to it really isn't 
something I can do on a whim. If we drop 4.0* I can move to our 5.x 
boxes, but for now the box I'm building on is the same one we use to 
build our products, so I have to stick with it as-is. (At least it isn't 
the even-older 4.0F which is supposed to be what we actually *support*, 
and doesn't have [v]snprintf()!)


--
Matthew
This message will self destruct in five millennia.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:


things went badly until I removed the #define for
intmax_t from config.h.


That's not a good sign.  In what way did they go badly, exactly?  What
diagnostics did you get?


source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \
DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \
cc -std  -I. -I. -I.   -I/home/install/gnu/alpha_osf/include 
-g -c xstrtoimax.c
cc: Warning: ./config.h, line 1741: The redefinition of the macro 
"intmax_t" conflicts with a current definition because the replacement 
lists differ.  The redefinition is now in effect. (macroredef)

#define intmax_t long long
-^
cc: Error: xstrtol.c, line 53: In this declaration, the type of 
"strtoimax" is not compatible with the type of a previous declaration of 
"strtoimax" at line number 1039 in file ./inttypes.h. (notcompat)

intmax_t strtoimax ();
-^
cc: Warning: xstrtol.c, line 89: In this declaration, parameter 4 has a 
different type than specified in an earlier declaration of this 
function. (mismatparam)

__xstrtol (const char *s, char **ptr, int strtol_base,
^
cc: Error: xstrtol.c, line 89: In this declaration, the type of 
"xstrtoimax" is not compatible with the type of a previous declaration 
of "xstrtoimax" at line number 48 in file xstrtol.h. (notcompat)

__xstrtol (const char *s, char **ptr, int strtol_base,
^
make[2]: *** [xstrtoimax.o] Error 1
make[2]: Leaving directory 
`/home/install/gnu/src/coreutils-6.3-alpha_osf/lib'


...this all went away if I took out the redefinition of intmax_t. It 
appears to be conflicting with the definition in lib/stdint[_].h.


--
Matthew
This message will self destruct in five millennia.



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Ralf Wildenhues]

Hello Paul,

* Paul Eggert wrote on Wed, Oct 04, 2006 at 09:12:09PM CEST:
> mwoehlke <[EMAIL PROTECTED]> writes:
> 
> > shuf builds, but the linker complains about 'ftello unresolved', and
> > then *produces a file* (but without +x), with the result that 'make'
> > then thinks it has nothing to do to for target 'shuf' and continues on
> > to "success" if re-run.
> 
> I installed this patch to Autoconf to try to address this problem.

The patch does two entirely unrelated things:
- fix a bug
- some efficiency-related change.

The second change causes config.log output to be less readable,
as now the test spans multiple lines.  I think that's actually a
regression.  Can we undo that part?

Cheers,
Ralf

> 2006-10-04  Paul Eggert  <[EMAIL PROTECTED]>
> 
>   * lib/autoconf/general.m4 (_AC_COMPILE_IFELSE, _AC_LINK_IFELSE):
>   Use a single call to AC_DO_TOKENS rather than multiple, for
>   efficiency.
>   (_AC_LINK_IFELSE): Test that resulting file is executable.
>   Problem reported by mwoehlke in
>   .


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Paul Eggert]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> The second change causes config.log output to be less readable,
> as now the test spans multiple lines.  I think that's actually a
> regression.  Can we undo that part?

Better yet, let's not log that gorp at all.  All the user normally
cares about is that the compile or link succeeded or failed.  They
want to see the command that failed, but they don't want to see
the awful machinery we use to detect this.

Also, there's a bug in the werror_flag setting; someone sets it
to "no" who should set it to the empty string.  And the code
to check the preprocessor should be more consistent with the
code that checks the compiler and linker.

I installed this:

2006-10-06  Paul Eggert  <[EMAIL PROTECTED]>

* lib/autoconf/c.m4 (_AC_PROG_PREPROC_WORKS_IFELSE): Remove
comment about ac_cpp_err; it was incorrect, and anyway
ac_cpp_err is being removed below.
* lib/autoconf/general.m4 (_AC_PREPROC_IFELSE): Don't
set ac_cpp_err to 'yesyes' if preproc_warn_flag and werror_flag
are both 'yes'.  In fact, don't bother setting ac_cpp_err at all;
nobody uses it.
(_AC_COMPILE_IFELSE, _AC_LINK_IFELSE): Don't log our funky tests
with werror_flag and conftest.err and so forth.  This is more
compatible with how _AC_PROG_PREPROC_WORKS_IFELSE behaves,
and anyway the user shouldn't normally want to see this gorp logged.
Problem reported by Ralf Wildenhues.
* lib/autoconf/lang.m4 (AC_LANG_WERROR): werror_flag's default is
empty, not 'no', since the rest of the code uses 'test -z'.

Index: lib/autoconf/c.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.235
diff -p -u -r1.235 c.m4
--- lib/autoconf/c.m4   20 Sep 2006 18:07:47 -  1.235
+++ lib/autoconf/c.m4   6 Oct 2006 17:40:26 -
@@ -416,7 +416,6 @@ AC_DEFUN([AC_LANG_PREPROC(C)],
 # ---
 # Check if $ac_cpp is a working preprocessor that can flag absent
 # includes either by the exit status or by warnings.
-# Set ac_cpp_err to a non-empty value if the preprocessor failed.
 # This macro is for all languages, not only C.
 AC_DEFUN([_AC_PROG_PREPROC_WORKS_IFELSE],
 [ac_preproc_ok=false
Index: lib/autoconf/general.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/general.m4,v
retrieving revision 1.932
diff -p -u -r1.932 general.m4
--- lib/autoconf/general.m4 4 Oct 2006 19:10:49 -   1.932
+++ lib/autoconf/general.m4 6 Oct 2006 17:40:26 -
@@ -2272,23 +2272,15 @@ AC_DEFUN([AC_RUN_LOG],
 # Try to preprocess PROGRAM.
 #
 # This macro can be used during the selection of a preprocessor.
-# Run cpp and set ac_cpp_err to "yes" for an error, to
-# "$ac_(c,cxx)_preproc_warn_flag" if there are warnings or to "" if
-# neither warnings nor errors have been detected.  eval is necessary
-# to expand ac_cpp.
+# eval is necessary to expand ac_cpp.
 AC_DEFUN([_AC_PREPROC_IFELSE],
 [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
-if _AC_DO_STDERR([$ac_cpp conftest.$ac_ext]) >/dev/null; then
-  if test -s conftest.err; then
-ac_cpp_err=$ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag
-ac_cpp_err=$ac_cpp_err$ac_[]_AC_LANG_ABBREV[]_werror_flag
-  else
-ac_cpp_err=
-  fi
-else
-  ac_cpp_err=yes
-fi
-AS_IF([test -z "$ac_cpp_err"], [$2], [_AC_MSG_LOG_CONFTEST
+AS_IF([_AC_DO_STDERR([$ac_cpp conftest.$ac_ext]) >/dev/null && {
+test -z 
"$ac_[]_AC_LANG_ABBREV[]_preproc_warn_flag$ac_[]_AC_LANG_ABBREV[]_werror_flag" 
||
+test ! -s conftest.err
+   }],
+  [$2],
+  [_AC_MSG_LOG_CONFTEST
   $3])
 rm -f conftest.err m4_ifval([$1], [conftest.$ac_ext])[]dnl
 ])# _AC_PREPROC_IFELSE
@@ -2357,11 +2349,10 @@ AC_DEFUN([AC_EGREP_HEADER],
 m4_define([_AC_COMPILE_IFELSE],
 [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
 rm -f conftest.$ac_objext
-AS_IF([_AC_DO_STDERR($ac_compile) &&
-_AC_DO_TOKENS([{
- test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
- test ! -s conftest.err
-   } && test -s conftest.$ac_objext])],
+AS_IF([_AC_DO_STDERR($ac_compile) && {
+test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+test ! -s conftest.err
+   } && test -s conftest.$ac_objext],
   [$2],
   [_AC_MSG_LOG_CONFTEST
$3])
@@ -2399,13 +2390,11 @@ AU_DEFUN([AC_TRY_COMPILE],
 m4_define([_AC_LINK_IFELSE],
 [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
 rm -f conftest.$ac_objext conftest$ac_exeext
-AS_IF([_AC_DO_STDERR($ac_link) &&
-   _AC_DO_TOKENS([{
-  test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
-  test ! -s conftest.err
-} &&
-test -s conftest$ac_exeext &&
-AS_EXECUTABLE_P([conftest$ac_exeext])])],
+AS_IF([_AC_DO_STDERR($ac_link) && {
+test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" ||
+test ! -s conft

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[Paul Eggert]

mwoehlke <[EMAIL PROTECTED]> writes:

> source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \
> DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \
> cc -std  -I. -I. -I.   -I/home/install/gnu/alpha_osf/include -g -c 
> xstrtoimax.c
> cc: Warning: ./config.h, line 1741: The redefinition of the macro
> "intmax_t" conflicts with a current definition because the replacement
> lists differ.  The redefinition is now in effect. (macroredef)
> #define intmax_t long long
> -^

I think I see the problem now; you can't include , then
, then , due to  having some
semi-obsolescent definitions of intmax_t (due to gettext not yet
upgrading to assume inttypes.h).

I installed this into gnulib to fix things:

2006-10-08  Paul Eggert  <[EMAIL PROTECTED]>

Don't include  twice; this doesn't work in some cases,
e.g., when config.h has "#define intmax_t long long int" and
we include , ,  in that order.
Problem reported by Matthew Woehlke in:
http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00073.html
* fprintftime.c: Don't include config.h or fprintftime.h.
* fts-cycle.c: Don't include config.h.
* strftime.c: Include fprintftime.h if FPRINTFTIME is defined.
* xstrtoimax.c: Remove copyright notice since it's short tnow.
Don't include config.h or xstrtol.h.  Define STRTOL_T_MINIMUM
and STRTOL_T_MAXIMUM unconditionally, since we now assume gnulib
inttypes.h.
* xstrtoumax.c: Likewise.
* xstrtol.c: Include config.h and xstrtol.h after defining
__strtol and the like, so that this module is more like its siblings.
(STRTOL_T_MINIMUM, STRTOL_T_MAXIMUM) [! defined STRTOL_T_MINIMUM]:
Remove; no longer needed now that we assume gnulib inttypes.h.

Index: lib/fprintftime.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fprintftime.c,v
retrieving revision 1.2
diff -p -u -r1.2 fprintftime.c
--- lib/fprintftime.c   13 Sep 2006 22:38:14 -  1.2
+++ lib/fprintftime.c   8 Oct 2006 07:16:11 -
@@ -1,5 +1,2 @@
-#include 
-
-#include "fprintftime.h"
 #define FPRINTFTIME 1
 #include "strftime.c"
Index: lib/fts-cycle.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/fts-cycle.c,v
retrieving revision 1.6
diff -p -u -r1.6 fts-cycle.c
--- lib/fts-cycle.c 13 Sep 2006 22:38:14 -  1.6
+++ lib/fts-cycle.c 8 Oct 2006 07:16:11 -
@@ -18,8 +18,6 @@
along with this program; if not, write to the Free Software Foundation,
Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
 
-#include 
-
 #include "cycle-check.h"
 #include "hash.h"
 
Index: lib/strftime.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v
retrieving revision 1.90
diff -p -u -r1.90 strftime.c
--- lib/strftime.c  13 Sep 2006 22:38:14 -  1.90
+++ lib/strftime.c  8 Oct 2006 07:16:11 -
@@ -30,6 +30,9 @@
 # include "../locale/localeinfo.h"
 #else
 # include 
+# if FPRINTFTIME
+#  include "fprintftime.h"
+# endif
 #endif
 
 #include 
Index: lib/xstrtoimax.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/xstrtoimax.c,v
retrieving revision 1.8
diff -p -u -r1.8 xstrtoimax.c
--- lib/xstrtoimax.c13 Sep 2006 22:38:14 -  1.8
+++ lib/xstrtoimax.c8 Oct 2006 07:16:11 -
@@ -1,32 +1,6 @@
-/* xstrtoimax.c -- A more useful interface to strtoimax.
-
-   Copyright (C) 2001, 2003, 2004, 2006 Free Software Foundation, Inc.
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 2, or (at your option)
-   any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this program; if not, write to the Free Software Foundation,
-   Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.  */
-
-/* Cloned by Jim Meyering. */
-
-#include 
-
-#include "xstrtol.h"
-
 #define __strtol strtoimax
 #define __strtol_t intmax_t
 #define __xstrtol xstrtoimax
-#ifdef INTMAX_MAX
-# define STRTOL_T_MINIMUM INTMAX_MIN
-# define STRTOL_T_MAXIMUM INTMAX_MAX
-#endif
+#define STRTOL_T_MINIMUM INTMAX_MIN
+#define STRTOL_T_MAXIMUM INTMAX_MAX
 #include "xstrtol.c"
Index: lib/xstrtol.c
===
RCS file: /cvsroot/gnulib/gnulib/lib/xstrtol.c,v
retrieving revision 1.40
diff -p -u -r1.40 xstrtol.c
--- lib/xstrtol.c   13 Sep 2

Re: coreutils 6.3 on Tru64 - just plain broken, or...?

[mwoehlke]

Paul Eggert wrote:

mwoehlke <[EMAIL PROTECTED]> writes:

source='xstrtoimax.c' object='xstrtoimax.o' libtool=no \
DEPDIR=.deps depmode=tru64 /usr/bin/posix/sh ../build-aux/depcomp \
cc -std  -I. -I. -I.   -I/home/install/gnu/alpha_osf/include -g -c 
xstrtoimax.c
cc: Warning: ./config.h, line 1741: The redefinition of the macro
"intmax_t" conflicts with a current definition because the replacement
lists differ.  The redefinition is now in effect. (macroredef)
#define intmax_t long long
-^


I think I see the problem now; you can't include , then
, then , due to  having some
semi-obsolescent definitions of intmax_t (due to gettext not yet
upgrading to assume inttypes.h).

I installed this into gnulib to fix things:

[patch snipped]


Sounds good, thanks!

--
Matthew
"Try to bring it back in one piece this time." -- Q (MI6)



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils