Jim Meyering <[EMAIL PROTECTED]> wrote:
> Yesterday, Nelson Beebe tested coreutils-6.8+.
>
> I replied:
>> "Nelson H. F. Beebe" <[EMAIL PROTECTED]> wrote:
>> ...
...
>> > The other peculiar thing is that when I do a "make install"
>> > to install the man pages from abajo, I get reports like this:
The module description and macros of relocatable-prog still has a problem:
It compiles relocatable.c both as part of lib_SOURCES and as an AC_LIBOBJ.
This leads to a link error when creating a shared library. This fixes it.
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
Compile relocatable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 3/4/2007 7:57 AM:
>
> Here's the current matrix:
>
>1 = checking whether printf supports size specifiers as in C99...
>2 = checking whether printf supports the 'a' and 'A' directives...
>3 = checking whether p
Bruno Haible wrote:
> Volunteers wanted: If you have access to a system with
> - FreeBSD 5.x
Results for FreeBSD 5.4:
ac_cv_func_snprintf=yes
gl_cv_func_printf_directive_a=yes
gl_cv_func_printf_directive_n=yes
gl_cv_func_printf_positions=yes
gl_cv_func_printf_retval_c99=yes
gl_cv_func_printf_s
The preceding was not complete:
* lib/acl.c (ACL_NOT_WELL_SUPPORTED): New macro.
Use it consistently, rather than enumerating errno constants.
Index: lib/acl.c
===
RCS file: /sources/gnulib/gnulib/lib/acl.c,v
retrievi
Hello Ralf,
> > > > for example, --prefix=/tmp/inst$$.
> > >
> > > This bit doesn't. Since /tmp is usually world-writable, you've got your
> > > attack vector already.
> ... So after you've installed
> your stuff, at some point /tmp/inst$$ is removed again (possibly even by
> you). At that ti
Bruno Haible <[EMAIL PROTECTED]> writes:
> If we recommend to use
>
> ./configure --enable-relocatable --prefix=/etc
> make
> make install DESTDIR=/tmp/inst$$
>
> then there should not be a security problem any more, right?
I tend to just use --prefix=$HOME/inst$$.
--
"While the Meli
Bruno Haible wrote:
> Paul Eggert wrote on 2007-02-16:
>> It's a bit of a pain that this will reject all cross-compiled snprintfs.
>> Is there some way you can test for this at compile-time?
>
> Cross-compiles can be handled at configure time, by using predetermined
> test results (and assuming th
progreloc.c is compiled always, even when --enable-relocatable is not
specified. This is pointless. I'm fixing this:
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
Compile progreloc.c only if --enable-relocatable is specified.
* m4/relocatable.m4 (gl_RELOCATABLE): Arrange to compil
Bruce Korb wrote:
> I know this may be seen as flame bait, but is it not just a
> bit easier to simply presume that the gnulib library is always
> going to be at least as standards compliant as the native
> implementation? In other words, why worry? Maybe right now
> I don't use the 'a' directiv
Brian Dessent wrote:
> Er, but the entire reason for the existance of this module was so that
> gdb can use %a to display floating point variables in hex, without
> having to worry about whether the platform's snprintf
Clearly I wasn't clear enough: just always use gnulib's *printf. :)
Bruce Korb wrote:
> In other words, why worry? Maybe right now
> I don't use the 'a' directive, is it worth the bother to go
> back and fix up configure scripts if the 'a' directive creeps
> into my sources?
You said already in [1] that you don't care about code size. Other people care.
gnulib wi
The module vasnprintf-posix defines a vasnprintf() function that supports
POSIX format strings with all frills.
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
* modules/vasnprintf-posix: New file.
* lib/vasnprintf.c: Include isnan.h, isnanl.h, printf-frexp.h,
printf-frexpl.
I'm renaming GETTIMEOFDAY_REPLACEMENT to REPLACE_GETTIMEOFDAY, for
consistency with the idiom used in other modules (REPLACE_FCHDIR,
REPLACE_NANOSLEEP etc.).
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
* lib/sys_time_.h: Rename GETTIMEOFDAY_REPLACEMENT to
REPLACE_GETTIMEOFDAY.
Addendum: This is also needed, to avoid two functions in the same name
(one in libc, the other one possibly in a user-defined shared library -
the overriding would not work in this situation).
*** lib/vasnprintf.h14 May 2005 06:03:58 - 1.4
--- lib/vasnprintf.h4 Mar 2007 23:48:11 -
Here's the full POSIX compliance variant of the 'vasprintf' module.
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
* modules/vasprintf-posix: New file.
* lib/vasprintf.h (asprintf, vasprintf): Rename if REPLACE_VASPRINTF is
defined.
* m4/vasprintf-posix.m4: New file
Portability would be easy if each platform didn't have its own quirks.
It turns out that the implementations of hexadecimal float printing
in glibc <= 2.4 and MacOS X 10.3 are buggy. Both produce control characters
in the output in some case: glibc sometimes outputs \001 and MacOS X sometimes
outpu
On Sun, Mar 04, 2007 at 01:23:58PM -0800, Brian Dessent wrote:
> Er, but the entire reason for the existance of this module was so that
> gdb can use %a to display floating point variables in hex, without
> having to worry about whether the platform's snprintf natively supports
> it or not.
No, th
> * lib/vasprintf.h (asprintf, vasprintf): Rename if REPLACE_VASPRINTF is
> defined.
This is needed too:
2007-03-04 Bruno Haible <[EMAIL PROTECTED]>
* lib/vasprintf.h: Update #if logic for the case when the functions
exist but are overridden.
*** lib/vasprintf.h
Bruce Korb <[EMAIL PROTECTED]> writes:
> Bruno Haible wrote:
>> Paul Eggert wrote on 2007-02-16:
>>> It's a bit of a pain that this will reject all cross-compiled snprintfs.
>>> Is there some way you can test for this at compile-time?
>>
>> Cross-compiles can be handled at configure time, by usin
20 matches
Mail list logo
