* open_issues/libpthread.mdwn(cthreader->libpthread): remove it.
---
open_issues/libpthread.mdwn | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index f8d9e1f..1a06897 100644
--- a/open_iss
---
open_issues/libpthread.mdwn | 4 ++--
open_issues/libpthread/{t => }/fix_have_kernel_resources.mdwn | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename open_issues/libpthread/{t => }/fix_have_kernel_resources.mdwn (100%)
diff --git a/open_
Samuel Thibault skribis:
> Ludovic Courtès, le mar. 13 oct. 2020 15:41:37 +0200, a ecrit:
>> ‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which
>> assumes it is valid:
> [...]
>> I suppose that before calling ‘sigaddset’, it should check whether SIGNO
>> is within bounds, alon
Ludovic Courtès, le mar. 13 oct. 2020 15:41:37 +0200, a ecrit:
> ‘pthread_kill’ passes the signal number to ‘_hurd_raise_signal’, which
> assumes it is valid:
[...]
> I suppose that before calling ‘sigaddset’, it should check whether SIGNO
> is within bounds, along the lines of:
>
> if (signo <
Hi!
(Cc: bug-hurd.)
Jan Nieuwenhuizen skribis:
>>> #include
>>>
>>> int
>>> main (void)
>>> {
>>> if (!raise (-1))
>>> return 1;
>>>
>>> return 0;
>>> }
>>
>> I don’t know if it’s relevant here, but you should always use ‘-pthread’
>> both at compile time and link time:
>>
>> gcc
Amos Jeffries, on ven. 02 mars 2018 03:37:17 +1300, wrote:
> This patch updates the copyright blurbs in libpthread repository to
> match upstream glibc requested format.
>
> Specific changes are:
>
> * use -2018 for copyright dates
>
> * replace obsolete FSF addr
Amos Jeffries, on ven. 02 mars 2018 14:43:52 +1300, wrote:
> Is there anything else I should include or do to get this part of the
> updates applied and over with?
Well, you don't need to have something "complete" to submit it. Even
just fixing the copyright years can be a patch on its own, we don
Hello,
Amos Jeffries, on ven. 02 mars 2018 03:37:17 +1300, wrote:
> This patch updates the copyright blurbs in libpthread repository to
> match upstream glibc requested format.
Mmm, there was no patch?
Samuel
On 02/03/18 03:45, Samuel Thibault wrote:
> Amos Jeffries, on ven. 02 mars 2018 03:37:17 +1300, wrote:
>> Joseph also asked in the other thread for "Contributed by" lines not to
>> be added in new files. There are a few in this code, but the files
>> creation are usually very old - late 1990's earl
eep them.
For the Arzille contribution, this is really new. We however need to be
sure to add her name to the ChangeLog, as well as other contributors of
the libpthread repo. I'd say replace the existing ChangeLog with the
list of names (in ChangeLog format) that we will put in the ChangeLog
when pushing the whole tree to glibc master.
Samuel
This patch updates the copyright blurbs in libpthread repository to
match upstream glibc requested format.
Specific changes are:
* use -2018 for copyright dates
* replace obsolete FSF address with current gnu.org URL reference from
glibc.
Joseph also asked in the other thread for
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,
> > <http://news.gmane.org/find-root.php?message_id=%3C20151012215601.GS2989%40var.ho
Thomas Schwinge, on Fri 30 Oct 2015 21:55:42 +0100, wrote:
> In context of preparing a new glibc-hurd+libpthread snapshot,
> <http://news.gmane.org/find-root.php?message_id=%3C20151012215601.GS2989%40var.home%3E>,
> is the procedure to merge/cherry-pick the recent patches from
Hi!
In context of preparing a new glibc-hurd+libpthread snapshot,
<http://news.gmane.org/find-root.php?message_id=%3C20151012215601.GS2989%40var.home%3E>,
is the procedure to merge/cherry-pick the recent patches from
libpthread's master branch into its master-glibc branch? Could yo
Thomas Schwinge skribis:
> Snapshot uploaded: <http://alpha.gnu.org/gnu/hurd/>, 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
t; I have prepared a master-glibc branch in the libpthread repo.
>
> Thanks! However, shouldn't that just be libpthread's master branch,
> nowadays? (Assuming the idea still is that libpthread is only to be
> built as part of glibc's build process?)
With that assumpti
Hi!
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 branch in the libpthread repo.
Thanks! However, shou
David Michael, le Mon 11 May 2015 12:07:33 -0400, a écrit :
> Can this be applied in the glibc branches?
Yes, I have done so.
Samuel
Samuel Thibault, le Thu 14 May 2015 02:16:25 +0200, a écrit :
> David Michael, le Mon 11 May 2015 12:07:33 -0400, a écrit :
> > Can this be applied in the glibc branches?
>
> Yes, I have done so.
I forgot to say: thanks for the patch!
Samuel
* Makefile (install-lib): New variable.
(install-lib-ldscripts): Remove variable.
($(inst_libdir)/libpthread.so): Remove rule.
---
Hi,
Thanks for all the recent glibc/libpthread updates. They greatly
simplify things. This is the only other libpthread change I've been
carrying locally
Samuel Thibault skribis:
> Ludovic Courtès, le Fri 30 May 2014 17:29:27 +0200, a écrit :
>> Manolis Ragkousis skribis:
>>
>> > I had to put one more line after AC_NO_EXECUTABLES, otherwise it would
>> > fail with
>> >>> syntax error near unexpected token `fi'.
>>
>> AC_NO_EXECUTABLES expands
Ludovic Courtès, le Fri 30 May 2014 17:29:27 +0200, a écrit :
> Manolis Ragkousis skribis:
>
> > I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail
> > with
> >>> syntax error near unexpected token `fi'.
>
> AC_NO_EXECUTABLES expands to nothing, hence the error. It see
Manolis Ragkousis skribis:
> I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail
> with
>>> syntax error near unexpected token `fi'.
AC_NO_EXECUTABLES expands to nothing, hence the error. It seems that we
don’t even have to use it in a conditional.
Ludo’.
Manolis Ragkousis, le Thu 29 May 2014 21:01:02 +, a écrit :
> Works like a charm.
Good, applied, thanks!
Samuel
> Could you try
>
> AC_MSG_WARN("cross-compiling, disabling linking")
>
> ?
diff --git a/configure.ac b/configure.ac
index ecabfdf..7ede6db 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,13 @@ AC_PROG_INSTALL
AC_PROG_AWK
AC_PROG_SED
+if test "x$cross_compiling" = "xyes"; then
+ # I
Manolis Ragkousis, le Wed 28 May 2014 18:47:57 +, a écrit :
> I sent the mail by mistake incomplete, I am sorry.
>
> > Could you try this patch for the Hurd’s configure.in?
>
> I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail
> with
> >> syntax error near unexpecte
I sent the mail by mistake incomplete, I am sorry.
> Could you try this patch for the Hurd’s configure.in?
I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with
>> syntax error near unexpected token `fi'.
Other than that it works as expected for me.
diff --git a/config
> Could you try this patch for the Hurd’s configure.in?
I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with
>> syntax error near unexpected token `fi'.
Manolis Ragkousis skribis:
> 0:00 Ludovic Courtès :
>>
>> Could you show what test tries to compile a program? (Send config.log.)
>>
>
> Here it is
Thanks.
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It w
0:00 Ludovic Courtès :
>
> Could you show what test tries to compile a program? (Send config.log.)
>
Here it is
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by GNU Hurd configure 0.5, which was
genera
Manolis Ragkousis skribis:
> When libpthread tries to link against "libihash.so" I get the error:
>
> /lib/libihash.so: file not recognized: File format not recognized.
>
> This happens because libihash was built using the native compiler.
> So I changed the flag in l
Manolis Ragkousis, le Fri 11 Apr 2014 00:03:40 +, a écrit :
> When libpthread tries to link against "libihash.so" I get the error:
>
> /lib/libihash.so: file not recognized: File format not recognized.
>
> This happens because libihash was built using the native com
When libpthread tries to link against "libihash.so" I get the error:
/lib/libihash.so: file not recognized: File format not recognized.
This happens because libihash was built using the native compiler.
So I changed the flag in libihash configure to "--host" so it will us
Manolis Ragkousis skribis:
> In the debian package I saw there are 2 patches that add this.
>
>> +libc_add_on_canonical=libpthread
>> +libc_add_on_subdirs=.
>
> How does this change the configure process?
Libc’s top-level configure file expects these two variables t
In the debian package I saw there are 2 patches that add this.
> +libc_add_on_canonical=libpthread
> +libc_add_on_subdirs=.
How does this change the configure process?
As Ludovic wrote
> Actually libc's configure doesn't use the normal AC_CONFIG_SUBDIRS
> mechanism, and instead runs add-on configure scripts by itself, without
> arguments AFAICS.
The part responsible for this is in the attached file and specifically the
part:
> libc_add_on_frag=$libc_add
> (This is libpthread's config.log, right?)
It's the config.log generated in the build folder of glibc.
There is no config.log file generated from libpthread.
Manolis
>
starting phase `configure'
source directory:
"/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.dr
(Hurd people: this is about a configure error when cross-compiling glibc
with libpthread as an add-on.)
Manolis Ragkousis skribis:
> when building glibc with libpthread as an addon I get this
>
> configure: running configure fragment for add-on libpthread
> configure: WARNING: yo
Pino Toscano, le Sun 30 Sep 2012 23:53:46 +0200, a écrit :
> The following two patches allow to
> a) make use of the "pthread" glibc sysdep, which provides implementation
>for some functions using pthreads (e.g. aio stuff)
> b) hook the libpthread version inside gl
Hi!
On Wed, 28 Nov 2012 03:54:48 +0100, Samuel Thibault
wrote:
> At last that work is out!
>
> I've pushed the patchqueue from Richard to upstreams [...]
Great, and many thanks also from my side to everyone involved: Vicente
who originally started the cthreads to pthreads conversion project a
Barry deFreese, le Tue 27 Nov 2012 22:12:36 -0500, a écrit :
> w000t!! Finally, nice job folks!!
Nice job Barry, for a start :)
Samuel
w000t!! Finally, nice job folks!!
(Sorry to have disappeared again... :-()
Barry
On 11/27/2012 9:54 PM, Samuel Thibault wrote:
> Hello,
>
> At last that work is out!
>
> I've pushed the patchqueue from Richard to upstreams, built test debian
> packages on
>
> deb http://people.debian.org/~s
Hello,
At last that work is out!
I've pushed the patchqueue from Richard to upstreams, built test debian
packages on
deb http://people.debian.org/~sthibault/hurd-i386/tmp ./
I hope to have not forgotten anything for the dependencies: the new hurd
depends on the new libc0.3, and breaks the old
Applied, thanks.
Samuel
Hi,
since 2.16, glibc dropped support for any binary format other than ELF;
the removal of the 'elf' variable causes libpthread.so to not link,
since ld.so is not passed to the linking line. The attached patch
defines elf to yes if not defined, allowing to keep compatibility also
with glibc <
Hi,
The following two patches allow to
a) make use of the "pthread" glibc sysdep, which provides implementation
for some functions using pthreads (e.g. aio stuff)
b) hook the libpthread version inside glibc, so it is properly returned
by confstr.
--
Pino To
Pino Toscano, le Sat 15 Sep 2012 19:27:18 +0200, a écrit :
> it seems that in some occasions (i.e on malloc failure) pthread_create
> can return ENOMEM, which is not a valid POSIX error number.
> Attached there is a patch for libpthread to normalize ENOMEM to EAGAIN.
Applied, thanks
Samuel
Hi,
it seems that in some occasions (i.e on malloc failure) pthread_create
can return ENOMEM, which is not a valid POSIX error number.
Attached there is a patch for libpthread to normalize ENOMEM to EAGAIN.
Thanks,
--
Pino Toscano
From 2ee7e1e143784452ef325a0c80c106e972a3ffdc Mon Sep 17 00:00
also the idea I got from reading the code. The work around I'm
currently using is to have a weak __pthread_stack_default_size symbol
in libpthread. If defined at runtime, this size will be used instead
of the 2 MiB default. For Hurd servers, this symbol is defined in
libports/manage-multithread.
The alignment issue is for threadvars: as long as we have them, we
need the stack to be aligned, and some constant size. Fortunately,
threadvars are to be dropped, but it's still not complete yet.
Samuel
At Mon, 13 Aug 2012 11:54:17 +0200,
Richard Braun wrote:
> In addition, here you only mention the recylcing problem, not the
> threadvar alignment problem. Or is there no such problem ?
It's been a decade since I wrote the code, I've fotten a bit. I don't
know offhand if there is a problem and I
On Mon, Aug 13, 2012 at 11:38:02AM +0200, Neal H. Walfield wrote:
> The problem has to do with the recycling of stacks. The problem is
> that a thread cannot easily free its own stack when it exits. If it
> frees its stack, it can't free it's kernel thread and vice versa. To
> work around this,
st add _np at the end of the
> > function name.
>
> Sorry to disturb you again, but I found something surprising when using
> libpthread. It seems the stack size can't be changed with
> pthread_attr_setstacksize. There is a comment about alignment but I'm
> not sure I
olzheimer/pthread/pt-join.c:44
#6 0x08048c42 in main (argc=1, argv=0x15ffbb8) at test-6.c:71
For the moment, I'm just reverting the patch locally, too, as I want to
get some other libpthread work finished first.
Grüße,
Thomas
pgpWb1DjCQzTG.pgp
Description: PGP signature
At Fri, 10 Aug 2012 09:15:01 +0200,
Neal H. Walfield wrote:
> > Why does Viengoos in
> > sysdeps/viengoos/pt-thread-halt.c:__pthread_thread_halt have to do
> > different things depending on whether »thread == _pthread_self« or not?
> > I'm assuming that on Mach, we can just always do thread_suspend
Hi, Thomas,
At Fri, 10 Aug 2012 01:17:30 +0200,
Thomas Schwinge wrote:
> libpthread applies some caching of data structures
> (cf. __pthread_free_threads; »state == PTHREAD_TERMINATED«) which after a
> thread has exited can be re-used for a new one.
> ...
> Is this an optimizatio
Hi!
libpthread applies some caching of data structures
(cf. __pthread_free_threads; »state == PTHREAD_TERMINATED«) which after a
thread has exited can be re-used for a new one. This also applies to
kernel resources (cf. have_kernel_resources), that may also be re-used.
That is, on Mach, instead
At Tue, 7 Aug 2012 23:55:12 +0200,
Thomas Schwinge wrote:
> > It's generic code. At least glibc keeps generic code around, if I
> > recall correctly. Further, one of the very nice things about this
> > libpthread is that it is really easy to integrate into a new OS (or
&
> > > > > to remove both the L4 and the Viengoos ports or just the L4 port?
> > > >
> > > > I only intend to clean up libpthread's master branch (that is, remove
> > > > its
> > > > old L4 port).
> > >
> > > Ok
are also used by the Viengoos port. Are you suggesting
> > > > to remove both the L4 and the Viengoos ports or just the L4 port?
> > >
> > > I only intend to clean up libpthread's master branch (that is, remove its
> > > old L4 port).
> >
> >
master branch (that is, remove its
> > old L4 port).
>
> Ok. I still think that the above files are generic and not L4
> specific.
Does that mean you'd like to keep them available in the master branch,
though unused there? (In principle I'm fine either way, but have a
tendenc
bit more
> > advanced) and provides everything that master-viengoos does and more.
> > I unfortunately never got around to issuing the right git commands to
> > make turn it into the master branch.
>
> Note that I'm talking about branches of the hurd/libpthread.git
>
Hi!
On Sat, 04 Aug 2012 13:02:10 +0200, "Neal H. Walfield"
wrote:
> At Sat, 4 Aug 2012 12:34:28 +0200,
> Thomas Schwinge wrote:
> > There has been a libpthread port for Hurd on L4 use, which is dead, and
> > has been superseded by a Viengoos port, which has its own b
At Sat, 4 Aug 2012 12:34:28 +0200,
Thomas Schwinge wrote:
> There has been a libpthread port for Hurd on L4 use, which is dead, and
> has been superseded by a Viengoos port, which has its own branches:
For what it is worth, the L4 port works directly on L4: no further OS
personality supp
Hi!
I'm currently having a look at a few pending libpthread issues. Before
getting to these, I'd first like to propose some cleanup. I have not yet
tested these changes, but will do so once they're generally approved.
There has been a libpthread port for Hurd on L4 use, which i
Thomas DiModica, le Mon 30 Jul 2012 16:17:20 -0700, a écrit :
> The fix seems to be to change the line to read:
> inst_libdir = $(libdir)
Indeed, commited, thanks!
Samuel
hurd, not as part of libc.
The fix seems to be to change the line to read:
inst_libdir = $(libdir)
Mr. Walfield,
Repeating a conversation you had with Herr Schwinge:
do you want a reply on the libpthread one inline?
the short answer is: yes, that's a bug
unfortunately, your fix is not enough
The only thing I've seen wrong with this branch so far:
If we fail to allocate a kernel thread while creating the thread in
pthread_create(), the wakeup port doesn't get freed.
This patch just ensures that the port isn't leaked upon failure.
TD
PthreadPatch.diff
Description: Binary data
Samuel Thibault, le Sun 22 Apr 2012 03:17:56 +0200, a écrit :
> Pino Toscano, le Sun 22 Apr 2012 00:58:29 +0200, a écrit :
> > The only bit I'm not too sure is the linking to rt in case libpthread is
> > compiled a glibc addon (as result of the changes by Samuel an hour ago).
Pino Toscano, le Sun 22 Apr 2012 00:58:29 +0200, a écrit :
> The only bit I'm not too sure is the linking to rt in case libpthread is
> compiled a glibc addon (as result of the changes by Samuel an hour ago).
Oops, actually there is a problem: librt already links against
libpthrea
Applied, thanks!
Samuel
Hi,
attached there are few commits for libpthread which allow to use
monotonic clock, if present, for pthread conditions.
Currently they should have "no effect", since there's no monotonic
clock, yet, but will allow to automatically use it once available,
detecting it at runtime
I haven't looked at this change in detail, but it sounds sane and if
Samuel says its okay, that's good enough for me.
Neal
Thomas Schwinge, le Sat 05 Nov 2011 01:24:05 +0100, a écrit :
> I found this while reviewing Pino's libpthread key-reuse patch. Correct?
Yes, please push.
Samuel
x27;s libpthread key-reuse patch. Correct?
Grüße,
Thomas
---
sysdeps/hurd/pt-destroy-specific.c |2 +-
tests/Makefile |2 +-
tests/test-__pthread_destroy_specific-skip.c | 83 ++
3 files changed, 85 insertions(+), 2 dele
Hi Thomas,
Thomas Schwinge skribis:
> Here is what I'm doing in cross-gnu; simply install the libpthread
> headers before building glibc:
> <http://git.savannah.gnu.org/cgit/hurd/incubator.git/commit/?h=cross-gnu/master&id=2114e5595b9f6f94efcf66d405003be31b5b8eed>.
Ind
Hi!
On Mon, 31 Oct 2011 18:11:09 +0100, l...@gnu.org (Ludovic
=?iso-8859-1?Q?Court=E8s?=) wrote:
> It used to be that Savannah’s libc could be compiled without libpthread,
> because none of the source files would explicitly include .
>
> This is no longer the case with the recent c
Hello,
It used to be that Savannah’s libc could be compiled without libpthread,
because none of the source files would explicitly include .
This is no longer the case with the recent changes where the new
nss_files/files-init.c includes (so it can use struct
traced_file), which includes and
This patch against Hurd's libpthread "activates" global signal dispositions for
newly created threads, if glibc supports it.
I'll submit a pkg-hurd version (which also updates libpthread_sigmask.patch)
to debian-hurd right away.
Jeremie Koenig (1):
Mark new threads as glo
Hello!
On Tue, Jun 23, 2009 at 12:05:42AM +0200, I wrote:
> On Sun, Apr 12, 2009 at 05:32:12PM +0200, I wrote:
> > When linking the pthread tests against a libpthread built (with Samuel's
> > TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
> >
ago, I published master-tls_support containing
> Samuel's TLS support for libpthread. How are we going to proceed with
> that one?
I believe the years-long test is OK :) It's mostly up to somebody with
glibc commit access to push the glibc part there.
Samuel
Hello!
On Sun, Apr 12, 2009 at 05:32:12PM +0200, I wrote:
> When linking the pthread tests against a libpthread built (with Samuel's
> TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
> matter) I always get this:
>
> $ ./test-1
> test-1: ../../
Thomas Schwinge, le Sun 12 Apr 2009 17:32:12 +0200, a écrit :
>__mach_port_destroy (__mach_task_self (),
> thread->wakeupmsg.msgh_remote_port);
> +
> + thread->have_kernel_resources = 0;
> }
Mmm, I do not like setting have_kernel_resources being set to 0 in
pthread_threa
Hello!
On Sun, Apr 12, 2009 at 08:37:40PM +0200, Samuel Thibault wrote:
> Thomas Schwinge, le Sun 12 Apr 2009 17:32:12 +0200, a écrit :
> > PPS: While digging through the libpthread code I wondered whether for the
> > Hurd servers cthreads to pthread migration PTHREAD_TH
Thomas Schwinge, le Sun 12 Apr 2009 17:32:12 +0200, a écrit :
> PPS: While digging through the libpthread code I wondered whether for the
> Hurd servers cthreads to pthread migration PTHREAD_THREADS_MAX being
> defined to 64 might be too small for some heavily multi-threaded Hurd
> ser
Hello!
When linking the pthread tests against a libpthread built (with Samuel's
TLS patches) from CVS HEAD (or any of the Viengoos branches, for that
matter) I always get this:
$ ./test-1
test-1: ../../HEAD/libpthread/sysdeps/mach/hurd/i386/pt-setup.c:103:
__pthread_setup: Unexp
Neal H. Walfield, le Sat 27 Sep 2008 09:15:25 +0200, a écrit :
> At Sat, 27 Sep 2008 00:55:31 +0200,
> Samuel Thibault wrote:
> > There seems to be at least two issues:
> >
> > if (_pthread_self ())
> >
> > doesn't actually make sense since _pthread_self() already asserts(self),
> > so the assert
ue for the Hurd on Mach implementation of _pthread_self,
however, this is not the case for the Viengoos implementation.
> in the case of a normal mutex, now libpthread checks the owner when
> NDEBUG is not defined. The problem is that libc uses mutexes that have
> to be compatible with cthread mutexe
Hello,
There seems to be at least two issues:
if (_pthread_self ())
doesn't actually make sense since _pthread_self() already asserts(self),
so the assertion will be triggered inside it.
in the case of a normal mutex, now libpthread checks the owner when
NDEBUG is not defined. The probl
Hi,
if you compile a trivial program and link it to libpthread from current
CVS, it hangs.
I bisected it mostly to the following change:
2008-06-22 Neal H. Walfield <[EMAIL PROTECTED]>
* sysdeps/generic/pt-mutex-timedlock.c
(__pthread_mutex_timedlock_internal) [! NDEBUG
Hello!
On Fri, Jul 18, 2008 at 03:30:43PM +0100, Samuel Thibault wrote:
> Samuel Thibault, le Fri 18 Jul 2008 15:26:01 +0100, a écrit :
> > Isn't it applied already?
>
> Ah, the Makefile part was not indeed, done now.
I was just about to commit exactly the same change... ;-)
Regards,
Thomas
Samuel Thibault, le Fri 18 Jul 2008 15:26:01 +0100, a écrit :
> Thomas Schwinge, le Fri 18 Jul 2008 16:18:45 +0200, a écrit :
> > Hurd CVS HEAD is currently broken in libpthread: ``error:
> > pthread/pthreadtypes.h: No such file or directory''. I can see a number
> &g
Thomas Schwinge, le Fri 18 Jul 2008 16:18:45 +0200, a écrit :
> Hurd CVS HEAD is currently broken in libpthread: ``error:
> pthread/pthreadtypes.h: No such file or directory''. I can see a number
> of libpthread patches in the Debian hurd SVN. And even spotted the one
> w
Hello!
Hurd CVS HEAD is currently broken in libpthread: ``error:
pthread/pthreadtypes.h: No such file or directory''. I can see a number
of libpthread patches in the Debian hurd SVN. And even spotted the one
which has the potential to fix this. But is it ``safe'' to apply/
when I run it, I get error:
> > pytest:
> > /build/mbanck/hurd-20080607/build-tree/hurd/libpthread/pthread/pt-self.c:28:
> > pthread_self: Assertion `__pthread_threads' failed.
>
> That's because you have a conflict between libpthread and libcthread.
> fshel
Hello,
Anatoly A. Kazantsev, le Sat 14 Jun 2008 20:45:12 +0700, a écrit :
> But if I compile it with command:
> $gcc -o pytest pytest.c -lpython2.5 -lfshelp
>
> and when I run it, I get error:
> pytest:
> /build/mbanck/hurd-20080607/build-tree/hurd/libpthread/pt
error:
pytest:
/build/mbanck/hurd-20080607/build-tree/hurd/libpthread/pthread/pt-self.c:28:
pthread_self: Assertion `__pthread_threads' failed.
Aborted
--
Anatoly A. Kazantsev
Protect your digital freedom and privacy, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_i
Hello!
Neal had the following question after having synchronized by hand a load
of changes from the `hurd' repository's version of libpthread to the
`hurd-l4' one:
| tschwinge : Is there an easy way to keep libpthread in sync for
| both the mainline and for hurd-l4?
O
, but for this to
properly work, libc and libpthread must be compiled at the same time for
making sure that they agree on the way those functions are passed.
For achieving the same on GNU/Hurd, the Hurd's libpthread needs to be
included in glibc. That shouldn't be so big a work.
In addit
ned 1 exit status
> #v-
>
> #v+
> $ uname -a
> Linux dirichlet 2.6.20-12-generic #2 SMP Sun Mar 18 03:07:14 UTC 2007 i686
> GNU/Linux
> $ gcc -Wall t.c -I../gllib -Lgllib -lgnu
> $ echo $?
> 0
> #v-
>
>
> So, where does this stem from? The Hurd's li
1 - 100 of 128 matches
Mail list logo
