[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[James Youngman]

On Fri, Jun 03, 2005 at 10:54:07PM +0200, Bruno Haible wrote:
> Derek Price asked:
> > In a recent discussion on bug-gnulib of the GNULIB stat & lstat modules,
> > GNULIB admins Jim Meyering, Bruno, and Paul Eggert agreed that it was no
> > longer useful to support SunOS 4.1.4 in GNULIB since even Sun stopped
> > supporting it over a year ago (handy dead OS reference here:
> > ).  Has this changed?
> 
> This has not changed: we don't support SunOS 4 any more in gnulib. But
> nevertheless, since James Youngman wants to support it for findutils, I
> try to be helpful anyway.

I'd like to clarify.  In response to Jason's question about a
compilation problem on SunOS 4.1.4 I suggested that the denizens of
bug-gnulib might be able to clarify the way forward for his particular
problem (e.g. whether they would accept a patch).

Findutils uses a substantial amount of gnulib code; I would not want
the gnulib maintainers to think that I thought they should put in
extra effort to maintain support for SunOS 4.1.4.  I don't have the
spare time to try to support SunOS 4.x either, so I wouldn't expect
you guys to support it.  I did say it "would be nice" if it worked,
but then it would be nice if everything in general worked.  Sadly,
maintainers' time is finite.

Regards,
James.





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

[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[Bruno Haible]

Derek Price asked:
> In a recent discussion on bug-gnulib of the GNULIB stat & lstat modules,
> GNULIB admins Jim Meyering, Bruno, and Paul Eggert agreed that it was no
> longer useful to support SunOS 4.1.4 in GNULIB since even Sun stopped
> supporting it over a year ago (handy dead OS reference here:
> ).  Has this changed?

This has not changed: we don't support SunOS 4 any more in gnulib. But
nevertheless, since James Youngman wants to support it for findutils, I
try to be helpful anyway.

Bruno



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

[bug-gnulib] Re: gcc -Wall warning for minmax.h

[Bruno Haible]

Derek Price wrote:
> Actually, `m4_popdef' is documented explicitly in my Autoconf 2.59
> manual.  The Autoconf 2.59 manual also contains the following text:
>
> With a few exceptions, all the M4 native macros are moved in the `m4_'
> pseudo-namespace, e.g., M4sugar renames `define' as `m4_define' etc.

Ah, right. I blindly searched for m4_pushdef in the manual and didn't find
it. (May I suggest that these renamed m4_* macros be added to the manual's
index, one by one?)

But AS_TR_* is actually undocumented, right?

Bruno



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

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

[Derek Price]

Bruno Haible wrote:

>>- use m4_pushdef/m4_popdef instead of define/undefine
>>- use AS_TR_* instead of raw m4_translit
>>
>>
>
>m4_pushdef, m4_popdef, AS_TR_* are not documented in the autoconf manual
>(latest release, 2.59). In consequence, their meaning can change, or they
>can go away entirely, without notice. Therefore, I don't wish to apply
>this patch.
>  
>

Actually, `m4_popdef' is documented explicitly in my Autoconf 2.59
manual.  The Autoconf 2.59 manual also contains the following text:

With a few exceptions, all the M4 native macros are moved in the `m4_'
pseudo-namespace, e.g., M4sugar renames `define' as `m4_define' etc.


Since the manual goes on to list the exceptions (including a slightly
different usage for `m4_popdef'), and the fact that `pushdef' is
documented in at least the GNU M4 1.4.1 manual and I would guess earlier
versions, I would consider `m4_pushdef' documented as well.

Cheers,

Derek



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

Re: [bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[Derek Price]

Bruno Haible wrote:

>James Youngman wrote:
>  
>
>>Certainly I believe that  should
>>define NULL (though my copy of the standard isn't to hand).
>>
>>
>
>On SunOS 4, it doesn't. GNU gettext has this ChangeLog entry:
>
>2001-10-31  Bruno Haible  <[EMAIL PROTECTED]>
>
>* plural.y: Include , needed for NULL with SunOS 4 cc.
>  
>

In a recent discussion on bug-gnulib of the GNULIB stat & lstat modules,
GNULIB admins Jim Meyering, Bruno, and Paul Eggert agreed that it was no
longer useful to support SunOS 4.1.4 in GNULIB since even Sun stopped
supporting it over a year ago (handy dead OS reference here:
).  Has this changed?

Regards,

Derek



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

[bug-gnulib] Re: gcc -Wall warning for minmax.h

[James Youngman]

On Fri, Jun 03, 2005 at 05:54:29PM +0200, Bruno Haible wrote:
> James Youngman wrote:
> > HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is
> > not.
> 
> Have you seen a system where this is the case? 

No, never. 

> The autoconf test assumes that when MIN is defined in a header, MAX
> will be defined as well, and vice versa.

It's not an unreasonable assumption.

James.


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

[bug-gnulib] Re: gcc -Wall warning for minmax.h

[Bruno Haible]

Stepan Kasal wrote:
> I read your macro in minmax.m4.  I'd like to propose some
> changes in style:
> - avoid the obsoleted AC_TRY_COMPILE

AC_TRY_COMPILE is shorter and more mnemonic than the *_IFELSE macros.

> - use m4_pushdef/m4_popdef instead of define/undefine
> - use AS_TR_* instead of raw m4_translit

m4_pushdef, m4_popdef, AS_TR_* are not documented in the autoconf manual
(latest release, 2.59). In consequence, their meaning can change, or they
can go away entirely, without notice. Therefore, I don't wish to apply
this patch.

Bruno



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

[bug-gnulib] Re: gcc -Wall warning for minmax.h

[Bruno Haible]

James Youngman wrote:
> HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is
> not.

Have you seen a system where this is the case? The autoconf test assumes
that when MIN is defined in a header, MAX will be defined as well, and
vice versa.

Bruno



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

[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[Bruno Haible]

James Youngman wrote:
> Certainly I believe that  should
> define NULL (though my copy of the standard isn't to hand).

On SunOS 4, it doesn't. GNU gettext has this ChangeLog entry:

2001-10-31  Bruno Haible  <[EMAIL PROTECTED]>

* plural.y: Include , needed for NULL with SunOS 4 cc.



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

[bug-gnulib] Re: removed some inaccurate uses of "pathname" etc. from gnulib modules

[Bruno Haible]

Paul Eggert wrote:
> Most of the changes come from the following part of the GNU
> coding standards:
>
>   Please do not use the term ``pathname'' that is used in Unix
>   documentation; use ``file name'' (two words) instead.  We use the term
>   ``path'' only for search paths, which are lists of directory names.

This citation is taken from the recommendations for GNU Manuals. As such,
it applies to source code only if you want to use the same speak in the
code as in the documentation.

IMO, for an end user, "file name" is really the better term, because the
user thinks to designate a file or directory. However, in implementation
code - such as path-concat - we the hackers think about the structure of
the string, with directory separators and dots etc. I think "pathname"
applies well to this context.

There are more differences between the language of different groups, such
as:

  end userprogrammer
  --

  program executable

  shared library  shared object

  character   combined character
  (since the user doesn't a base character
  and its attached combining characters as
  separate entities)

  file name   pathname

  block of memory page (of memory)

  user name   user fullname
  login name  user name

Etc.

For this reason, I don't see why I should rename the 'pathname' module.
It's not visible to the end user.

Bruno



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

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

[James Youngman]

On Fri, Jun 03, 2005 at 01:54:01PM +0200, Stepan Kasal wrote:

> +gl_CACHE_VAR,
> +[AC_COMPILE_IFELSE([#include <$1>
> + int x = MIN (42, 17);],
> +   [gl_CACHE_VAR=yes],
> +   [gl_CACHE_VAR=no])])
> +  if test $gl_CACHE_VAR = yes; then
> +AC_DEFINE([HAVE_MINMAX_IN_]AS_TR_CPP([$1]), 1,
>[Define to 1 if <$1> defines the MIN and MAX macros.])
>fi

Apologies for stating the obvious, but contrary to this description,
HAVE_MINMAX_IN_FOO_H is defined if MIN is defined in foo.h and MAX is
not.  Strictly speaking, we should change either the macro or the
description.

Regards,
James.


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

[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[jason andrade]

On Fri, 3 Jun 2005, James Youngman wrote:


Thanks for the bug report.  It would be nice if it did work.


i agree. but i am not holding my breath as

a) i'm sure the number of sunos4 users out there is very finite
b) the older version of findutils appears to work fine

but thanks for taking the time to send this really quick response.



4.1.4 and an irix 5.3 server available for developers interested in
testing/porting software to older OSes.


That could indeed be a useful resource.  However, I have a limited
amount of time available to work on findutils (and the other free
software project I work on) and so I have to prioritise some things
over others.  That means that although I would like to fix this, in
practice I can't take the time out to do it.


no worries.. the offer is open for as long as the hardware is around
so feel free to take me up on it if you're feeling particularly
masochistic one day.  i find about a day of compiling software on
sunos4 reminds me of how far software dev and packaging has come
along in 10+ years and why i don't want to go back.


bug-gnulib@gnu.org I hope that somebody on that list can confirm that
the problem as what I suspect and recommend a way forward.  That
suggestion might include sending a patch to the gnulib maintainers,
but it might not.


me too - i will poke around further and see what i can come up with.

regards,

-jason


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

Re: [bug-gnulib] Re: gcc -Wall warning for minmax.h

[Stepan Kasal]

Hi Bruno,

I read your macro in minmax.m4.  I'd like to propose some
changes in style:
- avoid the obsoleted AC_TRY_COMPILE
- use m4_pushdef/m4_popdef instead of define/undefine
- use AS_TR_* instead of raw m4_translit

A patch with my proposal is attached; it's not tested, sorry.

Could you please find some time to look at it?

[FYI: I'll be offline Jun 7 - Jun 21.]

Have a nice day,
Stepan
2005-06-03  Stepan Kasal  <[EMAIL PROTECTED]>

* minmax.m4 (gl_MINMAX_IN_HEADER): Use more modern macros.

Index: m4/minmax.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/minmax.m4,v
retrieving revision 1.1
diff -u -r1.1 minmax.m4
--- m4/minmax.m423 May 2005 10:25:53 -  1.1
+++ m4/minmax.m43 Jun 2005 11:53:03 -
@@ -19,20 +19,19 @@
 dnl gl_MINMAX_IN_HEADER(HEADER)
 AC_DEFUN([gl_MINMAX_IN_HEADER],
 [
-  define([header],[translit([$1],[./-],
- [___])])
-  define([HEADER],[translit([$1],[abcdefghijklmnopqrstuvwxyz./-],
- [ABCDEFGHIJKLMNOPQRSTUVWXYZ___])])
+  AC_PREREQ(2.50)
+  AS_LITERAL_IF([$1], [],
+[m4_fatal([gl_MINMAX_IN_HEADER requires a literal parameter.])])
+  m4_pushdef([gl_CACHE_VAR], gl_cv_minmax_in_[]AS_TR_SH([$1]))
   AC_CACHE_CHECK([whether <$1> defines MIN and MAX],
-[gl_cv_minmax_in_]header,
-[AC_TRY_COMPILE([#include <$1>
-int x = MIN (42, 17);], [],
-   [gl_cv_minmax_in_]header[=yes],
-   [gl_cv_minmax_in_]header[=no])])
-  if test $gl_cv_minmax_in_[]header = yes; then
-AC_DEFINE([HAVE_MINMAX_IN_]HEADER, 1,
+gl_CACHE_VAR,
+[AC_COMPILE_IFELSE([#include <$1>
+   int x = MIN (42, 17);],
+   [gl_CACHE_VAR=yes],
+   [gl_CACHE_VAR=no])])
+  if test $gl_CACHE_VAR = yes; then
+AC_DEFINE([HAVE_MINMAX_IN_]AS_TR_CPP([$1]), 1,
   [Define to 1 if <$1> defines the MIN and MAX macros.])
   fi
-  undefine([HEADER])
-  undefine([header])
+  m4_popdef([gl_CACHE_VAR])
 ])
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib

[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[Ian Abbott]

On 03/06/2005 09:34, James Youngman wrote:

[...]  Certainly I believe that  should
define NULL (though my copy of the standard isn't to hand).


Mine isn't either (that horribly annotated book), but draft standards 
are online, e.g. . 
According to that, NULL is defined in , , , 
,  and .


--
-=( Ian Abbott @ MEV Ltd.E-mail: <[EMAIL PROTECTED]>)=-
-=( Tel: +44 (0)161 477 1898   FAX: +44 (0)161 718 3587 )=-


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

[bug-gnulib] Re: findutils doesn't compile on sunos 4.1.4

[James Youngman]

On Fri, Jun 03, 2005 at 11:20:35AM +1000, jason andrade wrote:
> 
> hi,
> 
> just letting you know that findutils 4.2.20 doesn't seem to compile on 
> sunos 4.1.4.

Thanks for the bug report.  It would be nice if it did work.  

> the error is:
> 
> gcc -DHAVE_CONFIG_H -I. -I. -I../.. -g -O2 -c `test -f 'realloc.c' || 
> echo './'`realloc.c
> realloc.c: In function `rpl_realloc':
> realloc.c:40: `NULL' undeclared (first use in this function)
> realloc.c:40: (Each undeclared identifier is reported only once
> realloc.c:40: for each function it appears in.)
> make[4]: *** [realloc.o] Error 1
> make[4]: Leaving directory `/local/dev/build/findutils-4.2.20/gnulib/lib'
> make[3]: *** [all] Error 2
> make[3]: Leaving directory `/local/dev/build/findutils-4.2.20/gnulib/lib'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/local/dev/build/findutils-4.2.20/gnulib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/local/dev/build/findutils-4.2.20'
> make: *** [all] Error 2

The realloc.c file is part of gnulib (this mail CC'ed to
bug-gnulib@gnu.org).  These days, gnulib assumes that the software is
being built on a C89-compliant system.  I suspect that SunOS 4.1.4
isn't such a system.  Certainly I believe that  should
define NULL (though my copy of the standard isn't to hand).


> i'm happy to make this server available if needed - i have a sunos
> 4.1.4 and an irix 5.3 server available for developers interested in
> testing/porting software to older OSes.

That could indeed be a useful resource.  However, I have a limited
amount of time available to work on findutils (and the other free
software project I work on) and so I have to prioritise some things
over others.  That means that although I would like to fix this, in
practice I can't take the time out to do it.

However, I will usually accept patches to fix portabilty problems
(that is, I might not if the patch causes further problems elsewhere).
You should be aware however, that within the findutils distribution,
the "gnulib" subdirectory contains only pristine source code from the
gnulib project.  The way that findutils is built, packaged and
released (at the moment, at least) makes it impractical to ship a
modified version of gnulib.  Since I've copied this email to
bug-gnulib@gnu.org I hope that somebody on that list can confirm that
the problem as what I suspect and recommend a way forward.  That
suggestion might include sending a patch to the gnulib maintainers,
but it might not.

Thanks for your bug report.

Regards,
James Youngman.



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