Re: [bug-gnulib] Re: FYI, utimens was missing a dependency on timespec

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bruno Haible on 2/28/2007 4:37 PM:
> The two modules 'utimens' and 'utimecmp' still fail to build even on glibc
> systems, according to http://autobuild.josefsson.org/gnulib/.
> 
> Here's a proposed fix:
> 
> 
> 2007-02-28  Bruno Haible  <[EMAIL PROTECTED]>
> 
>   * m4/utimecmp.m4 (gl_UTIMECMP): Don't require gl_TIMESPEC.
>   * m4/utimens.m4 (gl_UTIMENS): Likewise.

Thanks for catching that.  It is correct, so I installed it on your behalf.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF5tJ/84KuGfSFAYARAhtxAJ4sGcuzYiAfsnrcrZyvrwtORT15qACdGAvo
xgeo6MFk9vu0OdUN+qZDB3Q=
=VMli
-END PGP SIGNATURE-

Re: GNU M4 1.4.8b released (beta release)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Matthew Woehlke on 2/28/2007 5:46 PM:
> Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
> long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
> thing, just because 'long long' exists. 16 errors trying to build printf.c.

That's because printf.c is part of gnulib, and both coreutils and m4 use
the same source file.  Whatever you do to fix it for one package will fix
it for the other; and as Bruno suggested, if compiling with CFLAGS=-O
fixes it (by detecting the brokenness of your compiler's long long), then
it probably is not worth much further effort in gnulib to work around it.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF5tY984KuGfSFAYARAid+AJ9KWfYg0MNa+trOyMkeQPAaCsSKjwCfT+hm
oe9h1dnzcb+ici5iyhZE7X8=
=LlvH
-END PGP SIGNATURE-

Re: link-warning a build-aux file?

[Simon Josefsson]

FYI, I solved this problem by letting gnulib put GNUmakefile and
maint.mk into build-aux/, and use this top-level GNUmakefile:

have-gnulib-files := $(shell test -f gnulib.mk && test -f maint.mk && echo yes)
ifneq ($(have-gnulib-files),yes)
gnulib.mk:
ln -s build-aux/GNUmakefile gnulib.mk || cp build-aux/GNUmakefile 
gnulib.mk
ln -s build-aux/maint.mk maint.mk || cp build-aux/maint.mk maint.mk
endif

-include gnulib.mk

If this approach works out well, it should go into the manual, because
without it, the maintainer-makefile module seems useless for projects
that use AC_CONFIG_AUX_DIR.

/Simon

Re: link-warning a build-aux file?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Simon Josefsson on 3/1/2007 6:35 AM:
> FYI, I solved this problem by letting gnulib put GNUmakefile and
> maint.mk into build-aux/, and use this top-level GNUmakefile:
> 
> have-gnulib-files := $(shell test -f gnulib.mk && test -f maint.mk && echo 
> yes)
> ifneq ($(have-gnulib-files),yes)
> gnulib.mk:
>   ln -s build-aux/GNUmakefile gnulib.mk || cp build-aux/GNUmakefile 
> gnulib.mk
>   ln -s build-aux/maint.mk maint.mk || cp build-aux/maint.mk maint.mk
> endif
> 
> -include gnulib.mk

Looks nice to me; I've been meaning to get maintainer-makefile imported
into M4, and this seems like a feasible way to do it.

> 
> If this approach works out well, it should go into the manual, because
> without it, the maintainer-makefile module seems useless for projects
> that use AC_CONFIG_AUX_DIR.

My other concern is how to make GNUMakefile play nicely with VPATH builds.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF5tjR84KuGfSFAYARAv3SAKDHhj7fFWSnMXAComRFkQ4QkSGHLwCfYXkn
041j45EbzUyo8Rkc4tMT83U=
=TGZC
-END PGP SIGNATURE-

Re: first draft of "relocatable" module

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> For reference, here are the changes that I did, compared to your patch.

Looks good.  

> There is still one problem: The comment at the head of gl_RELOCATABLE
> says that it accepts an argument. But the macro uses always $gl_source_base,
> not $1.

Oops.  I'll follow up later with a fix for this and for
compatibility problems pointed out by others.
-- 
"Implementation details are beyond the scope of the Java virtual
 machine specification.  One should not assume that every virtual
 machine implementation contains a giant squid."
--"Mr. Bunny's Big Cup o' Java"

Re: GNU M4 1.4.8b released (beta release)

[Matthew Woehlke]

Eric Blake wrote:

According to Matthew Woehlke on 2/28/2007 5:46 PM:

Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
thing, just because 'long long' exists. 16 errors trying to build printf.c.


That's because printf.c is part of gnulib, and both coreutils and m4 use
the same source file.  Whatever you do to fix it for one package will fix
it for the other; and as Bruno suggested, if compiling with CFLAGS=-O
fixes it (by detecting the brokenness of your compiler's long long), then
it probably is not worth much further effort in gnulib to work around it.


Well... aside from the fact that I forgot that (it's been quite a 
while), I still think that if printf.c is going to *assume* unsigned if 
long long exists, then config.h really ought to make this safe, say by 
having something like this in config.h.in:


#if defined(HAVE_LONG_LONG_INT) && !defined(HAVE_UNSIGNED_LONG_LONG_INT)
# undef HAVE_LONG_LONG_INT
#endif

...or at least in printf.c! This way things would work without having to 
"know" to specify special build flags.


--
Matthew
Ngx iqct zgg dxei zodt gf ngxk iqfrl.

Re: GNU M4 1.4.8b released (beta release)

[Matthew Woehlke]

Matthew Woehlke wrote:

Eric Blake wrote:

According to Matthew Woehlke on 2/28/2007 5:46 PM:

Sigh. Now you're picking up coreutils' problem, trying to use 'unsigned
long long' on a platform (Tandem NSK/OSS) that "doesn't" have such a
thing, just because 'long long' exists. 16 errors trying to build 
printf.c.


That's because printf.c is part of gnulib, and both coreutils and m4 use
the same source file.  Whatever you do to fix it for one package will fix
it for the other; and as Bruno suggested, if compiling with CFLAGS=-O
fixes it (by detecting the brokenness of your compiler's long long), then
it probably is not worth much further effort in gnulib to work around it.


Well... aside from the fact that I forgot that [snip]


...it also seems to break tempname.c:

source='tempname.c' object='tempname.o' libtool=no \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
cc  -I. -O -c tempname.c
  int64_t st_reserved[3];
  ^
"///usr/include/sys/stat.h", line 70: error(114): identifier "int64_t"
  is undefined


  struct  stat {
  ^
"///usr/include/sys/stat.h", line 48: warning(664): padding is required
  at the end of this struct for correct layout


len = strlen (tmpl);
  ^
"/home/tandem_oss/floss/src/m4-1.4.8b/lib/tempname.c", line 228:
  warning(1506): implicit conversion from "unsigned int" to
  "int": rounding, sign extension, or loss of accuracy may
  result


  if (__lxstat64 (_STAT_VER, tmpl, &st) < 0)
  ^
"/home/tandem_oss/floss/src/m4-1.4.8b/lib/tempname.c", line 286:
  warning(304): function "lstat" declared implicitly


1 error detected in the compilation of "tempname.c".
c89: /usr/lib/cfe exited, returning 2.
make[2]: *** [tempname.o] Error 1


No, wait. It breaks the system headers (which, if memory serves, I 
predicted would happen). So pretending long long does not exist is not 
an option.


--
Matthew
Ngx iqct zgg dxei zodt gf ngxk iqfrl.

Re: time_r.h -> time_.h

[Paul Eggert]

Bruno Haible <[EMAIL PROTECTED]> writes:

> Therefore I propose to remove this paragraph:
>
> -You should include Gnulib-provided headers before system headers,
> -so that Gnulib-provided headers can adjust how a system header
> -behaves.

That sounds good; thanks.

> The timegm.m4 did check whether timegm was declared. Was it because some
> platforms defined the function but did not declare it? Or the opposite?

The former.

> I'm asking because in the first case, the new timegm.m4 and  provides
> a replacement to the function although it already exists in libc.

That's OK.  The code will still work.  I am a bit leery of calling
undeclared functions when there's a suitable portable alternative,
which there is here.

It may be in other situations that it's important to call an
undeclared function, but my impression is that that sort of situation
is becoming less and less plausible as time goes on.

> gl_TIME_R should AC_REQUIRE([gl_HEADER_TIME_H_DEFAULTS]) to exclude the
> possibility that REPLACE_LOCALTIME_R gets set to 0 after it has already
> been set to 1 inside gl_TIME_R.
>
> Likewise for gl_FUNC_NANOSLEEP, gl_FUNC_STRPTIME, gl_FUNC_TIMEGM.

Thanks.

> strptime now requires the 'extensions' module, although it didn't before.
> Is this intentional?

Yes, because strptime isn't in ANSI C, nor is it in base POSIX, so its
declaration is excluded in some pedantic environments.

Also strptime's behavior might change if you're defining extensions.
On Solaris 10, for example, you get a different strptime if extensions
are used, and even if you are compiling pedantically you probably want
this since it's the strptime that is normally used and is
better-tested.

> time_.h: "overrrun" -> "overrun"

Thanks.

> Hmm. If used GNULIB_PORTCHECK, the user will get link errors about
> eschew_asctime but about rpl_nanosleep? Not consistent.

The difference here is that eschew_* functions should never be used,
and there is no replacement for them in gnulib.  For example, portable
code should never use asctime, not even glibc asctime, since it
mishandles some rare cases.

If we ever find a bug-free asctime in the field, or an unportable but
safe usage of asctime in gnulib-using code, then we can revisit this
decision.  I haven't encountered any yet, though.

I installed this:

2007-03-01  Paul Eggert  <[EMAIL PROTECTED]>

Followup to the 2007-02-12 patch, using suggestions from Bruno Haible in
.
* doc/gnulib-tool.texi (Initial import): Mention _FILE_OFFSET_BITS
as another example.
* lib/time_.h: Fix misspelling.
* m4/nanosleep.m4 (gl_FUNC_NANOSLEEP):
Require gl_HEADER_TIME_H_DEFAULTS.
* m4/strptime.m4 (gl_FUNC_STRPTIME): Likewise.
* m4/time_r.m4 (gl_TIME_R): Likewise.
* m4/timegm.m4 (gl_FUNC_TIMEGM): Likewise.

Index: doc/gnulib-tool.texi
===
RCS file: /cvsroot/gnulib/gnulib/doc/gnulib-tool.texi,v
retrieving revision 1.10
diff -u -p -r1.10 gnulib-tool.texi
--- doc/gnulib-tool.texi24 Feb 2007 01:13:52 -  1.10
+++ doc/gnulib-tool.texi1 Mar 2007 21:24:52 -
@@ -232,8 +232,9 @@ use of @code{strdup}.
 In the usual case where Autoconf is creating a @file{config.h} file,
 you should include @file{config.h} first, before any other include
 file.  That way, for example, if @file{config.h} defines
[EMAIL PROTECTED] to be the empty string on a pre-C99 host, the
-definition is consistent for all include files.
[EMAIL PROTECTED] to be the empty string on a pre-C99 host, or a macro
+like @samp{_FILE_OFFSET_BITS} that affects the layout of data
+structures, the definition is consistent for all include files.

 You should include Gnulib-provided headers before system headers,
 so that Gnulib-provided headers can adjust how a system header
Index: lib/time_.h
===
RCS file: /cvsroot/gnulib/gnulib/lib/time_.h,v
retrieving revision 1.1
diff -u -p -r1.1 time_.h
--- lib/time_.h 12 Feb 2007 18:49:19 -  1.1
+++ lib/time_.h 1 Mar 2007 21:24:52 -
@@ -86,7 +86,7 @@ char *strptime (char const *restrict __b
 time_t timegm (struct tm *__tm);
 #endif

-/* Encourage applications to avoid unsafe functions that can overrrun
+/* Encourage applications to avoid unsafe functions that can overrun
buffers when given outlandish struct tm values.  Portable
applications should use strftime (or even sprintf) instead.  */
 # if GNULIB_PORTCHECK
Index: m4/nanosleep.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/nanosleep.m4,v
retrieving revision 1.29
diff -u -p -r1.29 nanosleep.m4
--- m4/nanosleep.m4 24 Feb 2007 10:01:49 -  1.29
+++ m4/nanosleep.m4 1 Mar 2007 21:24:52 -
@@ -1,4 +1,4 @@
-#serial 21
+#serial 22

 dnl From Jim Meyering.
 dnl Check for the nanosleep function.

ls vs. Solaris 10: all files get "+" alternate access method flag

[Jim Meyering]

Yesterday, Nelson Beebe tested coreutils-6.8+.

I replied:
> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
> ...
> > I have a question, however.  Since 6.8 got installed, I've been
> > seeing a + at the end of the permission field, e.g., on abajo:
> >
> > % ls -l /usr/local/share/man/man3cw/urcw4.3cw
> > -rw-rw-r--+ 1 beebe wheel 1638 2007-02-26 22:57
> > /usr/local/share/man/man3cw/urcw4.3cw
> >
> > This is not documented in the man page for ls, but a search
>
> Remember that coreutils man pages are usually little more than
> massaged --help output.  In the real documenatation (info coreutils),
> this is documented:
>
>  Following the permission bits is a single character that specifies
>  whether an alternate access method applies to the file.  When that
>  character is a space, there is no alternate access method.  When it
>  is a printing character (e.g., `+'), then there is such a method.
>
> > of the source code shows that the + is attached when there
> > is an ACL.  The thing is, there should be no ACLs on these
> > files.  Here is what the ACL utility reports:
> >
> > % getfacl /usr/local/share/man/man3cw/urcw4.3cw
> > getfacl: Removing leading '/' from absolute path names
> > # file: usr/local/share/man/man3cw/urcw4.3cw
> > # owner: beebe
> > # group: wheel
> > user::rw-
> > group::rw-
> > mask::rwx
> > other::r--
>
> I'm glad you noticed that.  It is a bug.
> What's changed is that now Solaris includes the "mask:" field.
> Coreutils calls acl_get_file, then acl_entries
> to count the entries.  It used the heuristic that
> more than 3 entries indicates an ACL.
> Now there are always 4, even on files without an ACL.
>
> I hope there's an efficient way to implement has_acl, now.
> We'll see.
>
> I see that Solaris provides the acl_trivial function, with a
> const-incorrect prototype (it should be a "char const *" parameter).
>
> SYNOPSIS
>cc [ flag... ] file... -lsec [ library... ]
>#include 
>
>int acl_trivial(char *path);
>
> DESCRIPTION
>The  acl_trivial()  function  is used to determine whether a file
>has a trivial ACL. Whether an ACL is trivial depends on the  type
>of  the  ACL. A POSIX draft ACL is trivial if it has greater than
>MIN_ACL_ENTRIES. An NFSv4/ZFS-style ACL is trivial if  it  either
>has entries other than owner@, group@, and everyone@, has inheri-
>tance flags set, or is not ordered in a manner that  meets  POSIX
>access control requirements.
>
> But that won't help non-Solaris systems that mount a ZFS file system.
>
> My first reflex was to just use MIN_ACL_ENTRIES in place of "3"
> here, in lib/acl.c:
>
> ret = (3 < acl_entries (acl));
>
> But it can't work.  On a non-Solaris system like abajo,
> the number to compare against is 3 on e.g., local ext3 file systems
> but 4 on remote-mounted ZFS file systems.
>
> > The other peculiar thing is that when I do a "make install"
> > to install the man pages from abajo, I get reports like this:
> >
> > cp: setting permissions for `/usr/local/man/cat3cw/ldexp.3cw': Invalid
> > argument
> >
> > This too seems to be new with coreutils-6.8.
>
> This is due to the same underlying problem.
> strace shows that the failing syscall is fsetxattr, with EINVAL.
> cp thinks there's an ACL and is trying to preserve it.

Here's a possible solution:

If the presence of the "mask:" entry is a reliable indicator
that MIN_ACL_ENTRIES is 4, then we could implement something
whereby for one file per distinct file system (st_dev value)
we'd examine ACL entries looking for a "mask:" one, and maintain
a table mapping st_dev value to the MIN_ACL_ENTRIES value for
that file system.

Call it pre-optimization, but somehow, I think performing all of
those ACL-related syscalls and string compares for each and every file
processed would be too much of a performance hit.

Re: time_r.h -> time_.h

[Bruno Haible]

Paul Eggert wrote:
> > Therefore I propose to remove this paragraph:
> >
> > -You should include Gnulib-provided headers before system headers,
> > -so that Gnulib-provided headers can adjust how a system header
> > -behaves.
> 
> That sounds good; thanks.

OK, I removed it and expanded a bit more on the previous paragraph's topic:

*** doc/gnulib-tool.texi1 Mar 2007 21:24:55 -   1.11
--- doc/gnulib-tool.texi2 Mar 2007 01:14:46 -
***
*** 235,244 
  @samp{restrict} to be the empty string on a pre-C99 host, or a macro
  like @samp{_FILE_OFFSET_BITS} that affects the layout of data
  structures, the definition is consistent for all include files.
! 
! You should include Gnulib-provided headers before system headers,
! so that Gnulib-provided headers can adjust how a system header
! behaves.
  
  A final word of warning: Gnulib currently assumes it will be
  responsible for @emph{all} functions that end up in the Autoconf
--- 235,244 
  @samp{restrict} to be the empty string on a pre-C99 host, or a macro
  like @samp{_FILE_OFFSET_BITS} that affects the layout of data
  structures, the definition is consistent for all include files.
! Another reason why @file{config.h} must be included before any other
! include file is that it may define macros like @samp{_GNU_SOURCE}
! or @samp{_FILE_OFFSET_BITS} which, on glibc systems, have an effect only
! if defined before the first system header file is included.
  
  A final word of warning: Gnulib currently assumes it will be
  responsible for @emph{all} functions that end up in the Autoconf

Re: first draft of "relocatable" module

[Bruno Haible]

Ralf Wildenhues wrote:
> > Indeed, it would have to be documented in the user's documentation that
> > the relocatable module doesn't work on OpenBSD when shared libraries are
> > involved.
> 
> Well.  On systems where Libtool hardcodes an absolute soname.  1.5.22
> does it, and 1.5.24 will do it, but 2.0 will not do it any more on
> OpenBSD.

OK, I'm documenting it like this:

--- doc/relocatable.texi1 Mar 2007 02:07:56 -   1.1
+++ doc/relocatable.texi2 Mar 2007 01:24:51 -
@@ -33,7 +33,9 @@
 
 Installation with @option{--enable-relocatable} will not work for
 setuid or setgid executables, because such executables search only
-system library paths for security reasons.
+system library paths for security reasons.  Also, installation with
[EMAIL PROTECTED] might not work not OpenBSD, when the
+package contains shared libraries and libtool versions 1.5.xx are used.
 
 The runtime penalty and size penalty are negligible on GNU/Linux (just
 one system call more when an executable is launched), and small on


> But there are some ancient or rarer systems where it will
> still happen.

These systems (Unixware etc.) are not worth mentioning today.

> >   for example, --prefix=/tmp/inst$$.
> 
> This bit doesn't.  Since /tmp is usually world-writable, you've got your
> attack vector already.

/tmp is world-writable but a directory created by a user in /tmp is not
world-writable (assuming an umask of at least 002). Therefore I don't see
a security problem here.

Bruno

relocatable: break lines in install-reloc

[Bruno Haible]

install-reloc has a few long lines. I'm breaking them so it's easier to
understand.

2007-03-01  Bruno Haible  <[EMAIL PROTECTED]>

* build-aux/install-reloc: Break long lines.

*** build-aux/install-reloc 1 Mar 2007 02:14:04 -   1.2
--- build-aux/install-reloc 2 Mar 2007 01:37:25 -
***
*** 1,6 
  #!/bin/sh
  # install-reloc - install a program including a relocating wrapper
! # Copyright (C) 2003, 2005-2006 Free Software Foundation, Inc.
  # Written by Bruno Haible <[EMAIL PROTECTED]>, 2003.
  #
  # This program is free software; you can redistribute it and/or modify
--- 1,6 
  #!/bin/sh
  # install-reloc - install a program including a relocating wrapper
! # Copyright (C) 2003, 2005-2007 Free Software Foundation, Inc.
  # Written by Bruno Haible <[EMAIL PROTECTED]>, 2003.
  #
  # This program is free software; you can redistribute it and/or modify
***
*** 18,24 
  # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  
  # Usage:
! #   install-reloc library_path_var library_path_value prefix compile_command 
srcdir config_h_dir exeext install_command... destprog
  # where
  #   - library_path_var is the platform dependent runtime library path variable
  #   - library_path_value is a colon separated list of directories that contain
--- 18,26 
  # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
  
  # Usage:
! #   install-reloc library_path_var library_path_value prefix \
! # compile_command srcdir config_h_dir exeext \
! # install_command... destprog
  # where
  #   - library_path_var is the platform dependent runtime library path variable
  #   - library_path_value is a colon separated list of directories that contain
***
*** 70,76 
  shift
  shift
else
! echo "Usage: $0 library_path_var library_path_value prefix 
compile_command srcdir builddir config_h_dir exeext install_command... 
destprog" 1>&2
  exit 1
fi
  fi
--- 72,80 
  shift
  shift
else
! echo "Usage: $0 library_path_var library_path_value prefix" \
!  "compile_command srcdir builddir config_h_dir exeext" \
!  "install_command... destprog" 1>&2
  exit 1
fi
  fi
***
*** 119,129 
  
  # Compile wrapper.
  installdir=`echo "$destprog" | sed -e 's,/[^/]*$,,'`
! 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 $?
  
  # Rename $destprog.wrapper -> $destprog -> $destprog.bin.
  ln -f "$destprog$exeext" "$destprog.bin$exeext" \
!   || { rm -f "$destprog.bin$exeext" && cp -p "$destprog$exeext" 
"$destprog.bin$exeext"; } \
|| exit 1
  mv "$destprog.wrapper$exeext" "$destprog$exeext" || exit 1
  
--- 123,152 
  
  # Compile wrapper.
  installdir=`echo "$destprog" | sed -e 's,/[^/]*$,,'`
! 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 $?
  
  # Rename $destprog.wrapper -> $destprog -> $destprog.bin.
  ln -f "$destprog$exeext" "$destprog.bin$exeext" \
!   || { rm -f "$destprog.bin$exeext" \
!&& cp -p "$destprog$exeext" "$destprog.bin$exeext"; } \
|| exit 1
  mv "$destprog.wrapper$exeext" "$destprog$exeext" || exit 1
  

Re: GNU M4 1.4.8b released (beta release)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Matthew Woehlke on 3/1/2007 9:16 AM:
> Well... aside from the fact that I forgot that (it's been quite a
> while), I still think that if printf.c is going to *assume* unsigned if
> long long exists, then config.h really ought to make this safe, say by
> having something like this in config.h.in:
> 
> #if defined(HAVE_LONG_LONG_INT) && !defined(HAVE_UNSIGNED_LONG_LONG_INT)
> # undef HAVE_LONG_LONG_INT
> #endif

Are HAVE_LONG_LONG_INT and HAVE_UNSIGNED_LONG_LONG_INT both defined
correctly in config.h in your case that we could do that?  Do things work
for you if you manually append those three lines to the end of your config.h?

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF54Iy84KuGfSFAYARAiHeAJsHOYXTdBhJToT5Baktr0G7O2f0TACfVgEi
J2wIpE7P5X3XKv8Vy8NwaQQ=
=wq8s
-END PGP SIGNATURE-

Re: GNU M4 1.4.8b released (beta release)

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Matthew Woehlke on 3/1/2007 9:44 AM:
> 
> ...it also seems to break tempname.c:
> 
> source='tempname.c' object='tempname.o' libtool=no \
> DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> cc  -I. -O -c tempname.c
>   int64_t st_reserved[3];
>   ^
> "///usr/include/sys/stat.h", line 70: error(114): identifier "int64_t"
>   is undefined

That makes it sound like we might be able to get away with a fix stdint_.h
to include sys/stat.h prior to redefining all the 64-bit type names, along
with any other system header that uses int64_t on your platform.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF54KO84KuGfSFAYARAganAKCwLxWlzDl3+PuCVt6VHJGGmKWZtgCaA4NB
osvyHFPeO0Dxn25Ea3Qm7TU=
=jpBz
-END PGP SIGNATURE-

Re: first draft of "relocatable" module

[Bruno Haible]

Ralf Wildenhues wrote:
> 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

Thanks for the investigations. To cope with the right column, I'm applying
this. To cope with the middle column, it should be sufficient if the user
does not attempt to use parallel make, right?

Bruno


2007-03-01  Bruno Haible  <[EMAIL PROTECTED]>

* build-aux/install-reloc: Remove object files left over by some
compilers.
Reported by Ralf Wildenhues.

*** build-aux/install-reloc 2 Mar 2007 01:40:17 -   1.3
--- build-aux/install-reloc 2 Mar 2007 01:45:09 -
***
*** 140,147 
   "$srcdir"/setenv.c \
   "$srcdir"/strerror.c \
   "$srcdir"/c-ctype.c \
!  -o "$destprog.wrapper$exeext" \
!   || exit $?
  
  # Rename $destprog.wrapper -> $destprog -> $destprog.bin.
  ln -f "$destprog$exeext" "$destprog.bin$exeext" \
--- 140,160 
   "$srcdir"/setenv.c \
   "$srcdir"/strerror.c \
   "$srcdir"/c-ctype.c \
!  -o "$destprog.wrapper$exeext"
! rc=$?
! # Clean up object files left over in the current directory by the native C
! # compilers on Solaris, HP-UX, OSF/1, IRIX.
! rm -f relocwrapper.o \
!   progname.o \
!   progreloc.o \
!   xreadlink.o \
!   canonicalize-lgpl.o \
!   allocsa.o \
!   relocatable.o \
!   setenv.o \
!   strerror.o \
!   c-ctype.o
! test $rc = 0 || exit $?
  
  # Rename $destprog.wrapper -> $destprog -> $destprog.bin.
  ln -f "$destprog$exeext" "$destprog.bin$exeext" \

Re: first draft of "relocatable" module

[Bruno Haible]

Ralf Wildenhues wrote:
> > >> 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.

Yes, right. That's also how it's used in gettext. I'm applying this:


2007-03-01  Bruno Haible  <[EMAIL PROTECTED]>

* doc/relocatable-maint.texi: Recommend to set foo_CPPFLAGS, not
foo_CFLAGS.
Reported by Ralf Wildenhues.

--- doc/relocatable-maint.texi  1 Mar 2007 02:08:18 -   1.1
+++ doc/relocatable-maint.texi  2 Mar 2007 01:52:38 -
@@ -116,7 +116,7 @@
 installed in, say, @file{$(bindir)}, you add:
 
 @example
-foo_CFLAGS = -DINSTALLDIR=\"$(bindir)\"
+foo_CPPFLAGS = -DINSTALLDIR=\"$(bindir)\"
 if RELOCATABLE_VIA_LD
 foo_LDFLAGS = `$(RELOCATABLE_LDFLAGS) $(bindir)`
 endif

Re: GNU M4 1.4.8b released (beta release)

[Bruno Haible]

Eric Blake wrote:
> According to Matthew Woehlke on 3/1/2007 9:44 AM:
> >
> > ...it also seems to break tempname.c:
> >
> > source='tempname.c' object='tempname.o' libtool=no \
> > DEPDIR=.deps depmode=none /bin/sh ../depcomp \
> > cc  -I. -O -c tempname.c
> >   int64_t st_reserved[3];
> >   ^
> > "///usr/include/sys/stat.h", line 70: error(114): identifier "int64_t"
> >   is undefined
> 
> That makes it sound like we might be able to get away with a fix stdint_.h
> to include sys/stat.h prior to redefining all the 64-bit type names, along
> with any other system header that uses int64_t on your platform.

Another option would be to leave int64_t defined as it is, but set HAVE_INT64_T
to 0, to indicate that gnulib shouldn't use it.

But first, Matthew Woehlke should show enough info for analysis of possible
workarounds:
  - the relevant parts of sys/stat.h including all surrounding #ifs,
  - what is the original definition of int64_t on this OS if gnulib is not
involved? (a macro, a typedef?)
Just copy&pasting a compiler's error message is not useful enough.

Bruno

Re: first draft of "relocatable" module

[Bruno Haible]

Albert Chin wrote:
> > +  hpux9* | hpux10* | hpux11*)
> > +shlibpath_var=SHLIB_PATH
> > +;;
> 
> HP-UX/IA is ELF so you should really use LD_LIBRARY_PATH.

Oh, right. config.libpath was last updated for libtool 1.5.2. I'm updating it
for libtool-1.5.22:

2007-03-01  Bruno Haible  <[EMAIL PROTECTED]>

* build-aux/config.libpath: Update to libtool-1.5.22.
Reported by Albert Chin <[EMAIL PROTECTED]>.

*** build-aux/config.libpath1 Mar 2007 01:15:40 -   1.1
--- build-aux/config.libpath2 Mar 2007 02:15:54 -
***
*** 54,60 
beos*)
  shlibpath_var=LIBRARY_PATH
  ;;
!   bsdi4*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
cygwin* | mingw* | pw32*)
--- 54,60 
beos*)
  shlibpath_var=LIBRARY_PATH
  ;;
!   bsdi[45]*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
cygwin* | mingw* | pw32*)
***
*** 64,82 
darwin* | rhapsody*)
  shlibpath_var=DYLD_LIBRARY_PATH
  ;;
!   freebsd1*)
  ;;
kfreebsd*-gnu)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
!   freebsd*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
gnu*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
hpux9* | hpux10* | hpux11*)
! shlibpath_var=SHLIB_PATH
  ;;
irix5* | irix6* | nonstopux*)
  case $host_os in
--- 64,91 
darwin* | rhapsody*)
  shlibpath_var=DYLD_LIBRARY_PATH
  ;;
!   dgux*)
! shlibpath_var=LD_LIBRARY_PATH
  ;;
kfreebsd*-gnu)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
!   freebsd1*)
! ;;
!   freebsd* | dragonfly*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
gnu*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
hpux9* | hpux10* | hpux11*)
! case "$host_cpu" in
!   ia64* | hppa*64*) shlibpath_var=LD_LIBRARY_PATH ;;
!   *) shlibpath_var=SHLIB_PATH ;;
! esac
! ;;
!   interix3*)
! shlibpath_var=LD_LIBRARY_PATH
  ;;
irix5* | irix6* | nonstopux*)
  case $host_os in
***
*** 94,100 
  esac
  shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
  ;;
!   linux-gnu*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
knetbsd*-gnu)
--- 103,111 
  esac
  shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
  ;;
!   linux*oldld* | linux*aout* | linux*coff*)
! ;;
!   linux*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
knetbsd*-gnu)
***
*** 106,111 
--- 117,125 
newsos6)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
+   nto-qnx*)
+ shlibpath_var=LD_LIBRARY_PATH
+ ;;
openbsd*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
***
*** 115,136 
osf3* | osf4* | osf5*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
-   sco3.2v5*)
- shlibpath_var=LD_LIBRARY_PATH
- ;;
solaris*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
sunos4*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
!   sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
! shlibpath_var=LD_LIBRARY_PATH
! ;;
!   uts4*)
! shlibpath_var=LD_LIBRARY_PATH
! ;;
!   dgux*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
sysv4*MP*)
--- 129,141 
osf3* | osf4* | osf5*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
solaris*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
sunos4*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
!   sysv4 | sysv4.3*)
  shlibpath_var=LD_LIBRARY_PATH
  ;;
sysv4*MP*)
***
*** 138,143 
--- 143,154 
shlibpath_var=LD_LIBRARY_PATH
  fi
  ;;
+   sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ shlibpath_var=LD_LIBRARY_PATH
+ ;;
+   uts4*)
+ shlibpath_var=LD_LIBRARY_PATH
+ ;;
  esac
  
  LC_ALL=C sed -e 's/^\([a-zA-Z0-9_]*\)=/acl_cv_\1=/' <

Re: first draft of "relocatable" module

[Bruno Haible]

Albert Chin wrote:
> And, if $compile_command can be libtool, you'll definitely run into
> problems, especially on AIX with -export-dynamic.

This is a non-issue: $compile_command comes from $RELOC_COMPILE_COMMAND, which
is set (in m4/relocatable.m4) to "$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" -
this does not contain $(LIBTOOL).

Bruno

Re: first draft of "relocatable" module

[Ben Pfaff]

Bruno Haible <[EMAIL PROTECTED]> writes:

> -system library paths for security reasons.
> +system library paths for security reasons.  Also, installation with
> [EMAIL PROTECTED] might not work not OpenBSD, when the
> +package contains shared libraries and libtool versions 1.5.xx are used.

Typo: "might not work not" => "might not work on"
-- 
Ben Pfaff 
[EMAIL PROTECTED]
http://benpfaff.org

Re: first draft of "relocatable" module

[Ralf Wildenhues]

Hello Bruno,

* Bruno Haible wrote on Fri, Mar 02, 2007 at 02:30:07AM CET:
> Ralf Wildenhues wrote:
> 
> > >   for example, --prefix=/tmp/inst$$.
> > 
> > This bit doesn't.  Since /tmp is usually world-writable, you've got your
> > attack vector already.
> 
> /tmp is world-writable but a directory created by a user in /tmp is not
> world-writable (assuming an umask of at least 002). Therefore I don't see
> a security problem here.

On several systems that I know, /tmp is cleaned at system startup, or
old files are removed at regular intervals.  So after you've installed
your stuff, at some point /tmp/inst$$ is removed again (possibly even by
you).  At that time, I can write to /tmp/inst$$.  I can usually even
look at your binaries (in the final location) first to find out about
the value of $$ that was used by you at 'make install' time.

That's a trivial attack on the systems where run path overrides the
shared library path variable.

Cheers,
Ralf

Re: first draft of "relocatable" module

[Ralf Wildenhues]

* Bruno Haible wrote on Fri, Mar 02, 2007 at 02:48:10AM CET:
> Ralf Wildenhues wrote:
> > 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
[...]
> Thanks for the investigations. To cope with the right column, I'm applying
> this. To cope with the middle column, it should be sufficient if the user
> does not attempt to use parallel make, right?

Almost right.  To cope with *both* the middle and the right column,
parallel make is forbidden.  So it'll work only with GCC.  Or you
could work in a temporary directory.

Your patch also forbids parallel 'make install' with GCC in case objects
with the same names as the one you remove are created as part of the
regular build, and in case the objects are created in the build tree,
which I still don't know.

Cheers,
Ralf

> 2007-03-01  Bruno Haible  <[EMAIL PROTECTED]>
> 
>   * build-aux/install-reloc: Remove object files left over by some
>   compilers.
>   Reported by Ralf Wildenhues.
[...]
> ! # Clean up object files left over in the current directory by the native C
> ! # compilers on Solaris, HP-UX, OSF/1, IRIX.
> ! rm -f relocwrapper.o \
> !   progname.o \
> !   progreloc.o \
> !   xreadlink.o \
> !   canonicalize-lgpl.o \
> !   allocsa.o \
> !   relocatable.o \
> !   setenv.o \
> !   strerror.o \
> !   c-ctype.o