The test-binary-io unit test fails under MinGW running under Windows XP.OS: Windows XPMinGW Version: 20110211Gnulib Version: 2011-02-28This test failure can be easily reproduced with the following commands given a skeleton automake project:$ gnulib-tool --with-tests --import poll$ Make the modifica
Thanks for the follow-up. This should now be in plain text.
Here are the requested details about my specific setup. It is a
standard MinGW install (mingw-get-inst-20110211.exe) using the
pre-packaged repository catalogs and MSYS.
Shell: GNU bash, version 3.1.17(1)-release (i686-pc-msys)
Directo
Bruno,I wanted to follow-up with you with the latest information. I used the --create-testdir option per your last mail and the test-binary-io unit test passes for me as well. However, when I create a new project manually (using the same directory as I used with the --dir option alongside --creat
I noticed that there are items in the `Patch Manager' and `Tech
Support Manager' web interfaces under
https://savannah.gnu.org/projects/gnulib. I suspect these aren't
read, and you might want to turn off those forums (or whatever they're
called). Apologies if that's a bad guess.
I was looking th
Gnulib routines call `error', and on a non-glibc system that's likely
to use an uninitialized `program_name' since the variable is
initialized in progname.c, and that's not required. Users probably
won't find out about it until `error' gets called at some stage and
prints junk; if gnulib supports
Paul Eggert <[EMAIL PROTECTED]> writes:
> Under the current approach, it's the caller's responsibility to arrange
> for a program_name variable that works, either by using the progname
> module, or by rolling their own program_name variable.
So gnulib shouldn't be used for libraries (or at least
Paul Eggert <[EMAIL PROTECTED]> writes:
> If we put a similar declaration in
> error.c, it would cause two different definitions of program_name, and
> some non-Unix linkers reject this. (The C Standard allows them to
> reject it.)
Sorry, I thought Unix linkers actually did reject it, which was
Paul Eggert <[EMAIL PROTECTED]> writes:
> Perhaps we could change progname.h so that 'program_name' is a
> function that returns the program name, instead of being a global
> variable.
If it's any help, I can tell you what libroken does; I suspect it's
emulating a BSD facility. (In case you don'
On 20 December 2006 02:28, Andrew Pinski wrote:
>> Paul Brook wrote:
Compiler can optimize it any way it wants,
as long as result is the same as unoptimized one.
>>>
>>> We have an option for that. It's called -O0.
>>>
>>> Pretty much all optimization will change the behavior of your p
On 20 December 2006 02:40, Mike Stump wrote:
> On Dec 19, 2006, at 6:33 PM, Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
>>
>>>> Paul Brook wrote:
>>>>>> Compiler can optimize it any way it wants,
>>>>>> as
On 20 December 2006 16:25, Matthew Woehlke wrote:
> Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
>>>> Paul Brook wrote:
>>>>> Pretty much all optimization will change the behavior of your program.
>>>>
>>>> Now
On 20 December 2006 20:16, Seongbae Park wrote:
> On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> ...
>>> We (in a major, commercial application) ran into exactly this issue.
>>> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this
On 20 December 2006 21:42, Matthew Woehlke wrote:
> Dave Korn wrote:
>>> Particularly lock-free queues whose correct
>>> operation is critically dependent on the order in which the loads and
>>> stores are performed.
>>
>> No, absolutely not. Lock-
On 21 December 2006 02:50, Gabriel Dos Reis wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> [...]
>
>> C is no longer a kind of high-level assembly laguage:
>> it's defined by a standard, in terms of an abstract machine, and some
>> operations are not well-defined.
>
> that does not mean
On 22 December 2006 00:59, Denis Vlasenko wrote:
> Or this, absolutely typical C code. i386 arch can compare
> 16 bits at a time here (luckily, no alighment worries on this arch):
Whaddaya mean, no alignment worries? Misaligned accesses *kill* your
performance!
I know this doesn't affect c
On 30 December 2006 11:49, Robert Dewar wrote:
> Paul Eggert wrote:
Nor would I relish the prospect of keeping wrapv assumptions out of
GCC as other developers make further contributions, as the wrapv
assumption is so natural and pervasive.
>>> It's neither natural not pervasive to
On 31 December 2006 18:47, Paul Eggert wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
> The question is not whether GCC should support wrapv
> semantics; it already does, if you specify -fwrapv.
> The question is merely whether wrapv should be the default
> with optimization levels -O0 thro
e mechanism.
;)
Below is our depsver.mf fragment [1], with comments that may well be
more accurate than my recollection above.
Cheers,
Dave Hart
[1] depsver.mf:
$(DEPDIR)/deps-ver: $(top_srcdir)/deps-ver
@[ -f $@ ] || \
cp
On 03/10/2010 12:24, Ralf Wildenhues wrote:
> [ adding bug-gnulib ]
>
> Hi Dave,
>
> * Dave Korn wrote on Sun, Oct 03, 2010 at 01:42:15PM CEST:
>> I can't find any mention of it at the usual place for external sources
>> (http://gcc.gnu.org/codingconventions.h
dirname.h includes stdbool.h but the dirname module is missing a
Depends-on for it.
___
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
gnulib-tool sucked in xmalloc from something else and that failed to
build because xalloc-die was missing. This fixed it:
--- xalloc.~1.15.~ Sat Apr 16 22:19:07 2005
+++ xalloc Mon May 9 10:50:13 2005
@@ -7,6 +7,7 @@
m4/xalloc.m4
Depends-on:
+xalloc-die
configure.ac:
gl_XALLOC
Paul Eggert <[EMAIL PROTECTED]> writes:
> I omitted stdbool on the theory that packages that to assume C99 don't
> need to use the stdbool module, since stdbool.h comes with C99.
For what it's worth, this wasn't a package assuming c99. I think it
was a result of including something that autoscan
I noticed this, though it didn't seem to confuse gnulib-tool when it
got used.
--- moodules/stat-macros.~1.1.~ Tue Mar 22 07:43:56 2005
+++ moodules/stat-macrosMon May 9 11:21:01 2005
@@ -6,7 +6,6 @@
m4/stat-macros.m4
Depends-on:
-stat-macros
configure.ac:
gl_STAT_MACROS
___
you want more help, you should send us
> the content of your configure.ac, as well as the exact versions of the
> autotools you're using.
FWIW, I think that I've encountered errors like this before when I've installed
libtool in a different directory than I installed automake and/or autoconf.
This causes autom4te/aclocal to be unable to find the libtool m4 files, causing
tracing for LT_INIT to fail, so you get the "not using Libtool" message and
subsequent failures.
-Dave
On 6/19/22, G. Branden Robinson wrote:
> I think that if GNU doesn't have the infrastructure or personnel to
> support these, then, yes, the Savannah administrators should fork (or
> just patch) cgit to the extent necessary to suppress the exposure of
> these snapshot download links. I had no ide
;t exactly what is being mounted at the destination directory.
Instead it is a subdir of the filesystem that is being mounted there.
I'm submitting patches to both gnulib and coreutils to correct this issue.
Thank you,
Dave Chiluk
Add me_mountroot to mount_entry so linux machines based on
/proc/self/mountinfo can distinguish between bind mounts and original
mounts. In reality bind mounts aren't treated any different than
mountroot=/ mounts by the kernel, but this is still confusing to the
user, and a change in behavior
More
I agree with all suggestions. I'm posting a revised patch shortly.
Dave.
On 08/28/2015 07:42 PM, Pádraig Brady wrote:
> On 28/08/15 21:41, Dave Chiluk wrote:
>> Add me_mountroot to mount_entry so linux machines based on
>> /proc/self/mountinfo can distinguish between bind
Add me_mountroot to mount_entry so linux machines based on
/proc/self/mountinfo can distinguish between bind mounts and original
mounts. In reality bind mounts aren't treated any different than
mountroot=/ mounts by the kernel, but this is still confusing to the
user, and a change in behavior
More
On 09/08/2015 04:51 PM, Pádraig Brady wrote:
> On 31/08/15 22:07, Dave Chiluk wrote:
>> Add me_mountroot to mount_entry so linux machines based on
>> /proc/self/mountinfo can distinguish between bind mounts and original
>> mounts. In reality bind mounts aren't
30 matches
Mail list logo
