Hello,
Some last-minute changes have broken the start of programs in libc0.3
version 2.34-5 and 2.34-6, so do not upgrade to these versions, and wait
for at least 2.34-7~0. If you have unfortunately already upgraded, it's
very easy to fix:
ln -s ld.so.1 /lib/ld.so
Samuel
Hello,
Some news on the glibc/hurd debian packages side :)
So glibc 2.34 seems to be alright now after a few fixes.
On the hurd side:
- there was an issue in fakeroot that was making it inexplicably crash
some processes it runs, now fixed.
- I added a fix for terminal reset at end of session
Package: faketime
Version: 0.9.10-2.1
Severity: important
Tags: patch upstream
Hello,
With glibc 2.34, faketime now fails to build from source, because it
fails passing -lpthread to the linker:
cc -o libfaketime.so.1 -Wl,-soname,libfaketime.so.1 -Wl,-z,relro -Wl,-z,now
-lpthread -Wl,--version
> > On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > > > There's a glibc transition which is ongoing, whose consequence is
> > > > > that upgrading libc0.3-dev to 2.34-3
> > > > I've upgraded on darnassus.sceen.net and
Samuel Thibault, le mar. 09 août 2022 16:37:24 +0200, a ecrit:
> Samuel Thibault, le mar. 09 août 2022 15:06:03 +0200, a ecrit:
> > Richard Braun, le mar. 09 août 2022 14:18:44 +0200, a ecrit:
> > > On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > &
gt; On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > > > There's a glibc transition which is ongoing, whose consequence is
> > > > > that upgrading libc0.3-dev to 2.34-3
> > > > I've upgraded on darnassus.sceen.net and the
Samuel Thibault, le mar. 09 août 2022 16:37:24 +0200, a ecrit:
> Samuel Thibault, le mar. 09 août 2022 15:06:03 +0200, a ecrit:
> > Richard Braun, le mar. 09 août 2022 14:18:44 +0200, a ecrit:
> > > On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > &
Samuel Thibault, le mar. 09 août 2022 15:06:03 +0200, a ecrit:
> Richard Braun, le mar. 09 août 2022 14:18:44 +0200, a ecrit:
> > On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > > There's a glibc transition which is ongoing, whose consequence is
>
Richard Braun, le mar. 09 août 2022 14:18:44 +0200, a ecrit:
> On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> > There's a glibc transition which is ongoing, whose consequence is
> > that upgrading libc0.3-dev to 2.34-3
> I've upgraded on darnas
On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote:
> There's a glibc transition which is ongoing, whose consequence is
> that upgrading libc0.3-dev to 2.34-3 would make some -dev packages
> removed. The rebuilds for these packages are ongoing, you just need to
> wa
Hello,
There's a glibc transition which is ongoing, whose consequence is
that upgrading libc0.3-dev to 2.34-3 would make some -dev packages
removed. The rebuilds for these packages are ongoing, you just need to
wait for a few days, all you'll be able to upgrade libc0.3-dev to 2.34
I forgot here:
Samuel Thibault, le sam. 01 déc. 2018 18:59:48 +0100, a ecrit:
> case F_GETLK:
> case F_SETLK:
> case F_SETLKW:
> {
> struct flock *fl = va_arg (ap, struct flock *);
> struct flock64 fl64 = {
> .l_type = fl->l_type,
> .l_whence = fl->l_w
Svante Signell, le sam. 01 déc. 2018 16:27:24 +0100, a ecrit:
> On Thu, 2015-01-08 at 12:40 +0100, Svante Signell wrote:
> > Attached is the patch adding support for file record locking in glibc,
> > as implemented in Hurd by Neal Walfield and others. This patch should be
> &
On Thu, 2015-01-08 at 12:40 +0100, Svante Signell wrote:
> Hi,
>
> Attached is the patch adding support for file record locking in glibc,
> as implemented in Hurd by Neal Walfield and others. This patch should be
> applied after the corresponding hurd patch series in case glibc
Hello,
Guillem Jover, le dim. 30 sept. 2018 00:19:12 +0200, a ecrit:
> For example in inetutils, the code works on GNU/Linux because it's
> checking whether LNOFLSH is defined, and if so then it uses TIOCLGET.
Ah, I should disable the bits macros too, indeed.
Samuel
Hi!
I just noticed the inetutils build failure on the Hurd, and tracking
it down found:
<https://salsa.debian.org/glibc-team/glibc/blob/sid/debian/patches/hurd-i386/local-no_unsupported_ioctls.diff>
While I've prepared a patch to fix this, I think it might be better
(instead or
one)
Summary: *** glibc detected *** /usr/bin/perl: free(): invalid pointer:
0x01026000 ***
Category: None
Group: None
Resolution: None
Initial Comment:
a few perl applications, perldoc notably, crash with
*** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***
Hello,
FYI, the latest glibc upload (2.24-4) has the dropping of malloc_hook
disabled, so we can build hurd packages again without mach-defpager
having problems. That will buy us time to implemented mlockall, until
upstream removes the support completely.
Samuel
Samuel Thibault, on Tue 23 Aug 2016 22:42:11 +0200, wrote:
> Samuel Thibault, on Tue 23 Aug 2016 22:34:41 +0200, wrote:
> > and uploaded a package to debian,
>
> That'll be libc0.3 2.23-5, will probably be available about tomorrow.
I forgot to mention: this new libc0.3 will thus depend on recent
Samuel Thibault, on Tue 23 Aug 2016 22:34:41 +0200, wrote:
> and uploaded a package to debian,
That'll be libc0.3 2.23-5, will probably be available about tomorrow.
Samuel
Hello,
I have cleaned the patch a bit, commited to a branch in our repo, and
uploaded a package to debian, so we can test the libc part for now, and
we'll include libpthread parts later.
Thanks again for the great work!
Samuel
On 08/01/2016 12:08 PM, Christian Seiler wrote:
> Problem 1 (causing SIGLOST):
>
> When msg_name and msg_namelen are filled for a SOCK_STREAM AF_LOCAL
> socket (maybe also other AF_LOCAL, didn't check) upon calling
> recvmsg, SIGLOST is generated.
So this is actually a b
Hello,
I have fixed the i686 build of glibc:
- 3904414a3008751ffcaf18fbe33bd34812b7bfe5 fixes the
_hurd_self_sigstate reference from
sysdeps/mach/hurd/i386/longjmp_chk.S, which was making the final
libc.so link fail with a newer binutils.
- ifunc is not working yet with static
BTW, I have also commited rules to build the hurd-prof package. This
can however only built with a fixed gcc package ; the patch is pending
upload, I have put built binaries on
http://people.debian.org/~sthibault/tmp/
and then you uncomment the hurd-prof entry in debian/control, and build
with dpk
Svante Signell, on Tue 19 Apr 2016 11:46:18 +0200, wrote:
> As seen on #hurd:
>
> starting /hurd/startup fails:
> "Unexpected error: Invalid argument"
The fixed 2.22-7 just got accepted, it'll land on mirrors within ~6-12h.
Samuel
As seen on #hurd:
starting /hurd/startup fails:
"Unexpected error: Invalid argument"
Andreas Schwab, le Tue 25 Aug 2015 09:23:40 +0200, a écrit :
> Why does install-headers depend on crt*.o?
Ah, sorry, I wasn't clear about it. It does not, it's the bootstrapping
process of debian which uses both install-headers and builds the crt*.o
files so that gcc can start linking basic stuff
Why does install-headers depend on crt*.o? That appears to be the
regression to fix.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Hello,
Andreas Schwab, le Sun 23 Aug 2015 08:54:31 +0200, a écrit :
> Samuel Thibault writes:
> > and this goes on at infinitum. Make -d shows that it is trying to build
> > /tmp/glibc-2.19/build-tree/hurd-i386-libc/mach/mach-shortcuts.h
> > and adding a $(warning) shows th
Samuel Thibault writes:
> and this goes on at infinitum. Make -d shows that it is trying to build
> /tmp/glibc-2.19/build-tree/hurd-i386-libc/mach/mach-shortcuts.h
> and adding a $(warning) shows that the generated mach-shortcuts.h rule
> is for /tmp/glibc-2.19/build-tree/hurd-i386-l
Hello,
We are having trouble with bootstrapping glibc on Debian Hurd. To get
crt*.o, we run
/usr/bin/make cross-compiling=yes -C build-tree/hurd-i386-libc csu/subdir_lib
At some point it gets into
> /usr/bin/make -C ../mach mach-before-compile no_deps=t generating=t
then it builds a cou
Hello,
We got further with cross-bootstrapping hurd-i386, up to installing
glibc headers. The debian packaging however seems to be running a
subdir_lib build in csu (to get crt[1in].o). This ends up looping in
some rule, see below. Manolis, does that ring you a bell?
Samuel
touch /tmp/glibc
d = F_SETLKW64;
>
> Better use a switch () statement for that.
Done.
> > + default:
> > + errno = EINVAL;
> > return -1;
> > + break;
>
> Do not add a break after a return, it is completely useless. Same below.
Done.
> Apart from tha
Hello,
Svante Signell, le Thu 08 Jan 2015 19:54:12 +0100, a écrit :
> You made me confused, so all changes were not made. I think the malloc
> version was better for symmetry reasons. Changed anyway.
Which symmetry? You mean fl->foo vs fl.foo? It is not worth spending a
malloc call for this.
> +
t for file-record-lock RPC fixing posix
file locking using the flock64 version of struct flock.
* bits/fcntl.h: Since MIG cannot mix 32 bit and 64 bit
integers define unique numbers for F_GETLK64, F_SETLK64 and
F_SETLKW64 to prepar
On Thu, 2015-01-08 at 18:03:31 +0100, Svante Signell wrote:
> On Thu, 2015-01-08 at 16:56 +0100, Guillem Jover wrote:
> > On Thu, 2015-01-08 at 12:40:12 +0100, Svante Signell wrote:
> > > Index: glibc-2.19/sysdeps
On Thu, 2015-01-08 at 16:56 +0100, Guillem Jover wrote:
> On Thu, 2015-01-08 at 12:40:12 +0100, Svante Signell wrote:
> > Index: glibc-2.19/sysdeps/mach/hurd/fcntl.c
> > ===
> > --- glibc-2.19.orig/sysd
On Thu, 2015-01-08 at 12:40:12 +0100, Svante Signell wrote:
> Index: glibc-2.19/sysdeps/mach/hurd/fcntl.c
> ===
> --- glibc-2.19.orig/sysdeps/mach/hurd/fcntl.c
> +++ glibc-2.19/sysdeps/mach/hurd/fcntl.c
> @@
Hi,
Attached is the patch adding support for file record locking in glibc,
as implemented in Hurd by Neal Walfield and others. This patch should be
applied after the corresponding hurd patch series in case glibc and hurd
are not built simultaneously. (Maybe the conversion functions as written
by
On Mon, 2014-12-15 at 13:12 +0100, Samuel Thibault wrote:
> Svante Signell, le Mon 15 Dec 2014 11:46:43 +0100, a écrit :
> > export DEB_BUILD_OPTIONS=nocheck
> > dpkg-buildpackage -b -r/usr/bin/fakeroot-hurd 2>&1 |
>
> Rather use -B to avoid building the _all packages.
>
> > mach_init.h .../debia
Svante Signell, le Mon 15 Dec 2014 11:46:43 +0100, a écrit :
> export DEB_BUILD_OPTIONS=nocheck
> dpkg-buildpackage -b -r/usr/bin/fakeroot-hurd 2>&1 |
Rather use -B to avoid building the _all packages.
> mach_init.h .../debian/tmp-xen/usr/include/mach_init.h
You'll probably also want to comment
xen/usr/include/mach_error.h
make[3]: *** wait: (ipc/send) interrupted. Stop.
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '.../mach'
Makefile:229: recipe for target 'mach/subdir_install' failed
make[2]: *** [mach/subdir_install] Error 2
make[2]: Leaving di
Svante Signell, le Sun 14 Dec 2014 23:27:03 +0100, a écrit :
> In file included from /usr/include/i386-gnu/bits/mutex.h:34:0,
> from ../libpthread/include/pthread/pthreadtypes.h:83,
> from ../libpthread/include/pthread/pthread.h:55,
> from ../libpt
glibc (2.19-14~1) FTBFS early. Have I missed something?
The patch ports_h_loop.patch is applied when building hurd.
i586-gnu-gcc-4.8 hurdsig.c -c -std=gnu99 -fgnu89-inline -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -pipe
-Wno-parentheses -Wstrict-prototypes
Svante Signell, le Wed 12 Nov 2014 00:16:37 +0100, a écrit :
> On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote:
> > Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> > > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> > >
On Wed, 2014-11-12 at 00:07 +0100, Samuel Thibault wrote:
> Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> > Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> > but the latest version does not: glibc-2.19-14~0:
>
> But what "previo
Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
> but the latest version does not: glibc-2.19-14~0:
But what "previously" is exactly? Did you try to downgrade the libc or
hurd installed on your b
Svante Signell, le Mon 10 Nov 2014 17:59:45 +0100, a écrit :
> dh_install -plocales-all
> cp: cannot create symbolic link
> ‘debian/locales-all//usr/lib/locale/es_PA/LC_NUMERIC’: Device or
> resource busy
>
> What to do?
Well, investigate? This EBUSY error must be coming from somewhere.
Samuel
Hi,
Previously glibc-2.19-* built fine with fakeroot-hurd (no testsuite),
but the latest version does not: glibc-2.19-14~0:
dh_install -plocales-all
cp: cannot create symbolic link
‘debian/locales-all//usr/lib/locale/es_PA/LC_NUMERIC’: Device or
resource busy
dh_install: cp -a ./build-tree
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
> Ok, so that will be something like this.
Yes.
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140819204539.396742c3...@topped-with-meat.com
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
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
> > >
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 j
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
Hi,
The following patch to sysdeps/mach/hurd/bits/fcntl.h is needed for
future support of posix file locking support in Hurd. These patches are
an update of Neals patches from 2001 adapted for libpthread instead of
cthreads.
The reason this is needed is that the MIG generated RPC for hurd/glibc
On Fri, Feb 21, 2014 at 06:22:13AM -0800, Samuel Thibault wrote:
> libc 2.18 has just been uploaded. It notably includes Richard's fix for
> thread resources and name resolution fix for iceweasel.
We'll have to update hurd packages so that hurd servers actually benefit
from thread destruction. In
Samuel Thibault, le Fri 21 Feb 2014 06:22:13 -0800, a écrit :
> libc 2.18 has just been uploaded. It notably includes Richard's fix for
> thread resources and name resolution fix for iceweasel.
Note: this will uninstall libp11-kit, I'm rebuilding it to fix the
issue.
Samuel
--
To UNSUBSCRIBE,
Hello,
libc 2.18 has just been uploaded. It notably includes Richard's fix for
thread resources and name resolution fix for iceweasel.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
n build the libc there. But I need a little help,
> > > how do I build it? Please be specific ;)
> >
> > Building with gcc 4.8 is a matter of adding these to
> > debian/sysdeps/hurd.mk:
>
> $ svn checkout
> svn://svn.debian.org/pkg-glibc/glibc-package/branches
t? Please be specific ;)
>
> Building with gcc 4.8 is a matter of adding these to
> debian/sysdeps/hurd.mk:
$ svn checkout
svn://svn.debian.org/pkg-glibc/glibc-package/branches/eglibc-2.18
glibc-package-2.18
[.. doing what you told me to...]
$ dpkg-buildpackage -r -b
[...]
patching file s
Justus Winter, le Fri 29 Nov 2013 15:06:31 +0100, a écrit :
> Ok, Richard was kind enough to restore darnassus to a more mainline
> state, so that I can build the libc there. But I need a little help,
> how do I build it? Please be specific ;)
Building with gcc 4.8 is a matter of adding these to
d
Quoting Justus Winter (2013-11-29 01:08:43)
> Quoting Samuel Thibault (2013-11-28 23:54:18)
> > Hello,
> >
> > Adams would like to move glibc 2.18 build to gcc 4.8. It however
> > appears that the resulting build passes testsuites, but once installed
> > on the
Quoting Samuel Thibault (2013-11-28 23:54:18)
> Hello,
>
> Adams would like to move glibc 2.18 build to gcc 4.8. It however
> appears that the resulting build passes testsuites, but once installed
> on the system, it can't boot, apparently there is something fishy
> happ
Hello,
Adams would like to move glibc 2.18 build to gcc 4.8. It however
appears that the resulting build passes testsuites, but once installed
on the system, it can't boot, apparently there is something fishy
happening in the early RPCs.
If anybody happens to have some time to invest
Since 2.17-93 is already in testing, I guess it is fine for me to do
such upload?
Please do it, using current SVN.
kfreebsd-* will also benefit from such upload.
Thanks
Petr
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Con
Hello,
I have an important fix for hurd-i386 glibc (which will fix ruby2.0 and
others) which would be easier to upload in coordination with the hurd
package. The changes in 2.17-94 are only in hurd/ files, except in
include/errno.h where it changes things only for the hurd case.
Since 2.17-93
Svante Signell, le Sat 21 Sep 2013 17:02:28 +0200, a écrit :
> Strange, Pino just said on IRC that the patches were not accepted in
> upstream libc, and the t/verify (whatever that is) might not even be
> acceptable eglibc?
t/verify is already as a patch debian's eglibc
Samuel
--
To UNSUBSCR
have just added them to the debian glibc package.
Strange, Pino just said on IRC that the patches were not accepted in
upstream libc, and the t/verify (whatever that is) might not even be
acceptable eglibc?
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of &quo
Hello,
Thomas Schwinge, le Mon 02 Sep 2013 23:56:08 +0200, a écrit :
> I have implemented SOCK_CLOEXEC for socket in TopGit branch
> t/socket_flags and for socketpair in t/socketpair_flags
I have just added them to the debian glibc package.
Samuel
--
To UNSUBSCRIBE, email to debian-hur
On Mon, 2013-09-02 at 23:56 +0200, Thomas Schwinge wrote:
> Hi!
>
> This is strange -- nearly five years ago, I have implemented SOCK_CLOEXEC
> for socket in TopGit branch t/socket_flags and for socketpair in
> t/socketpair_flags (plus depending branches t/fcntl-internal.h and
> t/verify.h). Cou
Hi!
On Mon, 02 Sep 2013 22:35:51 +0200, Svante Signell
wrote:
> After building dbus-1.6.12-1 with eglibc-2.17-92 starting dbus-daemon
> fails (it was built 80 days ago with eglibc-2.13). The problem is due to
> the two statements in dbus/dbus-sysdeps-unix.c:
> *fd_p = socket (domain, type | SO
On Thu, Feb 28, 2013 at 06:24:57PM +0100, Samuel Thibault wrote:
> I have uploaded glibc and hurd packages with the io_select_timeout
> support to debian-ports.
>
> When upgrading to them, you *have* to reboot right after having upgraded
> the packages, because applications using
Hello,
I have uploaded glibc and hurd packages with the io_select_timeout
support to debian-ports.
When upgrading to them, you *have* to reboot right after having upgraded
the packages, because applications using select will not work until a
reboot.
Samuel
--
To UNSUBSCRIBE, email to debian
>No, the semantics are the same. And you're saying it yourself :
>"hurd_thread_cancel kindly informs the thread that it has been
>canceled". The description of pthread_cancel is "The pthread_cancel()
>function shall request that thread be canceled. [...] The cancellation
>processing in the target t
On Thu, Aug 02, 2012 at 03:13:12PM -0700, Thomas DiModica wrote:
> I get what you're saying: I'm confusing the semantics of how cancellation
> is HANDLED with the semantics of how it is SIGNALED. The signaling
> semantics are the same.
That's it.
> You mean like a PTHREAD_CANCEL_GNU? It would be
On Wed, Aug 01, 2012 at 06:40:05PM -0700, Thomas DiModica wrote:
>
>
> >No, the semantics are the same. The internal implementation may slightly
> >differ, I haven't looked in detail. The point is how to handle
> >cancellation from a cancelled thread, not how to mark a thread as being
> >cancelle
>No, the semantics are the same. The internal implementation may slightly
>differ, I haven't looked in detail. The point is how to handle
>cancellation from a cancelled thread, not how to mark a thread as being
>cancelled. The hurd_thread_cancel function merely exists because there
>isn't any in
On Wed, Aug 01, 2012 at 08:44:20AM -0700, Thomas DiModica wrote:
> Most of what I understand is from what Marcus has to say in this thread here:
> http://lists.gnu.org/archive/html/hurd-devel/2002-07/msg00010.html
That link explains the problem very well. It's better to keep the
current calls to h
From: Richard Braun
To: Thomas DiModica
Cc: "debian-hurd@lists.debian.org" ;
"bdefre...@debian.org"
Sent: Tuesday, July 31, 2012 4:48 PM
Subject: Re: Hurd_condition_wait in glibc libpthreads in Debian
On Tue, Jul 31, 2012 at 03:16:05PM -0700, Thomas DiModica wrote:
> A
On Tue, Jul 31, 2012 at 03:16:05PM -0700, Thomas DiModica wrote:
> As an aside, Vicente Ara (zenton) actually wrote the pthread
> hurd_condition_wait.
> For the provenance of this file, see the thread:
> http://lists.gnu.org/archive/html/bug-hurd/2002-11/msg00195.html
My understanding is that pth
As an aside, Vicente Ara (zenton) actually wrote the pthread
hurd_condition_wait.
For the provenance of this file, see the thread:
http://lists.gnu.org/archive/html/bug-hurd/2002-11/msg00195.html
I'm surprised that the function wasn't added to libpthread earlier.
Thomas DiModica
--
To UNSUB
Here is an updated patch that builds with Debian. Haven't tested it yet, I am
working on creating a
test environment. I essentially just moved the changes Thomas made into
pt-cond-wait.c in
libpthread in glibc.
Thanks,
Barry
On 7/30/2012 9:45 AM, Barry deFreese wrote:
> Hi folks,
&g
Hi folks,
OK, I have a patch that adds pthread_hurd_cond_wait into the libpthreads that
Samuel has migrated
into Debian's glibc. It builds but it isn't creating the symbol in
libpthreads.so. What stupid
thing am I missing?
Attached is the patch.
Thanks!
Barry deFreese
will probably permit to fix the
`__pthread_mutex_timedlock_internal: Assertion `__pthread_threads'
failed.' issue.
Note however that it also adds a __libc_pthread_init symbol in libc,
used by libpthread. So if you ever happen to build your own libc,
make sure to apply the newest patches
Samuel Thibault, le Tue 25 Oct 2011 01:30:20 +0200, a écrit :
> Samuel Thibault, le Tue 25 Oct 2011 01:19:01 +0200, a écrit :
> > Thomas Schwinge, le Tue 25 Oct 2011 01:17:31 +0200, a écrit :
> > > I did not know there was a straightforward/standardized way for doing
> > > this. How does this work
Samuel Thibault, le Tue 25 Oct 2011 01:19:01 +0200, a écrit :
> Thomas Schwinge, le Tue 25 Oct 2011 01:17:31 +0200, a écrit :
> > I did not know there was a straightforward/standardized way for doing
> > this. How does this work? Is there a tool to examine each packages' ELF
> > objects for certa
Thomas Schwinge, le Tue 25 Oct 2011 01:17:31 +0200, a écrit :
> I did not know there was a straightforward/standardized way for doing
> this. How does this work? Is there a tool to examine each packages' ELF
> objects for certain undefined symbols?
find + ar x + tar + nm :)
Samuel
--
To UNSU
> >
> > > > (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
> > > > stop due to this, as I understand its documentation?)
> > >
> > > I don't think it does.
> >
> > Hmm, should it do so? Or are you m
; > > > Ah, do your changes add some RPCs? Then that part is expected. The
> > > > symbols stuff is precisely meant to catch such changes.
> > >
> > > (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
> > > stop due to t
is precisely meant to catch such changes.
> >
> > (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
> > stop due to this, as I understand its documentation?)
>
> I don't think it does.
Hmm, should it do so? Or are you manually watching t
2.13-21+ts.0
> >
> > Ah, do your changes add some RPCs? Then that part is expected. The
> > symbols stuff is precisely meant to catch such changes.
>
> (Does dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
> stop due to this, as I understand
es dh_makeshlibs run dpkg-gensymbols with -c2? Otherwise it wouldn't
stop due to this, as I understand its documentation?)
This change must be because I had Jérémie's hurd-dev 20110519-4~jk4
installed, which contains Emilio's exec server patch.
But, that's exactly what I meant with ``
Guillem Jover, le Tue 25 Oct 2011 00:01:38 +0200, a écrit :
> On Mon, 2011-10-24 at 23:44:27 +0200, Samuel Thibault wrote:
> > > > __vm_statistics@Base 2.11
> > > > __vm_wire@Base 2.11
> > > > __vm_write@Base 2.11
> > > > - __xxx_cpu_control@Base 2.11
> >
> > I guess this is
On Mon, 2011-10-24 at 23:44:27 +0200, Samuel Thibault wrote:
> > > __vm_statistics@Base 2.11
> > > __vm_wire@Base 2.11
> > > __vm_write@Base 2.11
> > > - __xxx_cpu_control@Base 2.11
>
> I guess this is also due to changes? Same answer: dropping symbols in a
> lib is somethin
Thomas Schwinge, le Fri 21 Oct 2011 10:27:03 +0200, a écrit :
> > > If building with EGLIBC_PASSES=libc (more specifically, without xen)
> >
> > I don't use EGLIBC_PASSES, but it shouldn't matter either.
>
> During development, you build all flavors all the time?
No, I just run "make lib" in bui
Hi!
On Thu, 20 Oct 2011 12:44:10 +0200, Samuel Thibault
wrote:
> Thomas Schwinge, le Thu 20 Oct 2011 11:49:38 +0200, a écrit :
> > Hmm, I did a build afresh, and it happens again. How do you do glibc
> > development in this Debian build harness?
>
> Just dpkg-buildpacka
> > > steps needed?
> >
> > I don't see anything wrong here, I've no idea.
>
> Hmm, I did a build afresh, and it happens again. How do you do glibc
> development in this Debian build harness?
Just dpkg-buildpackage with no particular environme
Thomas Schwinge, le Tue 18 Oct 2011 10:42:00 +0200, a écrit :
> Help? Is my package version ``wrong''? Or are just some additional
> steps needed?
I don't see anything wrong here, I've no idea.
Samuel
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubsc
Hi!
I've been building Debian glibc with some additional patches, and added a
new snippet as follows to the top of debian/changelog, for getting a
separate package version number:
eglibc (2.13-21+ts.0) unstable; urgency=low
* [...]
-- Thomas Schwinge Mon, 17 Oct
1 - 100 of 322 matches
Mail list logo
