Re: glibc THREAD_GSCOPE and excessive gsync_wake ()

Samuel Thibault, le sam. 08 mai 2021 21:54:34 +0200, a ecrit: > Don't bother looking at the existing implementation, its roots dates > before we really had gsync working. > > Sergey Bugaev, le sam. 08 mai 2021 22:35:23 +0300, a ecrit: > > + do \ > > +{ \ > > + int count; \ > > + cou

Re: glibc THREAD_GSCOPE and excessive gsync_wake ()

Sergey Bugaev, le sam. 08 mai 2021 23:03:34 +0300, a ecrit: > On Sat, May 8, 2021 at 10:54 PM Samuel Thibault > wrote: > > Don't bother looking at the existing implementation, its roots dates > > before we really had gsync working. > > Interesting! > > As far as I can see, this implementation w

Re: glibc THREAD_GSCOPE and excessive gsync_wake ()

On Sat, May 8, 2021 at 10:54 PM Samuel Thibault wrote: > Don't bother looking at the existing implementation, its roots dates > before we really had gsync working. Interesting! As far as I can see, this implementation was committed (by you) in 2018; and gsync has not seen significant changes sin

Re: glibc THREAD_GSCOPE and excessive gsync_wake ()

Hello, Don't bother looking at the existing implementation, its roots dates before we really had gsync working. Sergey Bugaev, le sam. 08 mai 2021 22:35:23 +0300, a ecrit: > + do \ > +{ \ > + int count; \ > + count = atomic_exchange_and_add_rel (&GL(dl_thread_gscope_count), -1); >

Re: glibc compilation failed... malloc_usable_size: expected 7 but got 12

Paul Dufresne, le sam. 27 févr. 2021 14:04:01 -0500, a ecrit: > XFAIL: malloc/tst-malloc-usable-static XFAIL means we know that it fails, it's not a regression. > +-+ > | Encountered regressions that don't match expected fail

Re: glibc failing to build with undefined reference to `__vm_object_sync`

On Thu, Jan 30, 2020 at 07:39:00PM +0100, Samuel Thibault wrote: > Manolis Ragkousis, le jeu. 30 janv. 2020 19:25:38 +0100, a ecrit: > > I think we are using the latest tarball, but we will check. > > The latest release tarball? Not the Debian tarball? That's outdated > compared to the glibc relea

Re: glibc failing to build with undefined reference to `__vm_object_sync`

Manolis Ragkousis, le jeu. 30 janv. 2020 19:25:38 +0100, a ecrit: > I think we are using the latest tarball, but we will check. The latest release tarball? Not the Debian tarball? That's outdated compared to the glibc release tarball. Samuel

Re: glibc failing to build with undefined reference to `__vm_object_sync`

I think we are using the latest tarball, but we will check. On Thu, Jan 30, 2020, 19:18 Samuel Thibault wrote: > Efraim Flashner, le jeu. 30 janv. 2020 18:36:06 +0200, a ecrit: > > We ran into a bug during Guix Days pre-FOSDEM where we were unable to > > build a cross glibc for hurd. > > Are you

Re: glibc failing to build with undefined reference to `__vm_object_sync`

Efraim Flashner, le jeu. 30 janv. 2020 18:36:06 +0200, a ecrit: > We ran into a bug during Guix Days pre-FOSDEM where we were unable to > build a cross glibc for hurd. Are you using the master tree of gnumach? Samuel

Re: glibc failing to build with undefined reference to `__vm_object_sync`

The version of libc we are using is the upstream glibc 2.29. No debian patches are applied and we could not figure any that were related. On Thu, Jan 30, 2020, 17:36 Efraim Flashner wrote: > We ran into a bug during Guix Days pre-FOSDEM where we were unable to > build a cross glibc for hurd. > >

Re: Glibc port: commit clenup

Samuel Thibault, on jeu. 01 mars 2018 01:47:10 +0100, wrote: > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > Next branches I will work on are: > > > > - t/gscope > > I'm working on it. It's now commited. Samuel

Re: Glibc port: commit clenup

Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > Next branches I will work on are: > > - t/gscope I'm working on it. Samuel

Re: Glibc port: commit clenup

Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > - t/_dl_random I have commited it. Samuel

Re: Glibc port: commit clenup

Samuel Thibault, on mar. 20 févr. 2018 08:34:22 +0100, wrote: > Amos Jeffries, on mar. 20 févr. 2018 12:51:45 +1300, wrote: > > By "whole repository" do you mean the history needs rewriting for > > changelog automation, or just the working tree HEAD? > > We'd just import the HEAD :) (thus changel

Re: Glibc port: commit clenup

Amos Jeffries, on mar. 20 févr. 2018 12:51:45 +1300, wrote: > By "whole repository" do you mean the history needs rewriting for > changelog automation, or just the working tree HEAD? We'd just import the HEAD :) Samuel

Re: Glibc port: commit clenup

On 20/02/18 11:03, Samuel Thibault wrote: > Samuel Thibault, on lun. 19 févr. 2018 19:04:57 +0100, wrote: >> See the branches there, they already exist. >> >>> and ask you to commit upstream upstream? >> >> If it was a matter of committing, that'd be done already... See what I >> wrote on 18 Jan 20

Re: Glibc port: commit clenup

Samuel Thibault, on lun. 19 févr. 2018 19:04:57 +0100, wrote: > See the branches there, they already exist. > > > and ask you to commit upstream upstream? > > If it was a matter of committing, that'd be done already... See what I > wrote on 18 Jan 2018: > > « > Most of them don't have changelog,

Re: Glibc port: commit clenup

Svante Signell, on lun. 19 févr. 2018 18:51:12 +0100, wrote: > I've found the upstream upstream repo thanks. So, what is the > procedure, create a branch http://git.savannah.gnu.org/cgit/hurd/glibc. > git/ with one patch per debian patch See the branches there, they already exist. > and ask you t

Re: Glibc port: commit clenup

On Sun, 2018-02-18 at 00:44 +0100, Samuel Thibault wrote: > Svante Signell, on dim. 18 févr. 2018 00:40:57 +0100, wrote: > > On Sat, 2018-02-17 at 22:59 +0100, Samuel Thibault wrote: > > Maybe I can try to help out here after being AFK for a month. Where > > is > > upstream? > > You mean upstream

Re: Glibc port: commit clenup

Svante Signell, on dim. 18 févr. 2018 00:40:57 +0100, wrote: > On Sat, 2018-02-17 at 22:59 +0100, Samuel Thibault wrote: > > Hello, > > > > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > > Next branches I will work on are: > > > > > > - t/pagesize > > > > I have completel

Re: Glibc port: commit clenup

On 17 Feb 2018, at 23:40, Svante Signell wrote: > On Sat, 2018-02-17 at 22:59 +0100, Samuel Thibault wrote: >> Hello, >> >> Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: >>> Next branches I will work on are: >>> >>> - t/pagesize >> >> I have completely changed the fix there

Re: Glibc port: commit clenup

On Sat, 2018-02-17 at 22:59 +0100, Samuel Thibault wrote: > Hello, > > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > Next branches I will work on are: > > > > - t/pagesize > > I have completely changed the fix there, and commited upstream. Maybe I can try to help out he

Re: Glibc port: commit clenup

Hello, Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > Next branches I will work on are: > > - t/pagesize I have completely changed the fix there, and commited upstream. Samuel

Re: glibc / proc server interaction

On Mon, Feb 5, 2018 at 2:42 PM, Brent W. Baccala wrote: > On Mon, Feb 5, 2018 at 1:51 AM, Samuel Thibault > wrote: > >> Hello, >> >> Brent W. Baccala, on lun. 05 févr. 2018 00:35:17 -0500, wrote: >> > How do we know that the proc server knows about the task yet? It will >> get a >> > notificati

Re: glibc / proc server interaction

On Mon, Feb 5, 2018 at 1:51 AM, Samuel Thibault wrote: > Hello, > > Brent W. Baccala, on lun. 05 févr. 2018 00:35:17 -0500, wrote: > > How do we know that the proc server knows about the task yet? It will > get a > > notification from the kernel that a new task has been created, but how > do we

Re: glibc / proc server interaction

Hello, Brent W. Baccala, on lun. 05 févr. 2018 00:35:17 -0500, wrote: > How do we know that the proc server knows about the task yet?  It will get a > notification from the kernel that a new task has been created, but how do we > know that the notification has been processed yet? Isn't the notifi

Re: Glibc port: commit clenup

Samuel Thibault, on dim. 28 janv. 2018 19:43:24 +0100, wrote: > Samuel Thibault, on dim. 28 janv. 2018 18:59:55 +0100, wrote: > > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > > On Tue, 23 Jan 2018 21:45:59 +1300 > > > "Anatoly A. Kazantsev" wrote: > > > > > > > Currently

Re: Glibc port: commit clenup

Samuel Thibault, on dim. 28 janv. 2018 18:59:55 +0100, wrote: > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > On Tue, 23 Jan 2018 21:45:59 +1300 > > "Anatoly A. Kazantsev" wrote: > > > > > Currently working on the following branches: > > > > > > - t/fcntl-internal.h > >

Re: Glibc port: commit clenup

Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > On Tue, 23 Jan 2018 21:45:59 +1300 > "Anatoly A. Kazantsev" wrote: > > > Currently working on the following branches: > > > > - t/fcntl-internal.h > > - t/verify.h > > Next branches I will work on are: > > - t/pagesize > - t/

Re: Glibc port: commit clenup

Hello, Anatoly A. Kazantsev, on ven. 26 janv. 2018 21:28:31 +1300, wrote: > On Thu, 25 Jan 2018 09:47:04 +0100 > Samuel Thibault wrote: > > > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > > On Tue, 23 Jan 2018 21:45:59 +1300 > > > "Anatoly A. Kazantsev" wrote: > > > >

Re: Glibc port: commit clenup

On Thu, 25 Jan 2018 09:47:04 +0100 Samuel Thibault wrote: > Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > > On Tue, 23 Jan 2018 21:45:59 +1300 > > "Anatoly A. Kazantsev" wrote: > > > > > Currently working on the following branches: > > > > > > - t/fcntl-internal.h > > >

Re: Glibc port: commit clenup

Anatoly A. Kazantsev, on jeu. 25 janv. 2018 21:39:44 +1300, wrote: > On Tue, 23 Jan 2018 21:45:59 +1300 > "Anatoly A. Kazantsev" wrote: > > > Currently working on the following branches: > > > > - t/fcntl-internal.h > > - t/verify.h > > Next branches I will work on are: So do you think the two

Re: Glibc port: commit clenup

On Tue, 23 Jan 2018 21:45:59 +1300 "Anatoly A. Kazantsev" wrote: > Currently working on the following branches: > > - t/fcntl-internal.h > - t/verify.h Next branches I will work on are: - t/pagesize - t/_dl_random - t/gscope -- Regards, Anatoly

Re: Glibc port: commit clenup

On Sat, 20 Jan 2018 08:01:26 +1300 "Anatoly A. Kazantsev" wrote: > Hello, > > I've seen Upstreaming the glibc Hurd port thread and want to help with > the "boring" part of it. As the first step I'm going to go throw all > affected branches and fix/check for following topics: > > - Copyright not

Re: glibc-2.19-hurd+libpthread-20150515

Samuel Thibault, on Sat 31 Oct 2015 11:18:21 +0100, wrote: > Thomas Schwinge, on Fri 30 Oct 2015 21:55:42 +0100, wrote: > > In context of preparing a new glibc-hurd+libpthread snapshot, > > , > > is the procedure

Re: glibc-2.19-hurd+libpthread-20150515

Thomas Schwinge, on Fri 30 Oct 2015 21:55:42 +0100, wrote: > In context of preparing a new glibc-hurd+libpthread snapshot, > , > is the procedure to merge/cherry-pick the recent patches from > libpthread's master

Re: glibc-2.19-hurd+libpthread-20150515

Hi! In context of preparing a new glibc-hurd+libpthread snapshot, , is the procedure to merge/cherry-pick the recent patches from libpthread's master branch into its master-glibc branch? Could you please do and

Re: glibc build log (TLS-related issue)

Hello? Thomas Schwinge, le Wed 24 Jun 2015 10:08:13 +0200, a écrit : > On Tue, 23 Jun 2015 15:10:12 +0200, Samuel Thibault > wrote: > > Ok, the change which made my glibc work with static linking is: > > What's the failure mode? Well, just the default parameters actually. > (So that it can be

Re: glibc build log (TLS-related issue)

Ludovic Courtès, le Wed 24 Jun 2015 23:33:21 +0200, a écrit : > Manolis Ragkousis skribis: > > > On 24 June 2015 at 12:17, Thomas Schwinge wrote: > >>> and the same command with the tarballs sources end up with > >>> > >>> http://paste.lisp.org/display/150437 > >> > >> That looks like

Re: glibc build log (TLS-related issue)

Manolis Ragkousis skribis: > On 24 June 2015 at 12:17, Thomas Schwinge wrote: >>> and the same command with the tarballs sources end up with >>> >>> http://paste.lisp.org/display/150437 >> >> That looks like , >>

Re: glibc build log (TLS-related issue)

Hi again On 24 June 2015 at 12:17, Thomas Schwinge wrote: >> and the same command with the tarballs sources end up with >> >> http://paste.lisp.org/display/150437 > > That looks like , >

Re: glibc build log (TLS-related issue)

On 24 June 2015 at 12:17, Thomas Schwinge wrote: > That looks like something's going wrong with IFUNCs, > . What's your > exact configure command line? In particular, are you using > --disable-multi-arch (if I remember correctly)? No I am

Re: glibc build log (TLS-related issue)

Hi! On Wed, 24 Jun 2015 11:37:00 +0300, Manolis Ragkousis wrote: > On 23 June 2015 at 16:10, Samuel Thibault wrote: > > Ok, the change which made my glibc work with static linking is: > > > > --host=i586-gnu --build=i586-gnu > > > > I guess the default i686 variant introduces bugs. > > > > Try

Re: glibc build log (TLS-related issue)

On 23 June 2015 at 16:10, Samuel Thibault wrote: > Ok, the change which made my glibc work with static linking is: > > --host=i586-gnu --build=i586-gnu > > I guess the default i686 variant introduces bugs. > Trying to run "make lib" in darnassus using i586-gnu, with the debian sources, fails with

Re: glibc build log (TLS-related issue)

On 23 June 2015 at 16:10, Samuel Thibault wrote: > Ok, the change which made my glibc work with static linking is: > > --host=i586-gnu --build=i586-gnu > > I guess the default i686 variant introduces bugs. > Trying to run "make lib" in darnassus using i586-gnu, with the debian sources, fails with

Re: glibc build log (TLS-related issue)

Hi! On Tue, 23 Jun 2015 15:10:12 +0200, Samuel Thibault wrote: > Ok, the change which made my glibc work with static linking is: What's the failure mode? (So that it can be added to , or a new issue be filed.) > --host=i586-gnu --build=

Re: glibc build log (TLS-related issue)

Ok, the change which made my glibc work with static linking is: --host=i586-gnu --build=i586-gnu I guess the default i686 variant introduces bugs. Cc-ing the list to advertise this issue more. Samuel

Re: glibc-2.19-hurd+libpthread-20150515

Thomas Schwinge skribis: > Snapshot uploaded: , and corresponding > Git tags glibc-2.19-hurd+libpthread-20150515 pushed to the Savannah glibc > and libpthread repositories. Wonderful! Manolis should feel relieved now. ;-) I thought this was 2.21, but 2.19 shoul

Re: glibc-2.19-hurd+libpthread-20150515 (was: GSoC: Manolis to work on Guix port to GNU/Hurd)

Thomas Schwinge, le Fri 15 May 2015 16:46:43 +0200, a écrit : > On Thu, 7 May 2015 01:43:05 +0200, Samuel Thibault > wrote: > > Ludovic Courtès, le Wed 29 Apr 2015 21:40:13 +0200, a écrit : > > > The last missing bit upstream is a libc-for-hurd tarball. > > > > I have prepared a master-glibc bra

Re: glibc preparation patch for lockf support in Hurd

> Ok, so that will be something like this. Yes.

Re: glibc preparation patch for lockf support in Hurd

Roland McGrath, le Tue 19 Aug 2014 13:26:25 -0700, a écrit : > If we were starting from scratch, we'd use 64-bit types unconditionally. > But given that we already have off_t that is sometimes 32 bits, we should > be consistent with the other systems that have this distinction. That > means F_GETL

Re: glibc preparation patch for lockf support in Hurd

If we were starting from scratch, we'd use 64-bit types unconditionally. But given that we already have off_t that is sometimes 32 bits, we should be consistent with the other systems that have this distinction. That means F_GETLK64 should be a different value from F_GETLK in the ABI, and F_GETLK

Re: glibc preparation patch for lockf support in Hurd

Svante Signell, le Tue 19 Aug 2014 06:55:43 +0200, a écrit : > On Mon, 2014-08-18 at 23:39 +0200, Samuel Thibault wrote: > > Svante Signell, le Mon 18 Aug 2014 21:56:19 +0200, a écrit : > > > The reason this is needed is that the MIG generated RPC for hurd/glibc > > > currently does not support mix

Re: glibc preparation patch for lockf support in Hurd

On Mon, 2014-08-18 at 23:39 +0200, Samuel Thibault wrote: > Svante Signell, le Mon 18 Aug 2014 21:56:19 +0200, a écrit : > > The reason this is needed is that the MIG generated RPC for hurd/glibc > > currently does not support mixed 32 and 64 bit entries, > > Well, make it just always 64bit then.

Re: glibc preparation patch for lockf support in Hurd

Svante Signell, le Mon 18 Aug 2014 21:56:19 +0200, a écrit : > The reason this is needed is that the MIG generated RPC for hurd/glibc > currently does not support mixed 32 and 64 bit entries, Well, make it just always 64bit then. AIUI, this type is not used in any RPC at all yet, so this can't br

Re: Glibc building procedure error report.

Manolis Ragkousis, le Mon 07 Apr 2014 21:11:40 +, a écrit : > 2014-04-07 21:05 GMT+00:00 Samuel Thibault : > > Which version of libpthread is this? I don't have this in my copy of the > > tree. We got rid of these a long time ago. > > I am using the master branch, commit 3b391db91f70b21669514

Re: Glibc building procedure error report.

2014-04-07 21:05 GMT+00:00 Samuel Thibault : > Which version of libpthread is this? I don't have this in my copy of the > tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44

Re: Glibc building procedure error report.

Manolis Ragkousis, le Mon 07 Apr 2014 19:49:02 +, a écrit : > I am having some problems with building the libpthread addon. I get the error > > > ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: > > '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) Which versio

Re: Glibc building procedure error report.

I am having some problems with building the libpthread addon. I get the error > ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: > '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) > #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER <-- but I > can't s

Re: Glibc building procedure error report.

Manolis Ragkousis, le Thu 03 Apr 2014 23:14:49 +, a écrit : > > Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should > > have made the build system take the libpthread/sysdeps path into account > > (at least in the Debian package it does). > > It takes into account the libp

Re: Glibc building procedure error report.

>> However, it adds the start/stop symbols for the hurd_fork hooks, but not >> for the hurd_atfork hooks. Do we need something like this: I added the following lines to the shlib.lds part of Makerules so I can bypass the problem and it seems to work. +PROVIDE(__start__hurd_atfork

Re: Glibc building procedure error report.

Ludovic Courtès, le Sat 05 Apr 2014 15:36:17 +0200, a écrit : > Samuel Thibault skribis: > > > Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit : > >> > /../build/libc_pic.os: In function `__fork': > >> > /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to > >>

Re: Glibc building procedure error report.

Samuel Thibault skribis: > Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit : >> > /../build/libc_pic.os: In function `__fork': >> > /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to >> > `__start__hurd_atfork_prepare_hook' >> > /../gcc-cross-sans-libc-i686-

Re: Glibc building procedure error report.

> Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should > have made the build system take the libpthread/sysdeps path into account > (at least in the Debian package it does). It takes into account the libpthread/sysdeps tree path. I have pasted the corresponding output of the co

Re: Glibc building procedure error report.

Manolis Ragkousis, le Wed 02 Apr 2014 00:29:13 +, a écrit : > > /../build/libc_pic.os: In function `__fork': > > /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to > > `__start__hurd_atfork_prepare_hook' > > /../gcc-cross-sans-libc-i686-pc-gnu-4.8.2/libexec/gcc/i686-pc-

Re: Glibc building procedure error report.

As I said in the irc I managed to bypass the previous error by deleting #define _EXTERN_INLINE in signal/sigsetops.c I am now getting the error > /../build/libc_pic.os: In function `__fork': > /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to > `__start__hurd_atfork_prepa

Re: Glibc building procedure error report.

Manolis Ragkousis, le Mon 31 Mar 2014 22:35:08 +, a écrit : > I came across on some issues in the building procedure which are not solved in > the debian patches so I think I should report them, ask for comments on them > and be as solid as possible in my descriptions. > > First there are 2 de

Re: glibc: ELF_MACHINE_USER_ADDRESS_MASK, sysdeps/mach/hurd/dl-sysdep.c:fmh

> Hi Roland! Hi Thomas of the past! I'm culling old unanswered messages and I can't always tell which ones are still relevant. So ignore if not helpful. > Richard et moi, we wondered what ELF_MACHINE_USER_ADDRESS_MASK »Mask > identifying addresses reserved for the user program, where the dynami

Re: glibc t/tls (was: __thread errno)

Thomas Schwinge, le Thu 10 May 2012 12:46:42 +0800, a écrit : > Hi! > > On Thu, 10 May 2012 03:22:20 +0200, Samuel Thibault > wrote: > > Thomas Schwinge, le Thu 10 May 2012 09:17:33 +0800, a écrit : > > > Also, I plan to move some bits of the t/tls branch into t/tls-threadvar: > > > t/tls should

Re: glibc 'make install' fails when built apart from source tree - libc.info

Hi! On Sun, 20 Nov 2011 23:07:37 -0500, Stephen Gilles wrote: > On Sun, Nov 20, 2011 at 10:00:12AM +0100, Thomas Schwinge wrote: > > What does ``latest git version'' mean, excatly? > > Yes, sorry. I cloned git://git.sv.gnu.org/hurd/glibc.git and then checked > out origin/tschwinge > /Roger_Wh

Re: glibc 'make install' fails when built apart from source tree - libc.info

Hi! On Sat, 19 Nov 2011 13:54:50 -0500, Stephen Gilles wrote: > I was packaging glibc for the Arch Hurd yesterday, and I noticed that > the `make install' command aborts for the latest git version. What does ``latest git version'' mean, excatly? > After investigation, I believe that this was

Re: glibc: pagesize

> Linux has a EXEC_PAGESIZE macro, exposed in asm/param.h, typically > accessed via linux/param.h, then sys/param.h. This is now taken for > granted in glibc: It's not clear that EXEC_PAGESIZE means anything in particular in Linux. It's not used anywhere in the kernel itself. It also has ELF_EXE

Re: glibc CPUCLOCK_WHICH missing error for i686-pc-gnu

Hello, Allan McRae, le Tue 12 Jan 2010 22:17:50 +1000, a écrit : > Samuel Thibault wrote: > >Allan McRae, le Tue 12 Jan 2010 17:36:49 +1000, a écrit : > >>/home/allan/hurd/build/glibc-build/rt/librt_pic.a(clock_settime.os): In > >>function `clock_settime': > >>clock_settime.c:(.text+0x6f): undefi

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

> However there's nothing such for the calls manipulating the links of a > directory such as dir_mkdir(), dir_rmdir(), dir_unlink() and so on. > These apparently return EINVAL on an empty string (or at least my > /hurd/ext2fs does). Well, as we've been noting here, there is not really any sensical

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

On Sun, Jun 13, 2010 at 11:51 AM, Roland McGrath wrote: >> You mean directory_name_split("/") should return (, "") ? > > I do.  "This is the same as file_name_split, but ignores trailing slashes." > (...) Note that my patch changes both of them to return (, "."), and alters the documentation acco

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

On Sun, Jun 13, 2010 at 1:17 PM, Roland McGrath wrote: >> Is the empty string supposed to refer to the node itself somehow? > > It does.  To look up "." you need search (execute) permission on the > directory.  To look up "" it just has to actually be a directory port. > At least, that's the way I

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

Hi Roland, On Sun, Jun 13, 2010 at 10:53 AM, Roland McGrath wrote: > The . bit is bogus.  It should behave the same as file_name_split. You mean directory_name_split("/") should return (, "") ? This makes mkdir(), for instance, fail with EINVAL as well. Should it be handled on a case-by-case ba

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

> Note that my patch changes both of them to return (, "."), and > alters the documentation accordingly, though my post was unclear about > this (sorry). Oh, I didn't read it closely. Yeah, don't do that. > Is the empty string supposed to refer to the node itself somehow? It does. To look up "

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

> You mean directory_name_split("/") should return (, "") ? I do. "This is the same as file_name_split, but ignores trailing slashes." So directory_name_split ("") should return (crdir, "") too. End of story. > This makes mkdir(), for instance, fail with EINVAL as well. Well, what should it

Re: glibc: changing file_name_split()'s interface slightly to fix the "/" case

The . bit is bogus. It should behave the same as file_name_split. Thanks, Roland

Re: Glibc cross-compilation error

Hello Thomas! Thomas Schwinge writes: > On Wed, May 12, 2010 at 05:54:18PM +0200, Ludovic Courtès wrote: >> Cross-compilation of glibc 2.11.1 from the official release tarball >> fails for me: > > According to your failure log, you're building this in an Nix > environment. What exactly are you

Re: Glibc cross-compilation error

Hello! On Wed, May 12, 2010 at 05:54:18PM +0200, Ludovic Courtès wrote: > Cross-compilation of glibc 2.11.1 from the official release tarball > fails for me: According to your failure log, you're building this in an Nix environment. What exactly are you doing / working on? Building a whole syst

Re: Glibc cross-compilation error

Hello! On Wed, May 12, 2010 at 05:54:18PM +0200, Ludovic Courtès wrote: > Should I just give up building the “official” glibc and instead build > From hurd/glibc.git? Absolutely! (Or with the Debian patches, of course; but we're slowly converging.) Regards, Thomas signature.asc Description:

Re: glibc CPUCLOCK_WHICH missing error for i686-pc-gnu

Samuel Thibault wrote: Allan McRae, le Tue 12 Jan 2010 17:36:49 +1000, a écrit : /home/allan/hurd/build/glibc-build/rt/librt_pic.a(clock_settime.os): In function `clock_settime': clock_settime.c:(.text+0x6f): undefined reference to `CPUCLOCK_WHICH' This doesn't happen on Debian because Debian

Re: glibc CPUCLOCK_WHICH missing error for i686-pc-gnu

Allan McRae, le Tue 12 Jan 2010 17:36:49 +1000, a écrit : > /home/allan/hurd/build/glibc-build/rt/librt_pic.a(clock_settime.os): In > function `clock_settime': > clock_settime.c:(.text+0x6f): undefined reference to `CPUCLOCK_WHICH' This doesn't happen on Debian because Debian compiles only for i4

Re: glibc repository for Hurd matters on sourceware or Savannah?

As far as the mechanics go, it doesn't really matter. They are not significantly different to me for purposes of merging et al. It's up to the preferences of the people who would use it, i.e. you and Samuel. If you'd like to ask the sourceware robot for glibc group rights, I'll approve you. The

Re: glibc patches

Thomas Schwinge, le Sun 01 Mar 2009 11:01:11 +0100, a écrit : > > Nevertheless, for now, as I can't commit to the Debian glibc SVN repo, I > > send this to you, Samuel. Here are comments on some of the patches from > > [glibc]/trunk/debian/patches/hurd-i386/: > > Another one: as per a recent glib

Re: glibc patches

Hello, Thomas Schwinge, le Sat 28 Feb 2009 17:41:56 +0100, a écrit : > I think I would base this on the official glibc git mirror and publish > it again from the Hurd Savannah git repository Mmm, shouldn't we rather maintain a patch queue? That would make (re-)submission/review easier. > cvs-EC

Re: glibc patches

Hello! On Sat, Feb 28, 2009 at 05:41:56PM +0100, I wrote: > what about going a different route and really go ahead and > publish a glibc fork for Hurd use? I think I would base this on the > official glibc git mirror and publish it again from the Hurd Savannah git > repository -- a waste of disk

Re: glibc in Hurd

Hi, On Thu, Jun 05, 2008 at 01:16:12AM +0200, zhengda wrote: > I want to try the modified glibc. I compile it again, but I don't want > to install it in my system directly. I write a very simple test > program which only calls socket(). I want to compile the test program > with the modified glibc

Re: glibc in Hurd

Hi, Which version of gcc you using? Regards, - AG - Original Message From: zhengda <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Thursday, 5 June, 2008 4:46:12 AM Subject: glibc in Hurd Hi, I have some troubles with glibc. First, I'm not sure I get the right source code of glibc for

Re: glibc in Hurd

Hello, You should probably better just apt-get source glibc then ./debian/rules patch to get a buildable glibc. Samuel

Re: Glibc-2.5 with TLS cont'd

Hi, Barry deFreese, le Sun 04 Mar 2007 21:50:52 -0500, a écrit : > Thanks to Samuel I got past my errno problems but now I am getting this > error: > > /devel3/bdefreese/glibc-2.5/glibc-2.5/build/libc_pic.os: In function > `__pause_nocancel': > ../sysdeps/posix/pause.c:55: undefined reference t

Re: glibc category in the Hurd bug tracker

> People told me that this was not a too good idea, so I'd like to propose > something else instead: we use the glibc Bugzilla tracker for glibc stuff > and Roland adds some magic that makes every report with ``Component'' > equaling ``hurd'' get a cc to added. Roland, > something like that shoul

Re: glibc category in the Hurd bug tracker

Hello! On Fri, Sep 08, 2006 at 11:02:44AM +0200, I wrote: > I added a category field for glibc in the Hurd's bug tracker on Savannah, > . This allows for keeping the > Hurd-specific glibc bugs somewhere around where we actually can easily > pay attention

Re: glibc; introducing slashpackage-foreign

At Thu, 10 Mar 2005 12:04:28 +0100, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > > Are you suggesting something we > > should do, or what is this about? > > It only was a heads-up: I'm doing this and that and it's working for me. > I gave this introduction to show what I (and others) are doing, th

Re: glibc; introducing slashpackage-foreign

On Thu, Mar 10, 2005 at 02:35:29AM +0100, Marcus Brinkmann wrote: > This is all very well, but could you give us some context why you > posted this here in the first place? Alfred wanted to know which flags I used to configure glibc on GNU/Hurd. I told him. He asked why I'd have to use '--prefix=[

Re: glibc; introducing slashpackage-foreign

On Thu, Mar 10, 2005 at 01:17:32AM +0100, Alfred M. Szmidt wrote: >>I have to use './configure [...] --prefix=[...] >>--with-headers=[...]' because I have every package installed >>into its own hierarchy of >> >> Then your system is broken. > >That's an intere

Re: glibc; introducing slashpackage-foreign (was: GNU Mach panic)

At Wed, 9 Mar 2005 12:50:55 +0100, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > > [ Cc'ed to the slashpackage-foreign list > mailto:[EMAIL PROTECTED]>. ] > > [ Replied publically with Alfred's permission. ] This is all very well, but could you give us some context why you posted this here in t

Re: glibc; introducing slashpackage-foreign

Sighs, there is no dead end. This does exactly--from what I can see-- what stowfs/package will do, but in a less flexible, less Hurdish, less GNUish way, and in a less clean way. It is all less. Now, my understanding of this hack can be totally bogus, but in that case correct my understanding in

  1   2   >