Re: link-warning a build-aux file?

[Jim Meyering]

Simon Josefsson <[EMAIL PROTECTED]> wrote:
...
> I tried that now, since I kind of agree with the reasoning, although
> this breaks the maintainer-makefile module that I'm using in several
> projects.  The module contains a 'GNUmakefile' that really need to be
> in the top-level directory to make sense.  Any ideas how to resolve
> that?

Hi Simon,
Your module could include a tiny configure.ac snippet to run this

ln -s build-aux/GNUmakefile .

That'll work as long as no GNUmakefile rule is supposed to run ./configure.
Then a Makefile snippet to remove it:

MOSTLYCLEANFILES += GNUmakefile

Re: link-warning a build-aux file?

[Simon Josefsson]

Jim Meyering <[EMAIL PROTECTED]> writes:

> Simon Josefsson <[EMAIL PROTECTED]> wrote:
> ...
>> I tried that now, since I kind of agree with the reasoning, although
>> this breaks the maintainer-makefile module that I'm using in several
>> projects.  The module contains a 'GNUmakefile' that really need to be
>> in the top-level directory to make sense.  Any ideas how to resolve
>> that?
>
> Hi Simon,
> Your module could include a tiny configure.ac snippet to run this
>
> ln -s build-aux/GNUmakefile .
>
> That'll work as long as no GNUmakefile rule is supposed to run ./configure.
> Then a Makefile snippet to remove it:
>
> MOSTLYCLEANFILES += GNUmakefile

Unfortunately, I have GNUmakefile rules that run both autoreconf and
configure...  I have a maint-mk.cfg which contains among other things:

,
| ifeq ($(.DEFAULT_GOAL),abort-due-to-no-makefile)
| .DEFAULT_GOAL := bootstrap
| endif
| 
| autoreconf:
|   test -f ./configure || autoreconf --install
| 
| bootstrap: autoreconf
|   ./configure $(CFGFLAGS)
`

Then a simple 'make' in a fresh CVS checkout will do the right thing.

/Simon

Re: new module 'isnan-nolibm'

[Jim Meyering]

Bruno Haible <[EMAIL PROTECTED]> wrote:
> The package I announced two days ago shows that most systems have isnan()
> as a function:
>
> $ ./show-portability isnan
> libcfreebsd-5.2.1
> libcfreebsd-6.0
> libcirix-6.5
> libcmacosx-10.3

Sounds useful, but I haven't seen any announcement.
Where did you announce it?

Re: new module 'isnan-nolibm'

[Matthew Woehlke]

Jim Meyering wrote:

Bruno Haible <[EMAIL PROTECTED]> wrote:

The package I announced two days ago shows that most systems have isnan()
as a function:

$ ./show-portability isnan
libcfreebsd-5.2.1
libcfreebsd-6.0
libcirix-6.5
libcmacosx-10.3


Sounds useful, but I haven't seen any announcement.
Where did you announce it?


http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00269.html

--
Matthew
"There's nothing in the universe so permanent as a temporary government 
agency." -- Phil Geusz

Re: new module 'isnan-nolibm'

[Jim Meyering]

Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00269.html

Oh!  In _this_ list.  Thanks.
I never received that message.

I wish list-delivery-to-subscribers were more reliable.
Perhaps I should make gnus start reading via e.g., gmane.org.

Re: new module 'isnan-nolibm'

[Ben Pfaff]

Jim Meyering <[EMAIL PROTECTED]> writes:

> Perhaps I should make gnus start reading via e.g., gmane.org.

I recommend this approach.  I read many mailing lists this way,
and it works very well for me.  I'm not sure how gmane chooses
what to put in To: and CC:, but I've had no complaints so far.
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: new module 'isnan-nolibm'

[Bruno Haible]

Jim Meyering asked:
> Where did you announce it?

http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00269.html
http://article.gmane.org/gmane.comp.lib.gnulib.bugs/9267

Re: Building universal binaries makes 'check' fail

[Paul Eggert]

In 
Elias Pipping <[EMAIL PROTECTED]> writes:

> The actual problem (while these binaries work flawlessly for me)
> is that 'make check' fails (see cmd_output_tail)

Most likely the problem is that 'configure' is probing your build
architecture, and is coming up answers appropriate for that
architecture, but then you are running on a different architecture.
Given that md5sum fails, the first suspect would be WORDS_BIGENDIAN in
lib/config.h.  That is, I suspect that WORDS_BIGENDIAN should have
different values on your different architectures.

To help debug this, can you please try modifying your lib/config.h by
replacing these lines:

/* Define to 1 if your processor stores words with the most significant byte
   first (like Motorola and SPARC, unlike Intel and VAX). */
/* #undef WORDS_BIGENDIAN */

with these lines:

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel and VAX). */
#if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
#elif ! defined __LITTLE_ENDIAN__
/* #undef WORDS_BIGENDIAN */
#endif

and then do a "make clean; make"?  Then you can do a "make check" on
both architectures.

I will CC: this to bug-gnulib and bug-autoconf to give people a
heads-up on this issue.

In general the build != execute problem is a severe one with lots of
issues, but for the particular combination of Power Mac and Intel this
may be the only issue for coreutils.

Re: Building universal binaries makes 'check' fail

[Paul Eggert]

I have installed the following patch into Autoconf in an attempt to
fix the problem.  However, I have not tested this under Mac OS X, so
it'd help if someone with access to that environment could test it.

2007-02-27  Paul Eggert  <[EMAIL PROTECTED]>

* NEWS: AC_C_BIGENDIAN now supports universal binaries a la Mac OS X.
* doc/autoconf.texi (C Compiler): Document this.  There is a new
extra argument ACTION-IF-UNIVERSAL.
* lib/autoconf/c.m4 (AC_C_BIGENDIAN): Implement this.
Add support for Solaris-style _LITTLE_ENDIAN and _BIG_ENDIAN.
Reindent for sanity's sake.

Index: NEWS
===
RCS file: /cvsroot/autoconf/autoconf/NEWS,v
retrieving revision 1.424
diff -u -p -r1.424 NEWS
--- NEWS2 Feb 2007 14:11:43 -   1.424
+++ NEWS28 Feb 2007 00:03:28 -
@@ -1,5 +1,7 @@
 * Major changes in Autoconf 2.61b (-??-??)

+** AC_C_BIGENDIAN now supports universal binaries a la Mac OS X.
+
 ** Autoconf now requires GNU M4 1.4.5 or later.  Earlier versions of M4 have
a bug in macro tracing that interferes with the interaction between
Autoconf and Automake.  GNU M4 1.4.8 or later is recommended.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1132
diff -u -p -r1.1132 autoconf.texi
--- doc/autoconf.texi   8 Feb 2007 23:42:46 -   1.1132
+++ doc/autoconf.texi   28 Feb 2007 00:03:29 -
@@ -6457,7 +6457,7 @@ This macro is obsolescent, as current C 
 New programs need not use this macro.
 @end defmac

[EMAIL PROTECTED] AC_C_BIGENDIAN (@ovar{action-if-true}, 
@ovar{action-if-false}, @ovar{action-if-unknown})
[EMAIL PROTECTED] AC_C_BIGENDIAN (@ovar{action-if-true}, 
@ovar{action-if-false}, @ovar{action-if-unknown}, @ovar{action-if-universal})
 @acindex{C_BIGENDIAN}
 @cvindex WORDS_BIGENDIAN
 @cindex Endianness
@@ -6471,11 +6471,21 @@ system header files.  When cross-compili
 grep'ed for some magic values.  @var{action-if-unknown} is executed if
 the latter case fails to determine the byte sex of the host system.

+In some cases a single run of a compiler can generate code for multiple
+architectures.  This can happen, for example, when generating Mac OS X
+universal binary files, which work on both PowerPC and Intel
+architectures.  In this case, the different variants might be for
+different architectures whose endiannesses differ.  If
[EMAIL PROTECTED] detects this, it executes @var{action-if-universal}
+instead of @var{action-if-unknown}.
+
 The default for @var{action-if-true} is to define
 @samp{WORDS_BIGENDIAN}.  The default for @var{action-if-false} is to do
-nothing.  And finally, the default for @var{action-if-unknown} is to
-abort configure and tell the installer which variable he should preset
-to bypass this test.
+nothing.  The default for @var{action-if-unknown} is to
+abort configure and tell the installer how to bypass this test.
+And finally, the default for @var{action-if-universal} is to define
[EMAIL PROTECTED] or not, depending on the architecture that the
+code is being generated for.
 @end defmac

 @defmac AC_C_CONST
Index: lib/autoconf/c.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.242
diff -u -p -r1.242 c.m4
--- lib/autoconf/c.m4   7 Dec 2006 06:39:40 -   1.242
+++ lib/autoconf/c.m4   28 Feb 2007 00:03:29 -
@@ -1367,74 +1367,137 @@ fi
 ])# AC_C_CHAR_UNSIGNED


-# AC_C_BIGENDIAN ([ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-UNKNOWN])
+# AC_C_BIGENDIAN ([ACTION-IF-TRUE], [ACTION-IF-FALSE], [ACTION-IF-UNKNOWN],
+# [ACTION-IF-UNIVERSAL])
 # -
 AC_DEFUN([AC_C_BIGENDIAN],
-[AC_CACHE_CHECK(whether byte ordering is bigendian, ac_cv_c_bigendian,
-[# See if sys/param.h defines the BYTE_ORDER macro.
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include 
-#include 
-],
-[#if  ! (defined BYTE_ORDER && defined BIG_ENDIAN && defined LITTLE_ENDIAN \
-   && BYTE_ORDER && BIG_ENDIAN && LITTLE_ENDIAN)
- bogus endian macros
-#endif
-])],
-[# It does; now see whether it defined to BIG_ENDIAN or not.
-AC_COMPILE_IFELSE([AC_LANG_PROGRAM([#include 
-#include 
-], [#if BYTE_ORDER != BIG_ENDIAN
- not big endian
-#endif
-])], [ac_cv_c_bigendian=yes], [ac_cv_c_bigendian=no])],
-[# It does not; compile a test program.
-AC_RUN_IFELSE(
-[AC_LANG_PROGRAM([AC_INCLUDES_DEFAULT], [[
-  /* Are we little or big endian?  From Harbison&Steele.  */
-  union
-  {
-long int l;
-char c[sizeof (long int)];
-  } u;
-  u.l = 1;
-  return u.c[sizeof (long int) - 1] == 1;
-]])],
- [ac_cv_c_bigendian=no],
- [ac_cv_c_bigendian=yes],
-[# try to guess the endianness by grepping values into an object file
-  ac_cv_c_bigendian=unknown
-  AC_COMPILE_IFELSE([A

Re: recommended copyright stanza?

[Karl Berry]

Gary Vaughan just submitted a patch to Libtool to point to the URL for the
GPL in addition to the ability to request it by post:

Ah.  There have been several versions of this floating around, e.g.,
coreutils has another variant text. 

The last time we had this discussion was back in August 2006 (see the
archives for all the background).  We ended up thinking of proposing
this to rms (and it is what I used in hello 2.2):

  hello (GNU hello) 2.1.90
  Copyright (C) 2006 Free Software Foundation, Inc.
  License: GNU GPL v2+ 
  This is free software.  There is NO WARRANTY, to the extent permitted by law.

I still haven't written him about it, though (no particular reason, just
slothfulness).

Any comments at this point?

I think it is better not to include the physical address of the FSF.  I
think there is no need to do so, since rms has never done it for his own
programs.  As we all know, the physical address is a lot less stable
than the electronic ones.

karl

Re: recommended copyright stanza?

[Eric Blake]

Karl Berry  freefriends.org> writes:

> 
> Gary Vaughan just submitted a patch to Libtool to point to the URL for the
> GPL in addition to the ability to request it by post:
> 
> Ah.  There have been several versions of this floating around, e.g.,
> coreutils has another variant text. 
> 
> The last time we had this discussion was back in August 2006 (see the
> archives for all the background).  We ended up thinking of proposing
> this to rms (and it is what I used in hello 2.2):
> 
>   hello (GNU hello) 2.1.90

You are confusing --version output (which also could be standardized in 
maintainer.texi) with my request for the copyright comment that should be 
placed at the top of each source file.

> 
> I think it is better not to include the physical address of the FSF.  I
> think there is no need to do so, since rms has never done it for his own
> programs.  As we all know, the physical address is a lot less stable
> than the electronic ones.

The physical address of the FSF should remain in the source code comments; 
Gary's patch only added a web address in addition to the physical address.  But 
I agree that the physical address need not appear in the --version output.

-- 
Eric Blake

Re: first draft of "relocatable" module

[Ralf Wildenhues]

A couple more comments.

* Ben Pfaff wrote on Mon, Feb 26, 2007 at 03:27:42AM CET:

Content-Description: gnulib diff versus gettext
> --- gettext/build-aux/install-reloc   2006-11-09 06:26:40.0 -0800
> +++ gnulib.relocatable/build-aux/install-reloc2007-02-19 
> 22:31:39.0 -0800

> +func_verbose $compile_command -I"$builddir" -I"$srcdir" -I"$config_h_dir" 
> -DHAVE_CONFIG_H -DIN_RELOCWRAPPER -DNO_XMALLOC -D"INSTALLPREFIX=\"$prefix\"" 
> -D"INSTALLDIR=\"$installdir\"" -D"LIBPATHVAR=\"$library_path_var\"" 
> -D"LIBDIRS=$libdirs" -D"EXEEXT=\"$exeext\"" "$srcdir"/relocwrapper.c 
> "$srcdir"/progname.c "$srcdir"/progreloc.c "$srcdir"/xreadlink.c 
> "$srcdir"/readlink.c "$srcdir"/canonicalize-lgpl.c "$srcdir"/allocsa.c 
> "$srcdir"/relocatable.c "$srcdir"/setenv.c "$srcdir"/strerror.c 
> "$srcdir"/c-ctype.c -o "$destprog.wrapper$exeext" || exit $?

Do you have some data or experience on how portable it is wrt. the
compiler to list several source files in one compile command?  Can
some compiler create intermediate files in the current directory?
Because if yes, that would prevent parallel 'make install'.
Or it could leave behind object files?  Sorry, so far I wasn't able
to see easily in which directory this compilation command would be
executed.

I tried some compilers now.  All those I tried coped well with multiple
source files listed.  But just as well, none except GCC are intelligent
enough by themselves to not stomp upon each others' object files, and
most do not clean up.

compiler creates objects in pwd   leaves behind objects
AIX 4.3.3 xlcyes  no
AIX 5.3 xlc  yes  no
HP-UX 10.20 cc   yes  yes
HP-UX 11.23/IA ccyes  yes
IRIX 6.5 cc  yes  yes
Solaris 2.6 cc   yes  yes
Solaris 10 ccyes  yes
Tru64 4.0D ccyes  yes
Tru64 5.1 cc yes  yes
GCC  no   no

Cheers,
Ralf

Re: first draft of "relocatable" module

[Ralf Wildenhues]

* Ben Pfaff wrote on Mon, Feb 26, 2007 at 05:56:54AM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * Ben Pfaff wrote on Mon, Feb 26, 2007 at 05:41:15AM CET:
> >> 
> >> The issue is foo_CFLAGS and foo_LDFLAGS need to refer back to the
> >> directory in which foo is installed.  Thus, if foo is in
> >> bin_PROGRAMS then the following is correct:
> >> 
> >>   foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\"

FWIW, foo_CPPFLAGS would be more appropriate for -D.

[...]
> >> but if foo is in libexecdir_PROGRAMS then the following is needed
> >> instead:
> >
> > Ah, ok, thanks for the explanation.  Yes, this may be best solved from
> > within Automake.  Not sure if I have a chance to look at it soon though.
> 
> Do you have a suggestion for a reasonable syntax to request it?
> I am willing to do some implementation work.

Hmm, at first sight, not really.  It would be helpful if this request
could even be formulated coherently from an Automake POV.  I think it's
a bummer if the per-target *_CPPFLAGS are always used and thus cause the
need for individual rules for each object file, bloating the resulting
Makefile.  Most packages put all their PROGRAMS in bindir only, so in
that case just one global flag would suffice.

Anyway sending a mail to the Automake list even as a reminder about this
is a good idea.

Cheers,
Ralf

Re: Building universal binaries makes 'check' fail

[Paolo Bonzini]

+[[#if ! (defined __BIG_ENDIAN__ || defined __LITLE_ENDIAN__)


typo