Re: [distcc] [patch] Add a few missing bits for OS X support
Sorry, should patches be sent to distcc-patc...@googlegroups.com or
distcc@lists.samba.org?
Cheers,
Rafael
Index: include_server/include_analyzer.py
===
--- include_server/include_analyzer.py (revision 750)
+++ include_server/include_analyzer.py (working copy)
@@ -83,7 +83,8 @@
# Make a compressor for source files.
self.compress_files = compress_files.CompressFiles(self.includepath_map,
self.directory_map,
- self.realpath_map)
+ self.realpath_map,
+ self.mirror_path)
# A fast cache for avoiding calls into the mirror_path object.
self.mirrored = set([])
@@ -269,7 +270,8 @@
# handful. We add put the system links first, because there should be very
# few of them.
links = self.compiler_defaults.system_links + self.mirror_path.Links()
-files = self.compress_files.Compress(include_closure, client_root_keeper)
+files = self.compress_files.Compress(include_closure, client_root_keeper,
+ self.currdir_idx)
forcing_files = self._ForceDirectoriesToExist()
Index: include_server/parse_command.py
===
--- include_server/parse_command.py (revision 750)
+++ include_server/parse_command.py (working copy)
@@ -51,7 +51,7 @@
self.after_system_dirs = []
self.language = 'none'# equivalent to commandline of '-x none'
-self.isysroot = None
+self.isysroot =
self.sysroot =
self.output_file = None
self.iprefix =
@@ -63,6 +63,11 @@
def set_sysroot(self, x): self.sysroot = x
def set_outputfile(self, x): self.output_file = x
def set_iprefix(self, x): self.iprefix = x
+ def include_sysroot(self):
+# FIXME: Is this the correct precedence for isysroot and sysroot?
+if self.sysroot:
+ return self.sysroot
+return self.isysroot
def _SplitMacroArg(arg):
Split an arg as found in -Darg
@@ -96,6 +101,7 @@
'-MF':lambda ps, arg: None,
'-MT':lambda ps, arg: None,
'-MQ':lambda ps, arg: None,
+ '-arch': lambda ps, arg: None,
'-include': lambda ps, arg: ps.include_files.append(arg),
'-imacros': lambda ps, arg: ps.include_files.append(arg),
'-idirafter': lambda ps, arg: ps.after_system_dirs.append(arg),
@@ -104,13 +110,12 @@
os.path.join(ps.iprefix, arg)),
'-iwithprefixbefore': lambda ps, arg: ps.i_dirs.append(
os.path.join(ps.iprefix, arg)),
-# '-isysroot': lambda ps, arg: ps.set_isysroot(arg),
- '-isysroot': lambda ps, arg: _RaiseNotImplemented('-isysroot'),
+ '-isysroot': lambda ps, arg: ps.set_isysroot(arg),
'-imultilib': lambda ps, arg: _RaiseNotImplemented('-imultilib'),
'-isystem': lambda ps, arg: ps.before_system_dirs.append(arg),
'-iquote':lambda ps, arg: ps.quote_dirs.append(arg),
}
-CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS = ('M', 'i', '-')
+CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS = ('M', 'i', '-', 'a')
# A compile-time check to make sure the first-letter list is up-to-date
for key in CPP_OPTIONS_MAYBE_TWO_WORDS.keys():
assert key[1] in CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS
@@ -447,7 +452,8 @@
parse_state.language = basics.TRANSLATION_UNIT_MAP[suffix]
assert parse_state.language in basics.LANGUAGES
- compiler_defaults.SetSystemDirsDefaults(compiler, parse_state.sysroot,
+ sysroot = parse_state.include_sysroot()
+ compiler_defaults.SetSystemDirsDefaults(compiler, sysroot,
parse_state.language, timer)
def IndexDirs(dir_list):
@@ -464,9 +470,10 @@
angle_dirs = IndexDirs(parse_state.i_dirs)
angle_dirs.extend(IndexDirs(parse_state.before_system_dirs))
if not parse_state.nostdinc:
+sysroot = parse_state.include_sysroot()
angle_dirs.extend(
IndexDirs(compiler_defaults.system_dirs_default
-[compiler][parse_state.sysroot][parse_state.language]))
+[compiler][sysroot][parse_state.language]))
angle_dirs.extend(IndexDirs(parse_state.after_system_dirs))
quote_dirs = IndexDirs(parse_state.quote_dirs)
Index: include_server/compress_files.py
===
--- include_server/compress_files.py(revision 750)
+++ include_server/compress_files.py(working copy)
@@ -27,7 +27,7 @@
class CompressFiles(object):
- def __init__(self, includepath_map, directory_map, realpath_map):
+ def __init__(self, includepath_map, directory_map, realpath_map,
mirror_path):
Constructor.
Arguments:
@@ -38,10 +38,11 @@
self.includepath_map =
Re: [distcc] [patch] Add a few missing bits for OS X support
ccing distcc@lists.samba.org On 06/12/11 11:56 AM, Rafael Espíndola wrote: The attached patch is not complete, but it adds enough features and fixes to let distcc pump build a slightly patched version of firefox on OS X. What the patch does is * add support for -isysroot and -arch * Fix a really nasty corner case: * CompressFiles::Compress uses os.makedirs to create a directory (foo) for one compilation unit * Another compilation unit does the equivalent of '#include foo/../bar.h' * The compilation unit uses no other file in foo * We conclude that we don't have to create a dummy foo/forcing_technique_271828 Cheers, Rafael Cheers, Rafael __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [patch] Add a few missing bits for OS X support
On 14/12/11 04:16 PM, Rafael Ávila de Espíndola wrote:
ccing distcc@lists.samba.org
Now with the patch. Sorry about the noise.
Cheers,
Rafael
Index: include_server/include_analyzer.py
===
--- include_server/include_analyzer.py (revision 750)
+++ include_server/include_analyzer.py (working copy)
@@ -83,7 +83,8 @@
# Make a compressor for source files.
self.compress_files = compress_files.CompressFiles(self.includepath_map,
self.directory_map,
- self.realpath_map)
+ self.realpath_map,
+ self.mirror_path)
# A fast cache for avoiding calls into the mirror_path object.
self.mirrored = set([])
@@ -269,7 +270,8 @@
# handful. We add put the system links first, because there should be very
# few of them.
links = self.compiler_defaults.system_links + self.mirror_path.Links()
-files = self.compress_files.Compress(include_closure, client_root_keeper)
+files = self.compress_files.Compress(include_closure, client_root_keeper,
+ self.currdir_idx)
forcing_files = self._ForceDirectoriesToExist()
Index: include_server/parse_command.py
===
--- include_server/parse_command.py (revision 750)
+++ include_server/parse_command.py (working copy)
@@ -51,7 +51,7 @@
self.after_system_dirs = []
self.language = 'none'# equivalent to commandline of '-x none'
-self.isysroot = None
+self.isysroot =
self.sysroot =
self.output_file = None
self.iprefix =
@@ -63,6 +63,11 @@
def set_sysroot(self, x): self.sysroot = x
def set_outputfile(self, x): self.output_file = x
def set_iprefix(self, x): self.iprefix = x
+ def include_sysroot(self):
+# FIXME: Is this the correct precedence for isysroot and sysroot?
+if self.sysroot:
+ return self.sysroot
+return self.isysroot
def _SplitMacroArg(arg):
Split an arg as found in -Darg
@@ -96,6 +101,7 @@
'-MF':lambda ps, arg: None,
'-MT':lambda ps, arg: None,
'-MQ':lambda ps, arg: None,
+ '-arch': lambda ps, arg: None,
'-include': lambda ps, arg: ps.include_files.append(arg),
'-imacros': lambda ps, arg: ps.include_files.append(arg),
'-idirafter': lambda ps, arg: ps.after_system_dirs.append(arg),
@@ -104,13 +110,12 @@
os.path.join(ps.iprefix, arg)),
'-iwithprefixbefore': lambda ps, arg: ps.i_dirs.append(
os.path.join(ps.iprefix, arg)),
-# '-isysroot': lambda ps, arg: ps.set_isysroot(arg),
- '-isysroot': lambda ps, arg: _RaiseNotImplemented('-isysroot'),
+ '-isysroot': lambda ps, arg: ps.set_isysroot(arg),
'-imultilib': lambda ps, arg: _RaiseNotImplemented('-imultilib'),
'-isystem': lambda ps, arg: ps.before_system_dirs.append(arg),
'-iquote':lambda ps, arg: ps.quote_dirs.append(arg),
}
-CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS = ('M', 'i', '-')
+CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS = ('M', 'i', '-', 'a')
# A compile-time check to make sure the first-letter list is up-to-date
for key in CPP_OPTIONS_MAYBE_TWO_WORDS.keys():
assert key[1] in CPP_OPTIONS_MAYBE_TWO_WORDS_FIRST_LETTERS
@@ -447,7 +452,8 @@
parse_state.language = basics.TRANSLATION_UNIT_MAP[suffix]
assert parse_state.language in basics.LANGUAGES
- compiler_defaults.SetSystemDirsDefaults(compiler, parse_state.sysroot,
+ sysroot = parse_state.include_sysroot()
+ compiler_defaults.SetSystemDirsDefaults(compiler, sysroot,
parse_state.language, timer)
def IndexDirs(dir_list):
@@ -464,9 +470,10 @@
angle_dirs = IndexDirs(parse_state.i_dirs)
angle_dirs.extend(IndexDirs(parse_state.before_system_dirs))
if not parse_state.nostdinc:
+sysroot = parse_state.include_sysroot()
angle_dirs.extend(
IndexDirs(compiler_defaults.system_dirs_default
-[compiler][parse_state.sysroot][parse_state.language]))
+[compiler][sysroot][parse_state.language]))
angle_dirs.extend(IndexDirs(parse_state.after_system_dirs))
quote_dirs = IndexDirs(parse_state.quote_dirs)
Index: include_server/compress_files.py
===
--- include_server/compress_files.py(revision 750)
+++ include_server/compress_files.py(working copy)
@@ -27,7 +27,7 @@
class CompressFiles(object):
- def __init__(self, includepath_map, directory_map, realpath_map):
+ def __init__(self, includepath_map, directory_map, realpath_map,
mirror_path):
Constructor.
Arguments:
@@ -38,10
Re: [distcc] [PATCH][RFC] variable overlapping causing errors...
Thanks for the patch! Applied in svn revision 733.
On Tue, Oct 5, 2010 at 1:12 PM, Ian Kumlien po...@vapor.com wrote:
Hi,
It seems like s6_addr is a reserved type, on my macine (Gentoo linux,
building current svn trunk) i get the following error:
src/access.c: In function 'set_mask_inet6':
src/access.c:118:14: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '.' token
src/access.c:118:14: error: expected expression before '.' token
src/access.c:123:9: error: '__in6_u' undeclared (first use in this
function)
src/access.c:123:9: note: each undeclared identifier is reported only once
for each function it appears in
make: *** [src/access.o] Error 1
The fix is quite easy, when you see it:
This line:
uint8_t *s6_addr = addr-s6_addr;
Expands to:
uint8_t *__in6_u.__u6_addr8 = addr-__in6_u.__u6_addr8;
Which is wrong, this patch is against r730 on trunk.
--- src/access.c.orig 2010-10-05 19:01:56.133363116 +0200
+++ src/access.c2010-10-05 19:02:25.911554579 +0200
@@ -115,18 +115,18 @@
* Set a v6 address, @p addr, to a mask of @p mask_size bits.
**/
static void set_mask_inet6(struct in6_addr *addr, int mask_bits) {
-uint8_t *s6_addr = addr-s6_addr;
+uint8_t *ip6_addr = addr-s6_addr;
int allones_count = mask_bits / 8;
int i;
for (i = 0; i allones_count; i++)
-s6_addr[i] = allones8;
+ip6_addr[i] = allones8;
-s6_addr[i] = ~(allones8 (mask_bits % 8));
+ip6_addr[i] = ~(allones8 (mask_bits % 8));
i++;
for (; i 16; i++)
-s6_addr[i] = 0;
+ip6_addr[i] = 0;
}
#endif /* ENABLE_RFC2553 */
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
--
Fergus Henderson fer...@google.com
Defend the user, exclude no one, and create magic. -- Eric Schmidt.
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] PATCH: packaging/RedHat/init.d/distcc
Applied in SVN revision 711. On Wed, Dec 16, 2009 at 11:29 PM, Tal tal@gmail.com wrote: Hi, A silly patch - in packaging/RedHat/init.d/distcc the executable is once refereed to using the variable EXEC, and once as with the explicit expected name. Change it to always use the EXEC variable. Tal $ svn diff Index: packaging/RedHat/init.d/distcc === --- packaging/RedHat/init.d/distcc (revision 710) +++ packaging/RedHat/init.d/distcc (working copy) @@ -103,7 +103,7 @@ RETVAL=0 -[ -x /usr/bin/distccd ] || exit 0 +[ -x $EXEC ] || exit 0 ALLOWFILE= if test -f $CONFIGDIR/$DOMAIN/clients.allow; then __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc -- Fergus Henderson fer...@google.com __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] IPv6 ACLs
On Mon, 2009-07-20 at 22:23 -0400, Fergus Henderson wrote:
Oh, I see that the old code that this is replacing didn't check the
return value of strdup() either.
Indeed, both of the issues you raised were a continuation of the modus
operandi. As you noted, the return value of strdup() was not checked.
Also, the following non-standard C was used in srvnet.c:
-const in_addr_t *a4;
...
-a4 = (const in_addr_t *) a6-s6_addr[12];
Regardless, I've updated the patch to correct these issues. I've also
made two more updates. One is a fix to ensure the maximum bit mask size
is set according to the address family and not just whether RFC2553
support is enabled.
The other, slightly more worrying update modifies the non-RFC2553 code
to use inet_aton() instead of inet_pton(). The inet_pton() function is
defined in RFC2553. This is worrying because it means that people have
been compiling distcc without RFC2553 support enabled but still using a
function defined by that RFC. The fact that this state has continued
without being noticed previously calls into question the value of
maintaining non-RFC2553 code at all.
--
Bob Ham r...@bash.sh
Index: src/access.c
===
--- src/access.c (revision 676)
+++ src/access.c (working copy)
@@ -37,6 +37,7 @@
#include sys/socket.h
#include netinet/in.h
#include arpa/inet.h
+#include netdb.h
#include types.h
#include distcc.h
@@ -47,79 +48,329 @@
/**
* @file
*
- * Simple IP-based access-control system
+ * IP-based access-control system
*/
-static const in_addr_t allones = 0xUL;
+static const uint32_t allones = 0xUL;
+static const uint8_t allones8 = 0xffU;
+/**
+ * Split a HOST/BITS mask specification into HOST and BITS.
+ *
+ * @returns 0 on success or -1 if the program ran out of heap space
+ **/
+static int split_mask(const char *spec,
+ char **host,
+ const char **bits)
+{
+int value_len = strcspn(spec, /);
+
+if (host != NULL) {
+char *host_str;
+
+host_str = malloc(value_len + 1);
+if (host_str == NULL) {
+rs_log_error(could not allocate memory (%d bytes), value_len + 1);
+return -1;
+}
+strncpy(host_str, spec, value_len);
+host_str[value_len] = '\0';
+
+*host = host_str;
+}
+
+if (bits != NULL) {
+if (spec[value_len] spec[value_len + 1])
+*bits = spec + value_len + 1;
+else
+*bits = NULL;
+}
+
+return 0;
+}
/**
+ * Set a dcc_address_t to a full mask.
+ **/
+static void set_allones(dcc_address_t *addr)
+{
+#ifndef ENABLE_RFC2553
+addr-s_addr = allones;
+#else
+memset(addr-addr, allones8, sizeof(struct in6_addr));
+#endif
+}
+
+
+/**
+ * Set a 32-bit address, @p addr, to a mask of @p mask_size bits.
+ **/
+static inline void set_mask_inet(struct in_addr *addr, int mask_bits) {
+addr-s_addr = htonl(~(allones mask_bits));
+}
+
+
+#ifdef ENABLE_RFC2553
+/**
+ * Set a v6 address, @p addr, to a mask of @p mask_size bits.
+ **/
+static void set_mask_inet6(struct in6_addr *mask, int mask_bits) {
+uint8_t *iptr = mask-s6_addr;
+int allones_count = mask_bits / 8;
+int i;
+
+for(i = 0; i allones_count; ++i, ++iptr)
+*iptr = allones8;
+
+*iptr = ~(allones8 (mask_bits % 8));
+++iptr;
+
+for(i = 16 - allones_count - 1; i 0; --i, ++iptr)
+*iptr = 0;
+}
+#endif /* ENABLE_RFC2553 */
+
+
+/**
+ * Set a dcc_address_t to a mask of @p mask_bits bits. The family field of
+ * the address should be set appropriately if RFC2553 is enabled.
+ **/
+static void set_mask(dcc_address_t *mask, int mask_bits)
+{
+#ifndef ENABLE_RFC2553
+set_mask_inet(mask, mask_bits);
+#else
+if (mask-family == AF_INET)
+set_mask_inet(mask-addr.inet, mask_bits);
+else
+set_mask_inet6(mask-addr.inet6, mask_bits);
+#endif
+}
+
+/**
* Interpret a HOST/BITS mask specification. Return @p value and @p mask.
**/
int dcc_parse_mask(const char *spec,
- in_addr_t *value,
- in_addr_t *mask)
+ dcc_address_t *value,
+ dcc_address_t *mask)
{
-int value_len;
-struct in_addr ia;
-int mask_bits;
char *value_str;
-int matched;
+int ret;
const char *mask_str;
-
-value_len = strcspn(spec, /);
-
-/* get bit before slash */
-value_str = strdup(spec);
-value_str[value_len] = '\0';
-matched = inet_pton(AF_INET, value_str, ia);
-
+#ifndef ENABLE_RFC2553
+struct in_addr ia;
+#else
+struct addrinfo hints;
+struct addrinfo *res;
+#endif
+
+ret = split_mask(spec, value_str, mask_str);
+if (ret == -1)
+return EXIT_OUT_OF_MEMORY;
+
/* extract and parse value part */
-if (!matched) {
+#ifndef ENABLE_RFC2553
+ret = inet_aton(value_str,
Re: [distcc] [PATCH] IPv6 ACLs
Thanks for the patch!
Some comments:
+host_str = malloc(value_len + 1);
+strncpy(host_str, spec, value_len);
Here you are not checking the return value of malloc().
Oh, I see that the old code that this is replacing didn't check the return
value of strdup() either.
So I guess this is no worse.
+static void set_allones(dcc_address_t *addr)
+{
+#ifndef ENABLE_RFC2553
+*addr = *(dcc_address_t *)allones;
I'm concerned that this code may violate the C standard's rules on
aliasing/type-punning.
+static void set_mask_inet6(struct in6_addr *mask, int mask_bits) {
+uint32_t *iptr = (uint32_t *)mask;
+int allones_count = mask_bits / 32;
+int i;
+
+for(i = 0; i allones_count; ++i, ++iptr)
+*iptr = allones;
+
+set_mask_32(iptr, mask_bits % 32);
+++iptr;
+
+for(i = 4 - allones_count - 1; i 0; --i, ++iptr)
+*iptr = 0;
+}
Likewise here.
The C standard says: (ISO/IEC 9899:TC2, section 6.5, paragraph 7):
An object shall have its stored value accessed only by an lvalue expression
that has one of
the following types:74)
-- a type compatible with the effective type of the object,
-- a qualified version of a type compatible with the effective type of the
object,
-- a type that is the signed or unsigned type corresponding to the effective
type of the
object,
-- a type that is the signed or unsigned type corresponding to a qualified
version of the
effective type of the object,
-- an aggregate or union type that includes one of the aforementioned types
among its
members (including, recursively, a member of a subaggregate or contained
union), or
-- a character type.
The Posix standard says:
[IP6 javascript:open_code('IP6')] [image: [Option Start]] The *
netinet/in.h* header shall define the *in6_addr* structure that contains
at least the following member:
uint8_t s6_addr[16]
So in general I don't think it is standard-conforming to assume that an
in6_addr can be treated as an array of uint32_t.
I think that this issue could be avoided by rewriting the code using uint8_t
instead of uint32_t and using the s6_addr member of the in6_addr struct
instead of casts.
Now in practice the code probably works fine. So maybe I'm being a bit
pedantic here.
But I think it could be made standard-conforming without that much
additional effort.
What do you think?
Cheers,
Fergus.
On Mon, Jul 13, 2009 at 4:52 AM, Bob Ham r...@bash.sh wrote:
Hi there,
The attached patch implements IPv6 support for access control. It also
includes a small update to restrict zeroconf advertisements to IPv4 if
RFC2553 support isn't enabled.
I've tested the patch both with RFC2553 support enabled and without.
There seem to be no regressions.
A more extensive zeroconf update will follow to restrict the addresses
it advertises to ones that are actually listened on. It seems there may
be issues listening on IPv6 addresses as well.
Regards,
Bob Ham
--
Bob Ham r...@bash.sh
for (;;) { ++pancakes; }
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
--
Fergus Henderson fer...@google.com
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for dcc_unlock()
Thanks. This patch has been integrated in the distcc 3.0 sources at distcc.googlecode.com (you can thank Craig Silverstein for that). On Wed, Jun 4, 2008 at 10:17 AM, Sascha Demetrio [EMAIL PROTECTED] wrote: Hi! The current implementation of dcc_unlock() performs the unlock by closing the associated file descriptor. This only works correctly with flock() based locking. For fcntl(F_SETLK) and lockf() style locking, the lock is associated with the calling process, not with the fd - so an explicit unlocking call is required. The attached patch fixes this problem. Kind regards, Sascha Demetrio ___ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Crytek GmbH - http://www.crytek.com __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc -- Fergus Henderson [EMAIL PROTECTED] __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] Updated Avahi/Zeroconf support for distcc
On Sun, 30 Dec 2007 16:55:49 +0100 Lennart Poettering [EMAIL PROTECTED] wrote: I updated my Zeroconf/Avahi patch for distcc (2.18.3) I am just wondering if Martin Pool is ever going to reply to this message, or to the message from Matias D'Ambrosio dated 10 Dec 2007 (Bug in argutil.c:63)? -- All unaccompanied children will be given espresso and a free kitten. -- Free pop3 email with a spam filter. http://www.bluebottle.com/tag/5 __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch EmptySource_Case because of GCC 3.4.x Regresion
On 10 Jan 2006, Niklaus Giger [EMAIL PROTECTED] wrote: Hi A small patch with an explanation, why Patch EmptySource_Case fails with GCC 3.4 Thanks, taken. -- Martin signature.asc Description: Digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for make maintainer-clean if LANG != C
On 9 Jan 2006, Niklaus Giger [EMAIL PROTECTED] wrote: Hi This small patches fixes make maintainer-check if the environment variable LANG is set to something differtent of C. Thanks, taken. -- Martin signature.asc Description: Digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [patch] benchmark url update patch
On Thu, 2005-12-22 at 18:27 -0800, Dongmin Zhang wrote: Hello, The benchmark URLs coming with distcc-2.18.3 source are kind of stale. We made a patch updates the benchmark URLs. Attached please find the patch, or you can find it here http://students.cs.tamu.edu/dzhang/ Thanks, applied. -- Martin signature.asc Description: This is a digitally signed message part __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch?
Hi Martin, 2) Only print the newline after a series of distcc calls have been displayed (...) -printf(\n); +if(havePrinted) +printf(\n); Same can be done without the additional variable, see attached patch. Can you please consider my patch for inclusion into distccmon-text? Thanks, -- Jean Delvare __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch?
Hi Eddie, Here's a patch for what I've worked on. Just to reiterate this patch does the following to distccmon-text: 1) Add a timestamp to every line from the distccmon-text output 2) Only print the newline after a series of distcc calls have been displayed And here's the patch. Any chance this could make it into the official tree? (I tried submitting using tla, but apparently I don't have access. :) ) Both improvements sound very good to me, even if I am not a regular user of distccmon-text. I however have several objections to your implementation, and some more general comments about patch submission. --- orig/src/mon-text.c +++ mod/src/mon-text.c @@ -36,7 +36,7 @@ #include exitcode.h #include snprintf.h #include mon.h - +#include time.h I can't find any file named time.h in the distcc project. Don't you really mean time.h? @@ -85,25 +85,38 @@ * other program, so make sure we're always line buffered. */ setvbuf (stdout, NULL, _IOLBF, BUFSIZ); +char currentTimeAsString[9]; Older C compilers will not like variables being declared in the middle of a block. Also, please change the name of that variable. The distcc project names variables this_way, not thatWay. Same applies to all variables declared in your patch. -#if 1 + +havePrinted = 1; + if (i-curr_phase == DCC_PHASE_DONE) continue; -#endif I wouldn't drop #if/#endif, even if I don't know why it is there. I guess Martin has good reasons. +strftime(currentTimeAsString, 9, %H:%M:%S, localtime(currentTime)); Note that your mailer breaks long lines. I had to edit your patch manually before I could apply it. Either configure your client differently, or submit your patches as attachements instead of inline. /* Assume 80 cols = */ -printf(%6ld %-10.10s %-30.30s %24.24s[%d]\n, +printf([%8s] %6ld %-10.10s %-30.30s %24.24s[%d]\n, +currentTimeAsString, (long) i-cpid, dcc_get_phase_name(i-curr_phase), i-file, i-host, i-slot); This doesn't fit in 80 columns anymore, while this was very convenient. Also notice that you are computing the time string for each file/host line, while it will always be (almost) the same time. I would suggest that you compute the time string *outside* of the for loop, and print it only *once*, before the loop. This would result in something like: [12:59:26] 7181 Compile mon-text.c arrakis[0] 7177 Compile mon.c localhost[0] 7157 Compile popt.c mahadeva[0] instead of: [12:59:26] 7181 Compile mon-text.c arrakis[0] [12:59:26] 7177 Compile mon.c localhost[0] [12:59:26] 7157 Compile popt.c mahadeva[0] This has the following advantages: 1* Still fits on 80 columns. 2* Less computation. If you insist to have a the time on each line, please at least change the widths so that the lines will fit on 80 columns again. -printf(\n); +if(havePrinted) +printf(\n); Same can be done without the additional variable, see attached patch. And a more general comment: I'd suggest that you do not include several improvements in a single patch. One change per patch makes reviewing and merging way easier. Care to redo a patch implementing (1) only (since mine implements (2) more efficiently, or so I think), and addressing the points I listed above? Martin, like my patch? Thanks, -- Jean Delvare --- distcc-2.18.3/src/mon-text.c.orig 2004-10-24 07:05:49.0 +0200 +++ distcc-2.18.3/src/mon-text.c2005-02-20 13:04:19.0 +0100 @@ -103,7 +103,9 @@ i-file, i-host, i-slot); } -printf(\n); +/* Scroll only if something is actually happening */ +if (i != list) +printf(\n); /* XXX: usleep() is probably not very portable */ usleep(delay * 100); __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
RE: [distcc] Patch?
I personally would *love* a curses monitor. :) That said, I've never worked in curses, so I think I'll just submit my patch for now... :) Cheers! -e- -Original Message- From: Martin Pool [mailto:[EMAIL PROTECTED] Sent: Friday, February 11, 2005 3:02 PM To: Eddie Parker Cc: distcc@lists.samba.org Subject: Re: [distcc] Patch? On 11 Feb 2005, Eddie Parker [EMAIL PROTECTED] wrote: Hello! I love distcc, but the default output from the distccmon-text kinda drives me nuts. I am ready and willing to submit a patch to fix this, but I thought it would be best to ask first if it's OK to do such a thing. J Basically what I want to do is this: 1) Add a timestamp to every line from the distccmon-text output 2) Only print the newline if distccmon-text has encountered a call to itself. Would this be OK? I find it to be very useful. J Of course it's OK. Perhaps there should be a curses monitor instead... -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
RE: [distcc] Patch?
On Fri, 2005-11-02 at 16:02 -0700, Eddie Parker wrote: I personally would *love* a curses monitor. :) Using watch(1) can give curses-like output that is also similar to the gui monitor: watch -n 1 distccmon-text That said, having better output built into distccmon-text would be great. -- Nathan __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for propogating environment variables
Devon H. O'Dell wrote: Hello, [snip] __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc For those interested, I've completed a the preliminary patch for this functionality. It's available at: http://www.the-bofh.org/projects/distcc-env/ I'd be interested to know if this is at all useful for other projects or if it helps others perhaps use GCC bootstraps (especially across BSD systems). Kind regards, Devon H. O'Dell __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for propogating environment variables
On Thu, 25 Nov 2004 17:46:58 +0100, Devon H. O'Dell [EMAIL PROTECTED] wrote: For those interested, I've completed a the preliminary patch for this functionality. It's available at: http://www.the-bofh.org/projects/distcc-env/ I think it would be OK to merge this functionality (I haven't looked at the updated patch yet). I might save it for the next protocol bump though. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for propogating environment variables
Martin Pool wrote: On Thu, 25 Nov 2004 17:46:58 +0100, Devon H. O'Dell [EMAIL PROTECTED] wrote: For those interested, I've completed a the preliminary patch for this functionality. It's available at: http://www.the-bofh.org/projects/distcc-env/ I think it would be OK to merge this functionality (I haven't looked at the updated patch yet). I might save it for the next protocol bump though. Well, I do need to make it reset the environment to the original state once it's done, but other than that, even the protocols are handled (I've added a 1.1 and 2.1 protocol, plus a hostspec parser, so that hostname,env,lzo hostname2,env hostname3,lzo hostname4 will use protocol 2.1 for hostname, 1.1 for hostname2, 2.0 for hostname3, 1.0 for hostname). It'd obviously be pretty easy to just switch this to a 3.0. Other than that, it works pretty well. At least it's possible to build DragonFly with distcc :) --Devon __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] retry compiling when remote gcc was killed by signal
Jakub Stachowski wrote:
I noticed that return codes 128 (which means that compiler was killed by
signal) is treated exactly as normal compilation error. However, killing
compiler indicates problems with system (in most cases not enough memory) or
compiler itself, not with source code. So there is still chance that retrying
compilation on local machine will succeed. Typical example: I compile KDE
(lots of big c++ files) on several machines with 64-128MB of RAM ('localhost'
has 512MB RAM). I use distccKnoppix so there is no possibility to use swap on
these machines. Sometimes one of them run out of memory and gcc gets killed
and make finishes with error. Then I have to restart make with -j1 (to build
offending file on localhost as it has enough RAM), then restart it again with
-j8 and hope for the best.
Sorry for jumping in so late on this thread, I just joined the list today.
This feature is something I've wanted for a long time. I haven't tried
this patch yet (I'm having other problems with distcc I'll complain about
in a future message), but the description sounds like exactly what I've
been looking for.
I use distcc to speed compile jobs on both linux and solaris. All of the
other machines in the distcc farm are win2k/xp cygwin cross-compilers.
All machines have 1G of RAM (most of the windows boxes were upgraded to 1G
just to run distcc). The windows boxes are not dedicated to distcc -- they
are normal desktop systems other developers use, and these are sometimes
running local compiles of their own (with visual studio) which can eat up
resources temporarily. It also seems like a large compile job that our
linux machine can handle will sometimes run out of virtual memory if
distributed to a similarly configured windows box even when it isn't
heavily loaded.
Most of the files we compile are medium sized, but we have a handful of
files that are huge, usually generated from an IDL compiler. With these,
the .cpp source file is larger than one megabyte, and when preprocessed it
is three megabytes or more. Often these will cause internal compiler
errors in g++ on the windows machines if they are given these large files.
Initially, I had to do the same thing as Jakub: manually 'make -j1' to
compile that file, then break and restart with -j15. After a while, I
patched our distcc client to force any files greater than some arbitrary
size (around 2M) to compile locally, and I kept lowering that size until
the errors mostly stopped. What I really wanted was a way to make it
retry remote failures locally, but it wasn't immediately obvious to me how
to do that so I made a simpler but uglier fix.
Anyway, I just wanted to say thanks for the patch -- I look forward to
trying it. This feature is definitely something I'd like to see become
part of the regular distcc distribution (even if it has to be enabled with
an environment variable). And thanks to Martin and the rest of the distcc
developers... distcc has made developing a large project on unix so much
more enjoyable.
Eric
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] use GtkStatusbar in distccmon-gnome
On 8 Jul 2004, Nathan Fredrickson [EMAIL PROTECTED] wrote: Hello, I discovered distcc recently and I'm very impressed by how well it works. The attached patch improves distccmon-gnome by replacing the label with a real status bar. It looks better, has a grab handle for resizing the window, and follows the HIG. Looks good. -- Martin signature.asc Description: Digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] add ability to use *part* of absolute path to compiler
On 29 May 2004, Dan Kegel [EMAIL PROTECTED] wrote: The following is in use in crosstool-0.28-rc16 and works well; it's useful when your servers are offering many toolchains which cannot be distinguished without a pathname, but which are installed as a group at different absolute locations on different machines (as happens commonly when you have a hetrogenous cluster accessing the compilers from a single shared server). The interface leaves something to be desired, but I didn't want to do real option processing in the first pass (I guess I was lazy). Comments, anyone? The basic idea of wanting to apply a kind of filter to the compiler name is OK. I would rather see if there was a cleaner/simpler/more general way to describe it though. -- Martin signature.asc Description: Digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] add ability to use *part* of absolute path to compiler
Martin Pool wrote: On 29 May 2004, Dan Kegel [EMAIL PROTECTED] wrote: The following is in use in crosstool-0.28-rc16 and works well; it's useful when your servers are offering many toolchains which cannot be distinguished without a pathname, but which are installed as a group at different absolute locations on different machines (as happens commonly when you have a hetrogenous cluster accessing the compilers from a single shared server). The interface leaves something to be desired, but I didn't want to do real option processing in the first pass (I guess I was lazy). Comments, anyone? The basic idea of wanting to apply a kind of filter to the compiler name is OK. I would rather see if there was a cleaner/simpler/more general way to describe it though. I tried to encapsulate the actual filter implementation so it could be replaced by something nicer later. I considered using regexps, but that seemed (a) insecure, (b) more complicated, and (c) harder to use for my application. I'm going to use my patch as-is for now, but would be happy to consider improvements if anyone had concrete suggestions. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] Adding host list randomization
On 28 May 2004, Josh Hyman [EMAIL PROTECTED] wrote:
In http://lists.samba.org/archive/distcc/2004q2/002250.html, Dan
proposed randomizing the hosts list. Here's a patch to add that
feature, controlled by a special --randomize option in the hosts list.
On a large shared build cluster, this helps spread the load
without requiring separate hosts lists for each user.
Martin, what do you think?
Hi Josh,
Thankyou for the patch. It looks OK to me, except that I am not sure
if it should be an option specified in that way. I wonder if it
should always be on? Or at least, if it should always be on until we
have some kind of automatic weighting of faster machines.
Rather than the qsort I think it is OK to just do a simple shuffle.
Can I just check Google is OK for this to be released under the GPL?
-- Josh
--- distcc-2.14/man/distcc.1.dist2004-05-27 17:15:27.0 -0700
+++ distcc-2.14/man/distcc.12004-05-27 18:07:52.0 -0700
@@ -221,7 +221,9 @@
distcc prefers hosts towards the start of the list, so machines should
be listed in descending order of speed. In particular, when only a
single compilation can be run (such as from a configure script), the
-first machine listed is used.
+first machine listed is used (but see
+.I --randomize
+below).
.PP
Placing
.I localhost
@@ -235,6 +237,14 @@
client is less than one fifth of the total, then the client should be
left out of the list.
.PP
+If you have a large shared build cluster and a single shared hosts file,
+the above rules would cause the first few machines in the hosts
+file to be tried first even though they are likely to be busier than machines
+later in the list. To avoid this, place the keyword
+.I --randomize
+into the host list. This will cause the host list to be randomized,
+which should improve performance slightly for large build clusters.
+.PP
Performance depends on the details of the source and makefiles used
for the project, and the machine and network speeds. Experimenting
with different settings for the host list and -j factor may improve
@@ -245,6 +255,7 @@
.nf
DISTCC_HOSTS = HOSTSPEC ...
HOSTSPEC = LOCAL_HOST | SSH_HOST | TCP_HOST | OLDSTYLE_TCP_HOST
+| GLOBAL_OPTION
LOCAL_HOST = localhost[/LIMIT]
SSH_HOST = [EMAIL PROTECTED]/LIMIT][:COMMAND][OPTIONS]
TCP_HOST = HOSTID[:PORT][/LIMIT][OPTIONS]
@@ -252,6 +263,7 @@
HOSTID = HOSTNAME | IPV4
OPTIONS = ,OPTION[OPTIONS]
OPTION = lzo
+ GLOBAL_OPTION = --randomize
.fi
.PP
Here are some individual examples of the syntax:
@@ -298,6 +310,9 @@
.TP
.B ,lzo
Enables LZO compression for this TCP or SSH host.
+.TP
+.B --randomize
+Randomize the host list before execution.
.PP
Here is an example demonstrating some possibilities:
.PP
--- distcc-2.14/src/hosts.c.dist2004-05-25 16:21:27.0 -0700
+++ distcc-2.14/src/hosts.c2004-05-28 10:41:25.0 -0700
@@ -4,6 +4,9 @@
*
* Copyright (C) 2002, 2003, 2004 by Martin Pool [EMAIL PROTECTED]
*
+ * dcc_randomize_host_list() and friends:
+ * Copyright (C) 2004 by Google (Josh Hyman [EMAIL PROTECTED])
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
@@ -36,6 +39,7 @@
*
DISTCC_HOSTS = HOSTSPEC ...
HOSTSPEC = LOCAL_HOST | SSH_HOST | TCP_HOST | OLDSTYLE_TCP_HOST
+| GLOBAL_OPTION
LOCAL_HOST = localhost[/LIMIT]
SSH_HOST = [EMAIL PROTECTED]/LIMIT][:COMMAND][OPTIONS]
TCP_HOST = HOSTID[:PORT][/LIMIT][OPTIONS]
@@ -43,6 +47,7 @@
HOSTID = HOSTNAME | IPV4
OPTIONS = ,OPTION[OPTIONS]
OPTION = lzo
+ GLOBAL_OPTION = --randomize
*
* Any amount of whitespace may be present between hosts.
*
@@ -89,6 +94,8 @@
#include errno.h
#include time.h
#include ctype.h
+#include sys/time.h
+#include sys/types.h
#include distcc.h
#include trace.h
@@ -100,6 +107,18 @@
const int dcc_default_port = DISTCC_DEFAULT_PORT;
+/***
+ * A simple container which would hold a host - rand int pair
+ ***/
+struct rand_container {
+struct dcc_hostdef *host;
+int rand;
+};
+
+int dcc_randomize_host_list(struct dcc_hostdef **host_list, int length);
+
+int dcc_compare_container(const void *a, const void *b);
+
#ifndef HAVE_STRNDUP
/**
@@ -348,7 +367,7 @@
struct dcc_hostdef **ret_list,
int *ret_nhosts)
{
-int ret;
+int ret, flag_randomize = 0;
struct dcc_hostdef *prev, *curr;
/* TODO: Check for '/' in places where it might cause trouble with
@@ -390,6 +409,13 @@
token_start = where;
token_len = strcspn(where, #\t\n\f);
+/* intercept keywords which are not actually hosts */
+if (!strncmp(token_start, --randomize, 11)) {
+
Re: [distcc] [PATCH] Adding host list randomization
Martin Pool wrote: Thank you for the patch. It looks OK to me, except that I am not sure if it should be an option specified in that way. I wonder if it should always be on? Or at least, if it should always be on until we have some kind of automatic weighting of faster machines. People are used to the first machine being hit first, aren't they? We figured making it optional would be less disruption. Whatever you think is best is ok with us. Rather than the qsort I think it is OK to just do a simple shuffle. Would that be less code? Can I just check Google is OK for this to be released under the GPL? We got approval from Urz Hoezle for this, so it's cool. - Dan __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] Adding host list randomization
On Fri, May 28, 2004 at 04:51:38PM -0700, Daniel Kegel wrote: Martin Pool wrote: Thank you for the patch. It looks OK to me, except that I am not sure if it should be an option specified in that way. I wonder if it should always be on? Or at least, if it should always be on until we have some kind of automatic weighting of faster machines. People are used to the first machine being hit first, aren't they? We figured making it optional would be less disruption. Whatever you think is best is ok with us. How about keeping the first machine still being hit first but then randomize the remaining hosts? Tim. signature.asc Description: Digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] Adding host list randomization
Tim Potter wrote: On Fri, May 28, 2004 at 04:51:38PM -0700, Daniel Kegel wrote: Martin Pool wrote: Thank you for the patch. It looks OK to me, except that I am not sure if it should be an option specified in that way. I wonder if it should always be on? Or at least, if it should always be on until we have some kind of automatic weighting of faster machines. People are used to the first machine being hit first, aren't they? We figured making it optional would be less disruption. Whatever you think is best is ok with us. How about keeping the first machine still being hit first but then randomize the remaining hosts? We could randomize all the hosts that show up after the --randomize keyword, but I'm not sure that degree of control is really needed. - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] patch: ignoring unresolvable host when constructing host list
[EMAIL PROTECTED] wrote: On 7 Apr 2004, Yannick Brosseau [EMAIL PROTECTED] wrote: [...] Hi, Thanks for suggestion. It looks like at the moment, if the hostname is not resolvable then it works OK, except that it always falls back to local compilation. Is that right? Exactly So would this be fixed by just trying the compilation on some other remote host? Yes, it is. And this is what I found when I wrote a patch to do this remote fallback. I can send my (somewhat ugly) patch to the list... Yannick :) signature.asc Description: OpenPGP digital signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] patch: ignoring unresolvable host when constructing host list
On 7 Apr 2004, Yannick Brosseau [EMAIL PROTECTED] wrote: Hi! I've just tried distcc and the results are really awesome. I'm sending a small patch which enhance the usabillity of distcc on my laptop where I use it at home and in the lab. The patch add code to check if a hostname can be resovlved before adding it to the hostlist. With this patch, I can set all the name of the machine which I use, and, since the name of my home machine and the ones in the lab are not the same, only the locals hosts are added to the usable hosts list. Not exactly the autodetect solution, but it solve the problem in my case. Hi, Thanks for suggestion. It looks like at the moment, if the hostname is not resolvable then it works OK, except that it always falls back to local compilation. Is that right? So would this be fixed by just trying the compilation on some other remote host? -- Martin pgp0.pgp Description: PGP signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] patch: -Wa,-xarch=v8 incorrectly not distributed
On 23 Jan 2004, Ben Scarlet [EMAIL PROTECTED] wrote:
The following patch makes the processing of arguments passed through to the
assembler slightly less conservative. When compiling 32-bit sparc code with
gcc-2.95.3, it is sometimes necessary to tweak assembler's notion of the
architecture to allow for the use of some fancier instructions.
I merged this:
Index: arg.c
===
RCS file: /data/cvs/distcc/src/arg.c,v
retrieving revision 1.103
diff -u -p -r1.103 arg.c
--- arg.c 29 Feb 2004 04:05:35 - 1.103
+++ arg.c 29 Feb 2004 04:28:45 -
@@ -172,15 +172,11 @@ int dcc_scan_args(char *argv[], char **i
rs_trace(%s implies -E (maybe) and must be local, a);
return EXIT_DISTCC_FAILED;
} else if (str_startswith(-Wa,, a)) {
-/* Options passed through to the assembler. The only one we
- * need to handle so far is -al=output, which directs the
- * listing to the named file and cannot be remote. Parsing
- * all the options would be complex since you can give several
- * comma-separated assembler options after -Wa, but looking
- * for '=' should be safe. */
-if (strchr(a, '=')) {
-rs_trace(%s needs to write out assembly listings and must be
local,
- a);
+/* Look for assembler options that would produce output
+ * files and must be local. */
+if (strstr(a, ,-a) || strstr(a, --MD)) {
+rs_trace(%s must be local,
+ a);
return EXIT_DISTCC_FAILED;
}
} else if (!strcmp(a, -S)) {
--
Martin
signature.asc
Description: Digital signature
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
RE: [distcc] patch: -Wa,-xarch=v8 incorrectly not distributed
On Sunday, January 25, 2004 6:46 PM, Martin Pool [mailto:[EMAIL PROTECTED]
wrote
On 23 Jan 2004, Ben Scarlet [EMAIL PROTECTED] wrote:
The following patch makes the processing of arguments passed through to
the
assembler slightly less conservative. When compiling 32-bit sparc code
with
gcc-2.95.3, it is sometimes necessary to tweak assembler's notion of the
architecture to allow for the use of some fancier instructions. (e.g. -
the
atomic operation instructions used in implementing reference counting in
some multithread-safe implementations of the c++ class std::string). One
way
to get the appropriate information to the compiler is to use the flag
-Wa,-xarch=v8. As of distcc version 2.12.1, this flag would erroneously
cause distcc to refuse to distribute a compilation, because that version
takes a very simplistic approach to detecting another assembler flag,
-Wa,-al=foo. The following patch improves the detection of the -al flag
just slightly, so as to let compiles without it but still with an '=' in
an
assembler flag get distributed.
The basic idea is OK, but I think the implementation is still too
likely to guess wrong if there happens to be another -al in the
option.
Since the gcc manual says the option is split at the commas then I
think we need to look for something like the regexp ,-al[=,]
I was aiming for minimal change, but if you'd prefer something more correct:
Reading the info page for gnu as, actually any -a...=foo flag would behave
similarly to -al=foo:
Here's a new patch:
diff -rc distcc-2.12.1/src/arg.c distcc-2.12.1-new/src/arg.c
*** distcc-2.12.1/src/arg.c Wed Oct 8 01:41:49 2003
--- distcc-2.12.1-new/src/arg.c Mon Jan 26 11:53:10 2004
***
*** 173,187
return EXIT_DISTCC_FAILED;
} else if (str_startswith(-Wa,, a)) {
/* Options passed through to the assembler. The only one
we
! * need to handle so far is -al=output, which directs the
! * listing to the named file and cannot be remote.
Parsing
! * all the options would be complex since you can give
several
! * comma-separated assembler options after -Wa, but
looking
! * for '=' should be safe. */
! if (strchr(a, '=')) {
! rs_trace(%s needs to write out assembly listings and
must be local,
! a);
! return EXIT_DISTCC_FAILED;
}
} else if (!strcmp(a, -S)) {
seen_opt_s = 1;
--- 173,197
return EXIT_DISTCC_FAILED;
} else if (str_startswith(-Wa,, a)) {
/* Options passed through to the assembler. The only one
we
! * need to handle so far is -a with a filename, which
directs the
! * listing to the named file and cannot be remote. */
! const char *scan = a;
!
! for(;;) {
! /* find the next -a flag. if none is found, quit
looking */
! if (!(scan = strstr(scan, ,-a))) break;
!
! /* find the start of the next argument or a filename,
!whichever comes first. If none is found, there's no
filename
!and nothing more to do, so quit looking */
! if (!(scan = strpbrk(scan + 3,,=))) break;
!
! /* found a filename, not another argument, so run
locally */
! if (*scan == '=') {
! rs_trace(%s needs to write out assembly listings
and must be local,
! a);
! return EXIT_DISTCC_FAILED;
! }
}
} else if (!strcmp(a, -S)) {
seen_opt_s = 1;
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
RE: [distcc] patch: -Wa,-xarch=v8 incorrectly not distributed
Please go ahead. I just wanted to contribute the fix. -Original Message- From: 'Martin Pool' [mailto:[EMAIL PROTECTED] Sent: Monday, January 26, 2004 6:22 PM To: Ben Scarlet Cc: '[EMAIL PROTECTED]' Subject: Re: [distcc] patch: -Wa,-xarch=v8 incorrectly not distributed On 26 Jan 2004, Ben Scarlet [EMAIL PROTECTED] wrote: The basic idea is OK, but I think the implementation is still too likely to guess wrong if there happens to be another -al in the option. Since the gcc manual says the option is split at the commas then I think we need to look for something like the regexp ,-al[=,] I was aiming for minimal change, but if you'd prefer something more correct: Reading the info page for gnu as, actually any -a...=foo flag would behave similarly to -al=foo: After reading the manual more it looks like there is also a --MD (sic) for gas, which would also need to be local. I can take it from here if you want. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] patch: -Wa,-xarch=v8 incorrectly not distributed
On 23 Jan 2004, Ben Scarlet [EMAIL PROTECTED] wrote:
The following patch makes the processing of arguments passed through to the
assembler slightly less conservative. When compiling 32-bit sparc code with
gcc-2.95.3, it is sometimes necessary to tweak assembler's notion of the
architecture to allow for the use of some fancier instructions. (e.g. - the
atomic operation instructions used in implementing reference counting in
some multithread-safe implementations of the c++ class std::string). One way
to get the appropriate information to the compiler is to use the flag
-Wa,-xarch=v8. As of distcc version 2.12.1, this flag would erroneously
cause distcc to refuse to distribute a compilation, because that version
takes a very simplistic approach to detecting another assembler flag,
-Wa,-al=foo. The following patch improves the detection of the -al flag
just slightly, so as to let compiles without it but still with an '=' in an
assembler flag get distributed.
The basic idea is OK, but I think the implementation is still too
likely to guess wrong if there happens to be another -al in the
option.
Since the gcc manual says the option is split at the commas then I
think we need to look for something like the regexp ,-al[=,]
--
diff -rc distcc-2.12.1/src/arg.c distcc-2.12.1-new/src/arg.c
*** distcc-2.12.1/src/arg.c 2003-10-08 01:41:49.0 -0400
--- distcc-2.12.1-new/src/arg.c 2004-01-23 20:48:46.0 -0500
***
*** 177,184
* listing to the named file and cannot be remote.
Parsing
* all the options would be complex since you can give
several
* comma-separated assembler options after -Wa, but
looking
! * for '=' should be safe. */
! if (strchr(a, '=')) {
rs_trace(%s needs to write out assembly listings and
must be local,
a);
return EXIT_DISTCC_FAILED;
--- 177,184
* listing to the named file and cannot be remote.
Parsing
* all the options would be complex since you can give
several
* comma-separated assembler options after -Wa, but
looking
! * for -al= should be safe. */
! if (strstr(a, -al=)) {
rs_trace(%s needs to write out assembly listings and
must be local,
a);
return EXIT_DISTCC_FAILED;
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
--
Martin
signature.asc
Description: Digital signature
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] setsid() in the right place
On 28 Dec 2003 Daniel Ritz [EMAIL PROTECTED] wrote:
hi
the call to setsid() must be after setgid()/setgroups() because if
it's before, those calls return with -1, errno gets EPERM (=the user
is not the super-user) this way distccd can actually start for me..
Do you mean setsid or setuid?
against distcc-2.12
rgds
-daniel
ps: please cc, i'm not subscribed
--- setuid.c-old 2003-12-28 21:51:36.0 +0100
+++ setuid.c 2003-12-28 21:52:03.0 +0100
@@ -108,11 +108,6 @@
* permanently discard privileges: both the real and effective
uid are* set. */
-if (setuid(uid)) {
-rs_log_error(setuid(%d) failed: %s, (int) uid,
strerror(errno));-return EXIT_SETUID_FAILED;
-}
-
if (setgid(gid)) {
rs_log_error(setgid(%d) failed: %s, (int) gid,
strerror(errno)); return EXIT_SETUID_FAILED;
@@ -128,6 +123,11 @@
}
#endif
+if (setuid(uid)) {
+rs_log_error(setuid(%d) failed: %s, (int) uid,
strerror(errno));+return EXIT_SETUID_FAILED;
+}
+
if (getuid() == 0 || geteuid() == 0) {
rs_log_crit(still have root privileges after trying to
discard them!); return EXIT_SETUID_FAILED;
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
--
Martin
linux.conf.au -- Adelaide, January 2004
pgp0.pgp
Description: PGP signature
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] [PATCH] setsid() in the right place
Daniel Ritz wrote: hi the call to setsid() must be after setgid()/setgroups() because if it's before, those calls return with -1, errno gets EPERM (=the user is not the super-user) this way distccd can actually start for me.. against distcc-2.12 Just an FYI, not sure what platform you're on but this patch fixes building on OSX too. -- Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/ gpg: 6401 D02A A35F 55E9 D7DD 71C5 52EF A366 D3F6 65FE Odelay IS a word, just look it up in the Becktionary! pgp0.pgp Description: PGP signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for --with-docdir in configure.ac and Makefile.in
On 27 Nov 2003, Harold L Hunt II [EMAIL PROTECTED] wrote: The attached patch adds a --with-docdir=path flag for the configure script; the default when --with-docdir is not specified remains unchanged. The patch has been build tested on Cygwin. Thanks, taken. By the way, I am working with John Morrison to package distcc for Cygwin. This patch allows us to consolidate our documentation in the directory that we specify. It was also marked as a TODO in configure.ac so it seems that this was wanted. Yes, it's fine. -- Martin linux.conf.au -- Adelaide, January 2004 __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for Sun's Workshop 6
Martin Pool wrote: On 23 Oct 2003, P. Christeas [EMAIL PROTECTED] wrote: Hi all and thanks for the great project I have CC: Sun WorkShop 6 update 1 C++ 5.2, which works with distcc. However, that compiler doesn't like '.ii' input files. I simply created the following patch, which works for me but could break some others. Can you find a test or add a '--with-sun-cc' option to control that? I'm glad you like distcc. This patch is, as you say, no good at the moment because it will break other compilers. I can't think of a satisfactory way to decide at runtime which compiler ought to be supported. If somebody can suggest one I might merge it. For the meantime I can ship this in patches/ so people with sun cc can apply it. In the meanwhile I discovered more problems with Sun's compiler: It has no --nostddefs option, which means that it tries to re-load the std headers even when it compiles the precompiled source. This leads sometimes to trouble. It also messes up the ild information sometimes. Anyway, this compiler should be used with extreme caution. __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch for Sun's Workshop 6
On 23 Oct 2003, P. Christeas [EMAIL PROTECTED] wrote: Hi all and thanks for the great project I have CC: Sun WorkShop 6 update 1 C++ 5.2, which works with distcc. However, that compiler doesn't like '.ii' input files. I simply created the following patch, which works for me but could break some others. Can you find a test or add a '--with-sun-cc' option to control that? I'm glad you like distcc. This patch is, as you say, no good at the moment because it will break other compilers. I can't think of a satisfactory way to decide at runtime which compiler ought to be supported. If somebody can suggest one I might merge it. For the meantime I can ship this in patches/ so people with sun cc can apply it. -- Martin linux.conf.au -- Adelaide, January 2004 __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
Re: [distcc] Patch to state.h
On 27 Sep 2003, Frerich Raabe [EMAIL PROTECTED] wrote: Moin, the attached patch makes it possible to build C++ programs which link against state.o and use functions declared in state.h by adding an extern C directive if necessary. It also adds an include guard to remove the burder from the client including state.h of keeping track of possible multiple inclusion problems. Thanks, taken. -- Martin pgp0.pgp Description: PGP signature __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] Patch to flush distccmon-text output
On 29 Jun 2003, Hamish Rodda [EMAIL PROTECTED] wrote: Content-Description: clearsigned data Hash: SHA1 Hi, I'm writing distcc monitoring support for kdevelop (http://www.kdevelop.org). I've found that using KDE's KProcess support, the output of distccmon-text has to be flushed to be received in a timely manner, as per the attached patch. Could you please apply this? Thanks for the report and for supporting distcc. I have made it call setvbuf(_IOLBF) instead -- that seems effective and a little cleaner. Please make an announcement here know when support goes into KDevelop. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [Ethereal-dev] Re: [distcc] [patch] distcc dissector for ethereal
the ssh dissector would also at a later time need to be enhanced to offer TCP desegmentation service to higher layer dissectors. in the same way as currently both TCP and SMBnamedpipes offer TCP desegmnetation service to DCERPC. the dcerpc dissector just asks for desegmentation of x bytes and it just happens regardless if the transport is tcp or smb. ok, TCP desegmentation is a misnomer, it should instead have been called ConnectionOrientedTransport desegmentation. - Original Message - From: Martin Pool Sent: Tuesday, March 11, 2003 6:55 PM Subject: Re: [Ethereal-dev] Re: [distcc] [patch] distcc dissector for ethereal On 11 Mar 2003, Joerg Mayer [EMAIL PROTECTED] wrote: Quite a few dissectors use TCP reassembly, e.g. packet-skinny.c, packet-tds.c. OK, thanks for telling me. AFAIK Ethereal currently cannot decrypt ssh because nobody has written the code to do so. Oh, I meant to say that I assumed one would force null encryption, though I suppose with a bit of help Ethereal could work out the session key and do the decryption itself. Having said all this, I have not yet had to look at a TCP dump to debug a distcc problem, because the protocol is very straightforward and there's only a single implementation. So I'm not quite sure why anyone would want a dissector, aside from just completeness in Ethereal or for hack value. After that, the discc dissector would need to be turned into an heuristic dissector (basically, it needs to look at a data packet and decide whether the data is distcc from the contents. Either a heuristic, or it could be guided by the user. -- Martin ___ Ethereal-dev mailing list [EMAIL PROTECTED] http://www.ethereal.com/mailman/listinfo/ethereal-dev __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [Ethereal-dev] Re: [distcc] [patch] distcc dissector for ethereal
On Tue, Mar 11, 2003 at 09:36:40PM +1100, Ronnie Sahlberg wrote: ok, TCP desegmentation is a misnomer, it should instead have been called ConnectionOrientedTransport desegmentation. Or, rather, ConnectionOrientedByteStreamTransport desegmentation. __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] [patch] distcc dissector for ethereal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Mar 2003 15:01, Martin Pool wrote: Please call it distcc distributed compiler, not the generic Distributed Compiler System, which seems to be the name of some older system. No idea where I got the name from. Fixed. Perhaps you could use the word magic a bit less? It's magic, but not that magic. :-) (Or is this special jargon for Ethereal?) Trust me, when I was trying to figure out how it worked, it was deep magic :-) The user should see a lot less magics now. When I did the tree below, I just dropped out displaying of the fixed elements. I think the dissection could reasonably be a bit shorter, and perhaps also split into a tree. Something like distcc request compilation request (version 1) arguments (19): gcc-3.2 -c foo.i -o foo.o -Wall argument 0: gcc-3.2 (7 bytes) ... input file (71232 bytes) I implemented a tree for requests - slightly different to the one above. Any comments, and also any suggestions for how it should look on the response side? Also, there might be a better way to show the file contents. I'll take a look at that too. Perhaps it would be good to explain fields more in terms of what they mean, rather than the tags used in the protocol. So, input file or preprocessed source rather than DOTI data, stderr messages rather than SERR, etc. Ethereal seems to get a pretty good balance here with other protocols. Good point. I've fixed some of it. You could decode the STAT result as a waitstatus. This is still to come. I need to think about presentation for this. In the summary line packet list I think the best thing to show for the request is the whole compiler command line; for the response probably the decoded status and perhaps the error messages. Response is a bit harder - I recall seeing packets for the response where the SOUT part was in a different packet to SERR. I still like the idea of labelling them with indicative contents. It's still pretty useful as it is; these suggestions are just in case you feel like polishing it a bit more. I am working on it, but I have a few things that are more important (GF birthday on Tues, horseriding on Wed, UUNITE and ANSP meetings on Thurs :) to take care of before the weekend, which is when I am likely to get back it it. An interim patch is attached - feedback welcome. Hopefully this can get through to distcc. Brad -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+bH0iW6pHgIdAuOMRArkgAKC63ar45ZYfq/xMCyoioB/8nCt68QCghiTL 23Y956pcZgjqonRQCnbFNB0= =lkW0 -END PGP SIGNATURE- diff -Naur -X ethereal-dontdiff clean/ethereal-0.9.9/Makefile.am ethereal-0.9.9-distcc/Makefile.am --- clean/ethereal-0.9.9/Makefile.am2003-01-24 10:50:12.0 +1100 +++ ethereal-0.9.9-distcc/Makefile.am 2003-03-06 21:06:50.0 +1100 @@ -170,6 +170,7 @@ packet-dec-bpdu.c \ packet-dhcpv6.c \ packet-diameter.c \ + packet-distcc.c \ packet-dlsw.c \ packet-dns.c \ packet-dsi.c \ diff -Naur -X ethereal-dontdiff clean/ethereal-0.9.9/Makefile.nmake ethereal-0.9.9-distcc/Makefile.nmake --- clean/ethereal-0.9.9/Makefile.nmake 2003-01-23 13:45:42.0 +1100 +++ ethereal-0.9.9-distcc/Makefile.nmake2003-03-06 21:06:50.0 +1100 @@ -113,6 +113,7 @@ packet-dec-bpdu.c \ packet-dhcpv6.c \ packet-diameter.c \ + packet-distcc.c \ packet-dlsw.c \ packet-dns.c \ packet-dsi.c \ diff -Naur -X ethereal-dontdiff clean/ethereal-0.9.9/packet-distcc.c ethereal-0.9.9-distcc/packet-distcc.c --- clean/ethereal-0.9.9/packet-distcc.c1970-01-01 10:00:00.0 +1000 +++ ethereal-0.9.9-distcc/packet-distcc.c 2003-03-10 22:48:01.0 +1100 @@ -0,0 +1,532 @@ +/* packet-distcc.c + * Routines for distcc dissection + * Copyright 2003, Brad Hards [EMAIL PROTECTED] + * + * $Id: README.developer,v 1.65 2002/11/09 08:37:00 guy Exp $ + * + * Ethereal - Network traffic analyzer + * By Gerald Combs [EMAIL PROTECTED] + * Copyright 1998 Gerald Combs + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version 2 + * of the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#ifdef HAVE_CONFIG_H +# include config.h +#endif + +#include stdio.h
Re: [distcc] [patch] distcc dissector for ethereal
On 10 Mar 2003, Brad Hards [EMAIL PROTECTED] wrote: You could decode the STAT result as a waitstatus. This is still to come. I need to think about presentation for this. Status: exited 0 (0x) Status: exited 1 (0x0100) Status: killed by signal 2 (0x0002) Look at sys/wait.h to find out how to decode it. In the summary line packet list I think the best thing to show for the request is the whole compiler command line; for the response probably the decoded status and perhaps the error messages. Response is a bit harder - I recall seeing packets for the response where the SOUT part was in a different packet to SERR. I still like the idea of labelling them with indicative contents. Yes, that could easily happen if there are many errors. It's quite possible that the argv could span multiple packets if they're long or if the MTU is short. You really need to reassemble the TCP stream and work from there. Any alignment with packet boundaries is purely accidental. I don't know how hard this is in Ethereal, if it can't be done then I guess we just need to put up with only decoding the first packet. I am working on it, but I have a few things that are more important (GF birthday on Tues, horseriding on Wed, UUNITE and ANSP meetings on Thurs :) to take care of before the weekend, which is when I am likely to get back it it. An interim patch is attached - feedback welcome. Hopefully this can get through to distcc. There's no rush. The other thing that would be very cool, but which is probably not very practical at the moment, is that it would be great if Ethereal could decode distcc-over-ssh. Ethereal would need to be able to be told to treat the contents of the ssh stdin/stdout streams as a distcc stream. I don't know if anyone is considering this kind of recursive dissector. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [Ethereal-dev] Re: [distcc] [patch] distcc dissector for ethereal
On Tue, Mar 11, 2003 at 12:56:34PM +1100, Martin Pool wrote: You really need to reassemble the TCP stream and work from there. Any alignment with packet boundaries is purely accidental. I don't know how hard this is in Ethereal, if it can't be done then I guess we just need to put up with only decoding the first packet. Quite a few dissectors use TCP reassembly, e.g. packet-skinny.c, packet-tds.c. The other thing that would be very cool, but which is probably not very practical at the moment, is that it would be great if Ethereal could decode distcc-over-ssh. Ethereal would need to be able to be told to treat the contents of the ssh stdin/stdout streams as a distcc stream. I don't know if anyone is considering this kind of recursive dissector. AFAIK Ethereal currently cannot decrypt ssh because nobody has written the code to do so. After that, the discc dissector would need to be turned into an heuristic dissector (basically, it needs to look at a data packet and decide whether the data is distcc from the contents. The infrastructure is already present. Ciao Jörg -- Joerg Mayer[EMAIL PROTECTED] We are stuck with technology when what we really want ist just stuff that works. Some say that should read Microsoft instead of technology. __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] [patch] distcc dissector for ethereal
On 9 Mar 2003, Brad Hards [EMAIL PROTECTED] wrote: Content-Description: clearsigned data Hash: SHA1 G'day, Attached is a patch (against 0.9.9) that adds support for distcc to Ethereal.. Please apply. Cool! .. but, um, it didn't seem to be attached. To get through the lists.samba.org sheep dip you may need to make sure its mime-type is set to text/plain. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] [patch] distcc dissector for ethereal
On 9 Mar 2003, Brad Hards [EMAIL PROTECTED] wrote: Hash: SHA1 On Sun, 9 Mar 2003 22:15, Martin Pool wrote: To get through the lists.samba.org sheep dip you may need to make sure its mime-type is set to text/plain. Grrr. My gui mailer (KMail) makes that a bit tricky. Anyway, it got through on the list that was most critical: http://www.ethereal.com/lists/ethereal-dev/200303/msg00112.html That seems to work well. A couple of matters of terminology: Please call it distcc distributed compiler, not the generic Distributed Compiler System, which seems to be the name of some older system. Perhaps you could use the word magic a bit less? It's magic, but not that magic. :-) (Or is this special jargon for Ethereal?) I think the dissection could reasonably be a bit shorter, and perhaps also split into a tree. Something like distcc request compilation request (version 1) arguments (19): gcc-3.2 -c foo.i -o foo.o -Wall argument 0: gcc-3.2 (7 bytes) ... input file (71232 bytes) Perhaps it would be good to explain fields more in terms of what they mean, rather than the tags used in the protocol. So, input file or preprocessed source rather than DOTI data, stderr messages rather than SERR, etc. Ethereal seems to get a pretty good balance here with other protocols. You could decode the STAT result as a waitstatus. In the summary line packet list I think the best thing to show for the request is the whole compiler command line; for the response probably the decoded status and perhaps the error messages. It's still pretty useful as it is; these suggestions are just in case you feel like polishing it a bit more. Thanks to all the Ethereal developers; it's a great tool. -- Martin __ distcc mailing listhttp://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] [PATCH] timeout for gethostbyname and connect
On Sun, 2002-10-27 at 23:11, Tim Potter wrote: I wrote a patch similar to this for Samba that didn't end up being applied. I used the __res_state structure described in /usr/include/resolv.h which allows you to set various properties of the resolver library, including timeout values. I thought I would suggest it in case people don't like using longjmp. Yeah, longjmp isn't pretty, but does __res_state work with other resolvers than glibc? (BSD, cygwin, etc.) /Jonas Jensen ___ distcc mailing list [EMAIL PROTECTED] http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
Re: [distcc] Patch for problem with distcc and ccache
On 14 Aug 2002, Chris Halls [EMAIL PROTECTED] wrote: - in dcc_preproc_exten, the extension '.ii' is not recognised. Ccache preprocesses source and passes input files to distcc with this extension. - in dcc_accept_job, the function dcc_preproc_exten can return NULL, and this is not handled properly, causing a crash later when trying to take the length of this string. Thanks, merged to CVS. -- Martin ___ distcc mailing list [EMAIL PROTECTED] http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
