HOT NEW SITE DemandADate-females earn $44 per date/up to $4000 a month

New way of online dating.  Free sign-up.  We are a growing company.  The only reliable way to date online. Sign up at http://www.demandadate.com ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Gnumach kern/strings.h

- Original Message - From: "Claudio Fontana" <[EMAIL PROTECTED]> To: "Barry deFreese" <[EMAIL PROTECTED]> Cc: Sent: Monday, November 06, 2006 10:14 PM Subject: Re: Gnumach kern/strings.h Hello, --- Barry deFreese <[EMAIL PROTECTED]> wrote: OK, trying to do more clean-up, I ran acro

Re: Gnumach kern/strings.h

Hello, --- Barry deFreese <[EMAIL PROTECTED]> wrote: > OK, trying to do more clean-up, I ran across > kern/strings.h which has > declarations for many of the string handling > functions which I had intended > on adding to my include/string.h. > > However, it only seems to be used in ddb/ and

Gnumach kern/strings.h

OK, trying to do more clean-up, I ran across kern/strings.h which has declarations for many of the string handling functions which I had intended on adding to my include/string.h. However, it only seems to be used in ddb/ and kern/ files. So my dilemna is do I leave stings.h alone and let the

Re: gnumach ChangeLog i386/i386/gdt.h i386/i386/pcb... [gnumach-1-branch]

Ok. The much better thing to do is to use GDT entries for the standard segments. I don't really know why Mach never did that in the first place. I think that i386_set_ldt was never used in Mach originally for adding some segments to the standard set, as we want to do for TLS. It was used only f

Re: gnumach ChangeLog i386/i386/gdt.h i386/i386/pcb... [gnumach-1-branch]

At Sun, 5 Nov 2006 19:59:44 -0800 (PST), Roland McGrath wrote: > > > #v+ > > 2006-01-26 Jeroen Dekkers <[EMAIL PROTECTED]> > > > > * i386/i386/locore.S (trap_push_segs): Switch fs and gs to kernel > > data segment too. > > (syscall_entry_2): Likewise. > > * i386

[bug #18217] glibc: `__libc_once'

Follow-up Comment #1, bug #18217 (project hurd): Is the applied usage of `old_once' in line 2029 supported? For the Mach / Hurd `__libc_once' functionality, we'd need to change that `if (old_once ...' to `if (old_once.done ...', I think. Do we need a common interface for that then, i.e. someth

[bug #18216] glibc: `struct stat' et al.

Follow-up Comment #1, bug #18216 (project hurd): Thomas Schwinge, le Mon 06 Nov 2006 16:30:31 +, a écrit : > ../sysdeps/posix/getaddrinfo.c: In function 'gaiconf_init': > ../sysdeps/posix/getaddrinfo.c:1798: error: 'struct stat64' has no member > named 'st_mtim' This is generic code, so I gu

Re: [bug #18216] glibc: `struct stat' et al.

Thomas Schwinge, le Mon 06 Nov 2006 16:30:31 +, a écrit : > ../sysdeps/posix/getaddrinfo.c: In function 'gaiconf_init': > ../sysdeps/posix/getaddrinfo.c:1798: error: 'struct stat64' has no member > named 'st_mtim' This is generic code, so I guess all stat64 structures need fixed the linuxish w

[bug #18218] glibc: `MSG_NOSIGNAL'

URL: Summary: glibc: `MSG_NOSIGNAL' Project: The GNU Hurd Submitted by: tschwinge Submitted on: Monday 11/06/06 at 17:39 Category: glibc Severity: 5 - Blocker

[bug #18217] glibc: `__libc_once'

URL: Summary: glibc: `__libc_once' Project: The GNU Hurd Submitted by: tschwinge Submitted on: Monday 11/06/06 at 17:36 Category: glibc Severity: 5 - Blocker

[bug #18216] glibc: `struct stat' et al.

URL: Summary: glibc: `struct stat' et al. Project: The GNU Hurd Submitted by: tschwinge Submitted on: Monday 11/06/06 at 17:30 Category: glibc Severity: 5 - Blocker

[bug #17646] glibc: ``-z relro''

Follow-up Comment #1, bug #17646 (project hurd): The hack of configuring glibc with ``libc_cv_z_relro=no'' to get an usable result will not work anymore with glibc trunk versions that are newer than 2006-10-28: .

[bug #17644] glibc: support for TLS

Follow-up Comment #5, bug #17644 (project hurd): Note that since 2006-10-27 tls has been enabled on the glibc trunk unconditionally: . ___ Reply to this item at:

[bug #17644] glibc: support for TLS

Follow-up Comment #4, bug #17644 (project hurd): Roland's plan was / is to first make `--without-__thread' builds work (i.e. both compile and runtime-wise) before attemping anything else. ___ Reply to this item at:

[bug #17644] glibc: support for TLS

Follow-up Comment #3, bug #17644 (project hurd): The `i386_set_gdt' and `i386_get_gdt' functions (which are --- if available --- used by the glibc tls code instead of the ldt ones) have been back-ported from OSKit Mach to GNU Mach and have been installed on gnumach-1-branch on 2006-11-05: