Re: strings.h in argz.c?

2007-01-27 Thread Ralf Wildenhues
* Paul Eggert wrote on Mon, Jan 22, 2007 at 03:22:51AM CET:
 
 My experience is that everyone who's reported a bug against SunOS
 4.1.x for several years, is either (1) doing it only because they're
 worried we might still want to be portable to SunOS 4.1.x, or (2)
 maintaining a computer museum.  Neither of these cases are worth
 worrying about.

OK.

 Ralf Wildenhues [EMAIL PROTECTED] writes:
  Is it likely (in practice) to have math functions like sin, cos,
  available but not math.h?  Similarly, is it likely to have string
  functions but not string.h?
 
 Not these days, no.  However it is possible that a freestanding
 environment would have neither math.h nor the math functions.  PalmOS
 is one fairly-contemporary example.  It's less likely for string.h to
 be missing (PalmOS has it, albeit in a shim mode if memory serves).

OK, that's good enough for Libtool.  If a test fails due to missing
math.h, I won't be worried, if it would fail later anyway due to a
missing sine function.

* Simon Josefsson wrote on Mon, Jan 22, 2007 at 08:53:37AM CET:
 Ralf Wildenhues [EMAIL PROTECTED] writes:
 
  We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
  I'm not doing any C89 cleanup on branch-1-5.
 
 That's not a problem, I only meant it to apply to future version.  (I
 assume there will be future versions not based on branch-1-5 ;-)).

I do hope so, too.

  OTOH, the change may eventually cause 2 less header checks in user code;
  that is, once all other checks for string.h and strings.h are eliminated
  from their configury.
 
 Yes, and another problem might be code that checks for strings.h
 and/or memory.h, but not string.h.  It seems they might get the wrong
 headers..

Well, currently, Autoconf's _AC_INCLUDES_DEFAULT_REQUIREMENTS still
tests for these anyway.

 I don't know about math.h.  Math functions seem generally more
 optional than other functions to me, depending on platform.  If your
 patch only changed this for the self tests, that is probably OK, but
 it seems weird for libtool/ltdl to require math functions.

ACK.  Only the test suite requires them.

I applied the patch, with a NEWS bit added, to HEAD.

Cheers,
Ralf

Assume C89 for included headers, and throughout the testsuite.

* NEWS: Update.
* libltdl/argz.c: Do not include strings.h nor memory.h, include
string.h unconditionally.
Patch by Simon Josefsson [EMAIL PROTECTED].
* libltdl/libltdl/lt__private.h: Likewise.
* libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h,
strings.h, memory.h.
* tests/cdemo/configure.ac: Assume presence of math.h.
* tests/cdemo/foo.c: Likewise.
* tests/demo/configure.ac: Likewise for math.h, string.h.
Assume 'const'.  Drop obsolete AC_EXEEXT.
* tests/demo/dlmain.c: Likewise.
* tests/demo/foo.c: Likewise.
* tests/depdemo/configure.ac: Likewise.
* tests/depdemo/l4/l4.c: Likewise.
* tests/f77demo/configure.ac: Likewise.  Also drop obsolete
AC_OBJEXT.
* tests/fcdemo/configure.ac: Likewise.
* tests/mdemo/configure.ac: Likewise.
* tests/mdemo/foo1.c: Likewise.
* tests/mdemo/foo2.c: Likewise.
* tests/mdemo2/configure.ac: Likewise.
* tests/pdemo/configure.ac: Likewise.
* tests/pdemo/longer_file_name_dlmain.c:
* tests/pdemo/longer_file_name_foo.c: Likewise.
* tests/pdemo/longer_file_name_foo2.c: Likewise.
* tests/tagdemo/configure.ac: Likewise.
* tests/tagdemo/foo.cpp: Likewise.

Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.197
diff -u -r1.197 NEWS
--- NEWS24 Oct 2006 20:17:37 -  1.197
+++ NEWS27 Jan 2007 16:44:19 -
@@ -36,6 +36,9 @@
 * Initial support for the Sun compiler suite on GNU/Linux.
 * Improved support for GNU/kFreeBSD and GNU/NetBSD.
 * Search paths with GCC on multilib systems like x86_64 have been fixed.
+* The Libtool and libltdl macros and the testsuite now assume a C89
+  environment, consequently do not test for headers such as string.h,
+  strings.h, memory.h any more.
 * Bug fixes.
 
 New in 1.9f: 2004-10-23; CVS version 1.9e, Libtool team:


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


Re: strings.h in argz.c?

2007-01-22 Thread Simon Josefsson
Ralf Wildenhues [EMAIL PROTECTED] writes:

 We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
 I'm not doing any C89 cleanup on branch-1-5.

That's not a problem, I only meant it to apply to future version.  (I
assume there will be future versions not based on branch-1-5 ;-)).

 OTOH, the change may eventually cause 2 less header checks in user code;
 that is, once all other checks for string.h and strings.h are eliminated
 from their configury.

Yes, and another problem might be code that checks for strings.h
and/or memory.h, but not string.h.  It seems they might get the wrong
headers..

I don't know about math.h.  Math functions seem generally more
optional than other functions to me, depending on platform.  If your
patch only changed this for the self tests, that is probably OK, but
it seems weird for libtool/ltdl to require math functions.

 WDYT?
...
   * libltdl/argz.c: Do not include strings.h nor memory.h, include
   string.h unconditionally.
   Patch by Simon Josefsson [EMAIL PROTECTED].

I like this part. :-)

Thanks,
Simon


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


Re: strings.h in argz.c?

2007-01-21 Thread Ralf Wildenhues
Hello Simon,

Apologies for the long delay.

* Simon Josefsson wrote on Mon, Oct 30, 2006 at 01:46:30PM CET:
 Bruno Haible [EMAIL PROTECTED] writes:

  Is strings.h needed on any modern platform?
 
  No.

 I see that argz.c comes from libtool.  Would this patch be acceptable?
 I'm cc:ing bug-libtool in case they have some legacy priority that
 demand strings.h.

We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
I'm not doing any C89 cleanup on branch-1-5.

* Bruno Haible wrote on Mon, Oct 30, 2006 at 03:06:54PM CET:
 Simon Josefsson wrote:
  I assume that memory.h is a side-effect of using strings.h, and that
  memory.h is not needed today either?
 
 Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11,
 OSF/1 4.0, the contents of memory.h is also available through string.h.

Thanks.  Here's a quick audit of Libtool CVS HEAD to assume more of C89.
I'm really not sure whether I should apply it: the mere prospect of
lessening testsuite exposure on older hosts seems to me that it could
easily be more of a problem than the few, half a decade old lines that
nobody has needed to touch in a long time.

OTOH, the change may eventually cause 2 less header checks in user code;
that is, once all other checks for string.h and strings.h are eliminated
from their configury.

WDYT?

Cheers,
Ralf

2007-01-21  Ralf Wildenhues  [EMAIL PROTECTED]

Assume C89.
* libltdl/argz.c: Do not include strings.h nor memory.h, include
string.h unconditionally.
Patch by Simon Josefsson [EMAIL PROTECTED].
* libltdl/libltdl/lt__private.h: Likewise.
* libltdl/m4/ltdl.m4 (LTDL_INIT): Do not check for string.h,
strings.h, memory.h.
* tests/cdemo/configure.ac: Assume presence of math.h.
* tests/cdemo/foo.c: Likewise.
* tests/demo/configure.ac: Likewise for math.h, string.h.
Assume 'const'.  Drop obsolete AC_EXEEXT.
* tests/demo/dlmain.c: Likewise.
* tests/demo/foo.c: Likewise.
* tests/depdemo/configure.ac: Likewise.
* tests/depdemo/l4/l4.c: Likewise.
* tests/f77demo/configure.ac: Likewise.  Also drop obsolete
AC_OBJEXT.
* tests/fcdemo/configure.ac: Likewise.
* tests/mdemo/configure.ac: Likewise.
* tests/mdemo/foo1.c: Likewise.
* tests/mdemo/foo2.c: Likewise.
* tests/mdemo2/configure.ac: Likewise.
* tests/pdemo/configure.ac: Likewise.
* tests/pdemo/longer_file_name_dlmain.c:
* tests/pdemo/longer_file_name_foo.c: Likewise.
* tests/pdemo/longer_file_name_foo2.c: Likewise.
* tests/tagdemo/configure.ac: Likewise.
* tests/tagdemo/foo.cpp: Likewise.

Index: libltdl/argz.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/argz.c,v
retrieving revision 1.9
diff -u -r1.9 argz.c
--- libltdl/argz.c  24 Oct 2006 20:33:38 -  1.9
+++ libltdl/argz.c  21 Jan 2007 15:49:45 -
@@ -1,5 +1,5 @@
 /* argz.c -- argz implementation for non-glibc systems
-   Copyright (C) 2004, 2006 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2006, 2007 Free Software Foundation, Inc.
Originally by Gary V. Vaughan  [EMAIL PROTECTED]
 
NOTE: The canonical source of this file is maintained with the
@@ -40,15 +40,7 @@
 #include stdlib.h
 #include sys/types.h
 #include errno.h
-
-#if defined(HAVE_STRING_H)
-#  include string.h
-#elif defined(HAVE_STRINGS_H)
-#  include strings.h
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
+#include string.h
 
 #define EOS_CHAR '\0'
 
Index: libltdl/libltdl/lt__private.h
===
RCS file: /cvsroot/libtool/libtool/libltdl/libltdl/lt__private.h,v
retrieving revision 1.10
diff -u -r1.10 lt__private.h
--- libltdl/libltdl/lt__private.h   26 Oct 2006 20:39:04 -  1.10
+++ libltdl/libltdl/lt__private.h   21 Jan 2007 15:49:47 -
@@ -1,5 +1,5 @@
 /* lt__private.h -- internal apis for libltdl
-   Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
+   Copyright (C) 2004, 2005, 2006, 2007 Free Software Foundation, Inc.
Originally by Gary V. Vaughan  [EMAIL PROTECTED]
 
NOTE: The canonical source of this file is maintained with the
@@ -40,22 +40,12 @@
 #include ctype.h
 #include assert.h
 #include errno.h
+#include string.h
 
 #if defined(HAVE_UNISTD_H)
 #  include unistd.h
 #endif
 
-#if defined(HAVE_STRING_H)
-#  include string.h
-#else
-#  if defined(HAVE_STRINGS_H)
-#include strings.h
-#  endif
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
-
 /* Import internal interfaces...  */
 #include lt__alloc.h
 #include lt__dirent.h
Index: libltdl/m4/ltdl.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/ltdl.m4,v
retrieving revision 1.30
diff -u -r1.30 ltdl.m4
--- libltdl/m4/ltdl.m4  25 Aug 2006 15:04:30 -  

Re: strings.h in argz.c?

2007-01-21 Thread Paul Eggert
Ralf Wildenhues [EMAIL PROTECTED] writes:

 We got a bug report about Libtool 1.5.22 and SunOS 4.1.x this year, so
 I'm not doing any C89 cleanup on branch-1-5.

this year meaning 2007?  Or in the last 12 months?

I searched for such a bug report and found only
http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg00021.html
which mentions m68k SunOS 4.1.1 and sparc sunos 4.1.4.  However, in
http://lists.gnu.org/archive/html/bug-libtool/2006-06/msg00025.html
you asked Does anybody actually use these systems outside of a
museum?, noting that Sun itself dropped support for these operating
systems long ago, and didn't get a response.

I just checked
http://www.sun.com/service/eosl/solaris/solaris_vintage_eol_5.2005.xml,
and Sun stopped fixing bugs in SunOS 4.1.1 on 1997-01-06 and in SunOS
4.1.4 on 2000-09-30, and stopped giving advice about them on
2000-01-76 and 2003-09-30 respectively.

Obviously it's up to you as to whether to do C89 cleanup, but if that
bug report is what we're talking about, I wouldn't worry about it.

On the other hand, is libtool supposed to address the problem of
freestanding C compilers?  If so, the only headers it is allowed to
assume are float.h, limits.h, stdarg.h, and stddef.h.  If
memory serves, gnulib sometimes assumes freestanding, but more often
hosted.


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


Re: strings.h in argz.c?

2007-01-03 Thread Simon Josefsson
Hi!  I have had a patch for argz.c sitting in my local gnulib tree for
a while, discussed on the bug-gnulib list some time ago.  It seems as
if special string.h vs strings.h handling is not needed any more.
Argz is the only remaining module in gnulib which still includes the
header.  See the discussion below.

Would you consider installing the patch below in libtool?

Thanks,
Simon

Simon Josefsson [EMAIL PROTECTED] writes:

 Bruno Haible [EMAIL PROTECTED] writes:

 Simon Josefsson wrote:
 #if defined(HAVE_STRING_H)
 #  include string.h
 #elif defined(HAVE_STRINGS_H)
 #  include strings.h
 #endif
 #if defined(HAVE_MEMORY_H)
 #  include memory.h
 #endif
 
 Is strings.h needed on any modern platform?

 No.
 1) string.h exists on all platforms, for several years now.
The #elif branch in the above code is therefore never executed.
 2) There are a few other functions defined in glibc strings.h, but they
are not useful. See
http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00113.html

 I assume that memory.h is a side-effect of using strings.h, and that
 memory.h is not needed today either?

 I see that argz.c comes from libtool.  Would this patch be acceptable?
 I'm cc:ing bug-libtool in case they have some legacy priority that
 demand strings.h.

 /Simon

Index: argz.c
===
RCS file: /sources/gnulib/gnulib/lib/argz.c,v
retrieving revision 1.8
diff -u -p -r1.8 argz.c
--- argz.c  24 Oct 2006 20:40:29 -  1.8
+++ argz.c  3 Jan 2007 12:33:47 -
@@ -32,15 +32,7 @@
 #include stdlib.h
 #include sys/types.h
 #include errno.h
-
-#if defined(HAVE_STRING_H)
-#  include string.h
-#elif defined(HAVE_STRINGS_H)
-#  include strings.h
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
+#include string.h
 
 #define EOS_CHAR '\0'
 


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


Re: strings.h in argz.c?

2006-10-30 Thread Simon Josefsson
Bruno Haible [EMAIL PROTECTED] writes:

 Simon Josefsson wrote:
 #if defined(HAVE_STRING_H)
 #  include string.h
 #elif defined(HAVE_STRINGS_H)
 #  include strings.h
 #endif
 #if defined(HAVE_MEMORY_H)
 #  include memory.h
 #endif
 
 Is strings.h needed on any modern platform?

 No.
 1) string.h exists on all platforms, for several years now.
The #elif branch in the above code is therefore never executed.
 2) There are a few other functions defined in glibc strings.h, but they
are not useful. See
http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00113.html

I assume that memory.h is a side-effect of using strings.h, and that
memory.h is not needed today either?

I see that argz.c comes from libtool.  Would this patch be acceptable?
I'm cc:ing bug-libtool in case they have some legacy priority that
demand strings.h.

/Simon

--- argz.c  25 Oct 2006 13:16:14 +0200  1.8
+++ argz.c  30 Oct 2006 13:44:32 +0100  
@@ -32,15 +32,7 @@
 #include stdlib.h
 #include sys/types.h
 #include errno.h
-
-#if defined(HAVE_STRING_H)
 #  include string.h
-#elif defined(HAVE_STRINGS_H)
-#  include strings.h
-#endif
-#if defined(HAVE_MEMORY_H)
-#  include memory.h
-#endif
 
 #define EOS_CHAR '\0'
 


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


Re: strings.h in argz.c?

2006-10-30 Thread Bruno Haible
Simon Josefsson wrote:
 I assume that memory.h is a side-effect of using strings.h, and that
 memory.h is not needed today either?

Yes. Even on older systems like Solaris 2.4, AIX 4.3, IRIX 6.5, HP-UX 11,
OSF/1 4.0, the contents of memory.h is also available through string.h.

Bruno


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