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
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
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
;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
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
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
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
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
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
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
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
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 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 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 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 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 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 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 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
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'
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:
> 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
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
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
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
___
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
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
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
30 matches
Mail list logo
