Re: Time for another round of releases
Thomas Schwinge writes: >> but I'm actually glad we did have a chance to merge >> some more stuff ;) So, anything else missing for Hurd 0.9? > > :-) Seems we're good to go; planning for tomorrow. Cool! > I'll then set the GNU Hurd 0.10 etc. release dates for 2017-06, so that > we'll again have six months to get changes done. Or 1.0... /me ducks Cheers, Justus signature.asc Description: PGP signature
Re: Time for another round of releases
Hi! On Sat, 10 Dec 2016 18:35:16 +0100, Justus Winter wrote: > Thomas Schwinge writes: > > > Will it be OK to move the release date towards end of November? (Yay, > > one more month for getting stuff finished for inclusion...) ;'-\ > > Or two (mea culpa) Heh, certainly not your fault! > but I'm actually glad we did have a chance to merge > some more stuff ;) So, anything else missing for Hurd 0.9? :-) Seems we're good to go; planning for tomorrow. I'll then set the GNU Hurd 0.10 etc. release dates for 2017-06, so that we'll again have six months to get changes done. Grüße Thomas
Re: Time for another round of releases
Svante Signell, on Sat 10 Dec 2016 20:29:51 +0100, wrote: > Is there still time for the file record lock patches? I've been running > hurd/glibc locally with them for years now. Okay, but there were comments since the last submission, notably: https://lists.gnu.org/archive/html/bug-hurd/2016-02/msg00046.html https://lists.gnu.org/archive/html/bug-hurd/2016-02/msg00120.html We can't commit patches until they are reasonably right. Copy/pasting the pthread_cond_init prototype is really not. Returning bogus information for GETLK instead of ENOSYS as well: it'll probably bring a lot of subtle bugs here and there. Samuel
Re: Time for another round of releases
Hi Thomas, Is there still time for the file record lock patches? I've been running hurd/glibc locally with them for years now. Thanks! On Sat, 2016-12-10 at 18:35 +0100, Justus Winter wrote: > Thomas Schwinge writes: > > > Will it be OK to move the release date towards end of > > November? (Yay, > > one more month for getting stuff finished for inclusion...) ;'-\ > > Or two (mea culpa), but I'm actually glad we did have a chance to > merge > some more stuff ;) So, anything else missing for Hurd 0.9? > > Cheers, > Justus
Re: Time for another round of releases
Thomas Schwinge writes: > Will it be OK to move the release date towards end of November? (Yay, > one more month for getting stuff finished for inclusion...) ;'-\ Or two (mea culpa), but I'm actually glad we did have a chance to merge some more stuff ;) So, anything else missing for Hurd 0.9? Cheers, Justus signature.asc Description: PGP signature
Re: Time for another round of releases
Hello Samuel On 11/09/16 13:54, Samuel Thibault wrote: > Manolis Ragkousis, on Wed 09 Nov 2016 13:02:14 +0200, wrote: >> Now I only have problems with linking http://paste.lisp.org/display/330765 > > __gsync_wait and __gsync_wake are gnumach RPCs. They have been added to > gnumach quite a long time ago, don't you have them in > gnumach/include/mach/gnumach.defs? > > Samuel > Yes I do have them in gnumach/include/mach/gnumach.defs. The linking errors appears both when building from Guix and on debian/hurd. But I have managed to bypass the linking by first running make mach/subdir_lib, make hurd/subdir_lib, make libpthread/subdir_lib and then make all. It seems there is an issue with the order of subdirs building. Manolis
Re: Time for another round of releases
Manolis Ragkousis, on Wed 09 Nov 2016 13:02:14 +0200, wrote: > Now I only have problems with linking http://paste.lisp.org/display/330765 __gsync_wait and __gsync_wake are gnumach RPCs. They have been added to gnumach quite a long time ago, don't you have them in gnumach/include/mach/gnumach.defs? Samuel
Re: Time for another round of releases
Hello Samuel, The problem was that guix was using gcc-4.9 for cross-compiling which has a bug not present in newer versions. Using the newer gcc-5 fixes this. [1] Now I only have problems with linking http://paste.lisp.org/display/330765 Has anyone encountered this before? Thank you, Manolis [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63567
Re: Time for another round of releases
On Wed, Oct 19, 2016 at 08:10:03PM +0200, Thomas Schwinge wrote: > ..., and again I want to excuse my radio silence... The good news: we're > getting married. The bad news: that basically didn't allow to spend any > time on pet projects, in the last weeks/months. The good news (well, for > us, anyway): we'll soon be leaving for the honeymoon trip. The bad news: > I didn't manage to squeeze in enough time to prepare the releases. I > still need to better document/automate what needs to be done (in > particular for updating the web pages). Will it be OK to move the > release date towards end of November? (Yay, one more month for getting > stuff finished for inclusion...) ;'-\ Congratulations :-). -- Richard Braun
Re: Time for another round of releases
Thomas Schwinge writes: > On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter wrote: >> it is October, therefore, it is time for a new set of releases :) > > Will it be OK to move the release date towards end of November? Sure. > I still need to better document/automate what needs to be done (in > particular for updating the web pages). That would be helpful, yes. > (Yay, one more month for getting stuff finished for inclusion...) > ;'-\ :) Cheers, Justus signature.asc Description: PGP signature
Re: Time for another round of releases
Hi! On Sun, 2 Oct 2016 18:54:05 +0200, Justus Winter wrote: > it is October, therefore, it is time for a new set of releases :) :-) (I've set a reminder in my calender to trigger every half a year.) ;-) ..., and again I want to excuse my radio silence... The good news: we're getting married. The bad news: that basically didn't allow to spend any time on pet projects, in the last weeks/months. The good news (well, for us, anyway): we'll soon be leaving for the honeymoon trip. The bad news: I didn't manage to squeeze in enough time to prepare the releases. I still need to better document/automate what needs to be done (in particular for updating the web pages). Will it be OK to move the release date towards end of November? (Yay, one more month for getting stuff finished for inclusion...) ;'-\ Grüße Thomas
Re: Time for another round of releases
Manolis Ragkousis, on Fri 14 Oct 2016 16:42:42 +0300, wrote: > ../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’: > ../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer > element is not constant > (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZER } > ^ > ../libpthread/include/pthread/pthread.h:757:27: note: in expansion of > macro ‘__PTHREAD_ONCE_INIT’ > #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT >^ > ../libpthread/sysdeps/hurd/pt-key.h:55:29: note: in expansion of macro > ‘PTHREAD_ONCE_INIT’ >static pthread_once_t o = PTHREAD_ONCE_INIT; That's odd, I'm not getting such error. This really is constant... Does the attached program fail to build too? It should be equivalent to the libpthread code at stake. Samuel typedef volatile int fooo; struct foo { int i; fooo j; }; static struct foo bar = (struct foo) { 0, ((fooo) 0)}; int main(void) { }
Re: Time for another round of releases
Building the latest tschwinge/Roger_Whittaker fails with: In file included from ../libpthread/include/pthread/pthreadtypes.h:120:0, from ../libpthread/include/pthread/pthread.h:55, from ../libpthread/include/pthread.h:2, from ../include/pthread.h:1, from ./pthread/../sysdeps/generic/pt-attr.c:20: ../libpthread/sysdeps/hurd/pt-key.h: In function ‘__pthread_key_lock_ready’: ../libpthread/sysdeps/pthread/bits/once.h:32:10: error: initializer element is not constant (struct __pthread_once) { 0, __PTHREAD_SPIN_LOCK_INITIALIZER } ^ ../libpthread/include/pthread/pthread.h:757:27: note: in expansion of macro ‘__PTHREAD_ONCE_INIT’ #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT ^ ../libpthread/sysdeps/hurd/pt-key.h:55:29: note: in expansion of macro ‘PTHREAD_ONCE_INIT’ static pthread_once_t o = PTHREAD_ONCE_INIT; ^ http://paste.lisp.org/display/328517 Manolis
Re: Time for another round of releases
Justus Winter, on Sun 02 Oct 2016 18:54:05 +0200, wrote: > I'm afraid there haven't been any commits for MIG. Does anyone have a > patch for it? Actually I had an unpushed typo patch :) But I have also pushed the proposed fix for the MACH_MSG_TYPE_POLYMORPHIC warning. Samuel
Re: Time for another round of releases
Samuel Thibault, on Mon 10 Oct 2016 21:47:47 +0200, wrote: > In Debian we build with build-mathvec = no FYI I've been testing with ../configure --host=i586-gnu --build=i586-gnu --prefix=/usr --enable-add-ons=libidn,"libpthread " --enable-pt_chown --disable-nscd CFLAGS="-O2 -g" --disable-werror Samuel
Re: Time for another round of releases
David Michael, on Mon 10 Oct 2016 12:44:32 -0700, wrote: > On Sun, Oct 9, 2016 at 3:35 PM, Samuel Thibault > wrote: > > Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote: > >> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: > >> > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > >> > in the process of switching from 2.23 to 2.24), > >> > >> Ah! I was asking the question some time ago, and thought Guix was still > >> on 2.22. We can easily upgrade to 2.23 and 2.24 as needed, we already > >> have the required changes in Debian. > > > > I have now upgraded to 2.23. > > This seems to have fixed the static-linking weirdness, however I now > have to remove a reference to the non-existent libmvec_nonshared at: > > http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/math/Makefile?h=tschwinge/Roger_Whittaker#n102 > > Linking with -lm fails due to that missing file. Is it supposed to be built? In Debian we build with build-mathvec = no Samuel
Re: Time for another round of releases
On Sun, Oct 9, 2016 at 3:35 PM, Samuel Thibault wrote: > Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote: >> Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: >> > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently >> > in the process of switching from 2.23 to 2.24), >> >> Ah! I was asking the question some time ago, and thought Guix was still >> on 2.22. We can easily upgrade to 2.23 and 2.24 as needed, we already >> have the required changes in Debian. > > I have now upgraded to 2.23. This seems to have fixed the static-linking weirdness, however I now have to remove a reference to the non-existent libmvec_nonshared at: http://git.savannah.gnu.org/cgit/hurd/glibc.git/tree/math/Makefile?h=tschwinge/Roger_Whittaker#n102 Linking with -lm fails due to that missing file. Is it supposed to be built? Thanks. David
Re: Time for another round of releases
Samuel Thibault, on Mon 10 Oct 2016 16:10:40 +0200, wrote: > Manolis Ragkousis, on Mon 10 Oct 2016 17:07:52 +0300, wrote: > > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c: > > In function ?__register_new_task_notification?: > > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22: > > error: large integer implicitly truncated to unsigned type > > [-Werror=overflow] > >/* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, > > ^ > > cc1: all warnings being treated as errors > > > > Any ideas? > > In Debian we use -Wno-error, there are lots of warnings here and there, > fixing them all is a no-go for now. I have disabled -Werror in our tree. Samuel
Re: Time for another round of releases
Manolis Ragkousis, on Mon 10 Oct 2016 17:07:52 +0300, wrote: > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c: > In function ?__register_new_task_notification?: > /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22: > error: large integer implicitly truncated to unsigned type [-Werror=overflow] >/* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, > ^ > cc1: all warnings being treated as errors > > Any ideas? In Debian we use -Wno-error, there are lots of warnings here and there, fixing them all is a no-go for now. Samuel
Re: Time for another round of releases
Hello Ludo, Hello Samuel I am currently trying to build the latest tschwinge/Roger_Whittaker with Guix and it fails with /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c: In function ?__register_new_task_notification?: /tmp/guix-build-glibc-cross-i586-pc-gnu-2.23.drv-0/build/mach/RPC_register_new_task_notification.c:78:22: error: large integer implicitly truncated to unsigned type [-Werror=overflow] /* msgt_name = */ MACH_MSG_TYPE_POLYMORPHIC, ^ cc1: all warnings being treated as errors http://paste.lisp.org/display/328211 Any ideas? Manolis On 10/10/16 12:15, Samuel Thibault wrote: > > For 2.23, the tschwinge/Roger_Whittaker is ready. > > Samuel 1nl08hppn6c1lpmbgw07565fbcir4f-glibc-cross-i586-pc-gnu-2.23.drv.bz2 Description: application/bzip
Re: Time for another round of releases
Ludovic Courtès, on Mon 10 Oct 2016 10:02:36 +0200, wrote: > Samuel Thibault skribis: > > Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: > >> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > >> > it. > >> > >> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > >> in the process of switching from 2.23 to 2.24), and we’d prefer to have > >> the same version on both GNU/Linux and GNU/Hurd, modulo the > >> Hurd-specific patches. > > > > So it's now 2.23. When Guix switched to 2.24 for Linux, please tell me, > > I'll update the tree to 2.24. > > It’s already done in a branch that is being built (hopefully merged > within a week or so). > > So you could go ahead and just let us know which tarballs or commits we > should be using for each version. Is that fine with you? Manolis, For 2.23, the tschwinge/Roger_Whittaker is ready. Samuel
Re: Time for another round of releases
Samuel Thibault skribis: > Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: >> > Yes, but our current glibc tree is based on glibc 2.22, as guix needs >> > it. >> >> FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently >> in the process of switching from 2.23 to 2.24), and we’d prefer to have >> the same version on both GNU/Linux and GNU/Hurd, modulo the >> Hurd-specific patches. > > So it's now 2.23. When Guix switched to 2.24 for Linux, please tell me, > I'll update the tree to 2.24. It’s already done in a branch that is being built (hopefully merged within a week or so). So you could go ahead and just let us know which tarballs or commits we should be using for each version. Is that fine with you? Manolis, WDYT? Thanks! Ludo’.
Re: Time for another round of releases
Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: > > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > > it. > > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > in the process of switching from 2.23 to 2.24), and we’d prefer to have > the same version on both GNU/Linux and GNU/Hurd, modulo the > Hurd-specific patches. So it's now 2.23. When Guix switched to 2.24 for Linux, please tell me, I'll update the tree to 2.24. Samuel
Re: Time for another round of releases
Samuel Thibault, on Tue 04 Oct 2016 16:45:36 +0200, wrote: > Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: > > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > > in the process of switching from 2.23 to 2.24), > > Ah! I was asking the question some time ago, and thought Guix was still > on 2.22. We can easily upgrade to 2.23 and 2.24 as needed, we already > have the required changes in Debian. I have now upgraded to 2.23. Samuel
Re: Time for another round of releases
Richard Braun, on Tue 04 Oct 2016 16:45:46 +0200, wrote: > On Tue, Oct 04, 2016 at 03:22:32PM +0200, Ludovic Courtès wrote: > > >> Is it possible to make a release of Hurd until mlockall/munlockall is > > >> implemented? From what I understand these functions are needed to build > > >> Hurd on > > >> top of glibc2.24. > > > > > > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > > > it. > > > > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > > in the process of switching from 2.23 to 2.24), and we’d prefer to have > > the same version on both GNU/Linux and GNU/Hurd, modulo the > > Hurd-specific patches. > > The real problem is that we still have nothing about mlockall... Until > we have, there is really not much to talk about. For 2.24, yes. Samuel
Re: Time for another round of releases
Ludovic Courtès, on Tue 04 Oct 2016 15:22:32 +0200, wrote: > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > in the process of switching from 2.23 to 2.24), Ah! I was asking the question some time ago, and thought Guix was still on 2.22. We can easily upgrade to 2.23 and 2.24 as needed, we already have the required changes in Debian. > and we’d prefer to have the same version on both GNU/Linux and > GNU/Hurd, modulo the Hurd-specific patches. Sure! And Debian has the same issue. I'd say we'd keep the hurd glibc and libpthread repositories to the lowest version of Guix and Debian (i.e. 2.23 ATM). We can store patches for next versions in separate branches (see e.g. master-glibc-2.23 in libpthread). Samuel
Re: Time for another round of releases
On Tue, Oct 04, 2016 at 03:22:32PM +0200, Ludovic Courtès wrote: > >> Is it possible to make a release of Hurd until mlockall/munlockall is > >> implemented? From what I understand these functions are needed to build > >> Hurd on > >> top of glibc2.24. > > > > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > > it. > > FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently > in the process of switching from 2.23 to 2.24), and we’d prefer to have > the same version on both GNU/Linux and GNU/Hurd, modulo the > Hurd-specific patches. The real problem is that we still have nothing about mlockall... Until we have, there is really not much to talk about. -- Richard Braun
Re: Time for another round of releases
Hi, Samuel Thibault skribis: > Svante Signell, on Tue 04 Oct 2016 12:27:12 +0200, wrote: >> On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote: >> > it is October, therefore, it is time for a new set of releases :) >> > >> > I'll be going over the changes and update the NEWS files as usual, but >> > feel free to beat me to that. Also, if anyone has some pet patches or >> > fixes that would be nice to include, feel free to speak up or send >> > patches. >> > >> > Personally, I'd love to include Shengyu Zhang's work on xattrs, so I'm >> > going to see whether I can weed out the remaining issues in time. Also, >> > I have a cleanup patch for Mach. >> > >> > I'm afraid there haven't been any commits for MIG. Does anyone have a >> > patch for it? If not, are we going to make an release anyway, to keep >> > the version numbers in sync with GNU Mach? >> >> Is it possible to make a release of Hurd until mlockall/munlockall is >> implemented? From what I understand these functions are needed to build Hurd >> on >> top of glibc2.24. > > Yes, but our current glibc tree is based on glibc 2.22, as guix needs > it. FWIW Guix follows upstream glibc releases for GNU/Linux (we’re currently in the process of switching from 2.23 to 2.24), and we’d prefer to have the same version on both GNU/Linux and GNU/Hurd, modulo the Hurd-specific patches. Ludo’.
Re: Time for another round of releases
Svante Signell, on Tue 04 Oct 2016 12:27:12 +0200, wrote: > On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote: > > it is October, therefore, it is time for a new set of releases :) > > > > I'll be going over the changes and update the NEWS files as usual, but > > feel free to beat me to that. Also, if anyone has some pet patches or > > fixes that would be nice to include, feel free to speak up or send > > patches. > > > > Personally, I'd love to include Shengyu Zhang's work on xattrs, so I'm > > going to see whether I can weed out the remaining issues in time. Also, > > I have a cleanup patch for Mach. > > > > I'm afraid there haven't been any commits for MIG. Does anyone have a > > patch for it? If not, are we going to make an release anyway, to keep > > the version numbers in sync with GNU Mach? > > Is it possible to make a release of Hurd until mlockall/munlockall is > implemented? From what I understand these functions are needed to build Hurd > on > top of glibc2.24. Yes, but our current glibc tree is based on glibc 2.22, as guix needs it. > Additionally, maybe we should make the effort of merging file record locking > support in Hurd/glibc? I've been adding those patches locally for years now > without hiccups. In my memory I had made questions and remarks which hadn't been answered so far. Samuel
Re: Time for another round of releases
On Sun, 2016-10-02 at 18:54 +0200, Justus Winter wrote: > Hello, > > it is October, therefore, it is time for a new set of releases :) > > I'll be going over the changes and update the NEWS files as usual, but > feel free to beat me to that. Also, if anyone has some pet patches or > fixes that would be nice to include, feel free to speak up or send > patches. > > Personally, I'd love to include Shengyu Zhang's work on xattrs, so I'm > going to see whether I can weed out the remaining issues in time. Also, > I have a cleanup patch for Mach. > > I'm afraid there haven't been any commits for MIG. Does anyone have a > patch for it? If not, are we going to make an release anyway, to keep > the version numbers in sync with GNU Mach? Is it possible to make a release of Hurd until mlockall/munlockall is implemented? From what I understand these functions are needed to build Hurd on top of glibc2.24. Additionally, maybe we should make the effort of merging file record locking support in Hurd/glibc? I've been adding those patches locally for years now without hiccups.
Re: Time for another round of releases
On Sun, Oct 2, 2016 at 12:45 PM, Samuel Thibault wrote: > David Michael, on Sun 02 Oct 2016 12:18:50 -0700, wrote: >> On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault >> wrote: >> > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote: >> >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking >> >> (namely ext2fs.static) from missing pthread_setcancelstate. >> > >> > Ah? I don't understand how: this commit only makes libpthread use its >> > own internal __pthread_setcancelstate symbol. A pthread_setcancelstate >> > alias is still defined from pthread/pt-setcancelstate.c, how is it that >> > you don't get it? >> >> The following is the actual error when using that commit. It looks >> like pthread_setcancelstate is defined in libpthread2.a, and the >> linking command includes -lpthread, which includes -lpthread2. >> Changing error.c and pthread-functions.h doesn't seem correct since >> there are many other instances of that throughout glibc. > > Actually it *is* correct :) > When an application uses error(), it still shouldn't get the > pthread_setcancelstate symbol, and thus error.c should be using > __pthread_setcancelstate, to avoid pulling pthread_setcancelstate. > > That being said, glibc 2.22 didn't fix that yet, that'll be for glibc > 2.23 and later, better not try to backport this which might pose other > troubles. > >> /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error': >> (.text+0x26f): undefined reference to `pthread_setcancelstate' > > So I'm surprised by this. Is -lpthread properly *after* libcrt.a? Well, -lcrt doesn't appear explicitly in the command-line for either exec.static or ext2fs.static. The builds actually succeed if I add either -lc or -lcrt (or their full paths) before or after -lpthread, e.g. by `echo exec.static: -lc >> exec/Makefile`, so I'm not sure what is going on yet. Thanks. David
Re: Time for another round of releases
Hello, David Michael, on Sun 02 Oct 2016 12:18:50 -0700, wrote: > On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault > wrote: > > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote: > >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking > >> (namely ext2fs.static) from missing pthread_setcancelstate. > > > > Ah? I don't understand how: this commit only makes libpthread use its > > own internal __pthread_setcancelstate symbol. A pthread_setcancelstate > > alias is still defined from pthread/pt-setcancelstate.c, how is it that > > you don't get it? > > The following is the actual error when using that commit. It looks > like pthread_setcancelstate is defined in libpthread2.a, and the > linking command includes -lpthread, which includes -lpthread2. > Changing error.c and pthread-functions.h doesn't seem correct since > there are many other instances of that throughout glibc. Actually it *is* correct :) When an application uses error(), it still shouldn't get the pthread_setcancelstate symbol, and thus error.c should be using __pthread_setcancelstate, to avoid pulling pthread_setcancelstate. That being said, glibc 2.22 didn't fix that yet, that'll be for glibc 2.23 and later, better not try to backport this which might pose other troubles. > /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error': > (.text+0x26f): undefined reference to `pthread_setcancelstate' So I'm surprised by this. Is -lpthread properly *after* libcrt.a? > >> The panic update patches produce -Wformat-security warnings--errors > >> with Fedora's CFLAGS. Use a literal "%s" instead of a variable as the > >> format string. > > > > Could you be more precise? A quick check didn't let me see where it was > > a problem. > > This will make it build: Thanks! Samuel
Re: Time for another round of releases
On Sun, Oct 2, 2016 at 10:53 AM, Samuel Thibault wrote: > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote: >> Add a GLIBC_2.22 { __mach_host_self_; } section to mach/Versions. > > Alright, I forgot to cherry-pick the upstream commit for this. Note > however that in upstream, it got versioned to 2.23, so we are diverging > here, distributions will have to handle this. That's fine with me, but I don't know if Guix will have an issue with this difference. CCing Manolis and Ludovic so they are aware of it. >> Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking >> (namely ext2fs.static) from missing pthread_setcancelstate. > > Ah? I don't understand how: this commit only makes libpthread use its > own internal __pthread_setcancelstate symbol. A pthread_setcancelstate > alias is still defined from pthread/pt-setcancelstate.c, how is it that > you don't get it? The following is the actual error when using that commit. It looks like pthread_setcancelstate is defined in libpthread2.a, and the linking command includes -lpthread, which includes -lpthread2. Changing error.c and pthread-functions.h doesn't seem correct since there are many other instances of that throughout glibc. I didn't get much further into it than that yet. /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error': (.text+0x26f): undefined reference to `pthread_setcancelstate' /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error': (.text+0x2b4): undefined reference to `pthread_setcancelstate' /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error_at_line': (.text+0x330): undefined reference to `pthread_setcancelstate' /usr/i686-pc-gnu/sys-root/lib/libcrt.a(error.o): In function `__error_at_line': (.text+0x38f): undefined reference to `pthread_setcancelstate' collect2: error: ld returned 1 exit status ../Makeconf:347: recipe for target 'ext2fs.static' failed >> The panic update patches produce -Wformat-security warnings--errors >> with Fedora's CFLAGS. Use a literal "%s" instead of a variable as the >> format string. > > Could you be more precise? A quick check didn't let me see where it was > a problem. This will make it build: --- a/i386/i386at/biosmem.c +++ b/i386/i386at/biosmem.c @@ -35,7 +35,7 @@ #define __init #define boot_memmovememmove -#define boot_panic panic +#define boot_panic(s) panic("%s", s) #define boot_strlen strlen #define BOOT_CGAMEM phystokv(0xb8000) @@ -216,7 +216,7 @@ unsigned int i; if (start >= end) { -panic(biosmem_panic_inval_boot_data); +panic("%s", biosmem_panic_inval_boot_data); } assert(biosmem_nr_boot_data != 0); Thanks. David
Re: Time for another round of releases
Samuel Thibault, on Sun 02 Oct 2016 19:53:12 +0200, wrote: > David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote: > > There were undefined symbol errors from pthread timer sysdeps. I > > didn't look into a real solution to this one and just worked around it > > with `rm sysdeps/pthread/*timer*`. > > I guess you need unsubmitted-timer_routines.diff from Debian. It still > needs some work. I'll commit that patch to topgit at least. It's now in. Samuel
Re: Time for another round of releases
Hello, David Michael, on Sun 02 Oct 2016 10:22:12 -0700, wrote: > On Sun, Oct 2, 2016 at 9:54 AM, Justus Winter wrote: > > Also, if anyone has some pet patches or > > fixes that would be nice to include, feel free to speak up or send > > patches. > > Okay, here is my semiannual list of non-Debian glibc/libpthread > problems (and also gnumach this time). Thanks! > glibc: > > Add a GLIBC_2.22 { __mach_host_self_; } section to mach/Versions. Alright, I forgot to cherry-pick the upstream commit for this. Note however that in upstream, it got versioned to 2.23, so we are diverging here, distributions will have to handle this. > Fix closing a block in hurd/Versions. Oops, bogus merge indeed. > There were undefined symbol errors from pthread timer sysdeps. I > didn't look into a real solution to this one and just worked around it > with `rm sysdeps/pthread/*timer*`. I guess you need unsubmitted-timer_routines.diff from Debian. It still needs some work. I'll commit that patch to topgit at least. > libpthread: > > Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking > (namely ext2fs.static) from missing pthread_setcancelstate. Ah? I don't understand how: this commit only makes libpthread use its own internal __pthread_setcancelstate symbol. A pthread_setcancelstate alias is still defined from pthread/pt-setcancelstate.c, how is it that you don't get it? > gnumach: > > The highmem patches left a conflicting definition of pmap_map_bd in > linux/dev/glue/kmem.c. I'll let that for Richard :) > The panic update patches produce -Wformat-security warnings--errors > with Fedora's CFLAGS. Use a literal "%s" instead of a variable as the > format string. Could you be more precise? A quick check didn't let me see where it was a problem. > And as a minor request: Can the DDE branch be updated to apply the > patch on current master? Right, I've done it. Samuel
Re: Time for another round of releases
Hi, On Sun, Oct 2, 2016 at 9:54 AM, Justus Winter wrote: > Also, if anyone has some pet patches or > fixes that would be nice to include, feel free to speak up or send > patches. Okay, here is my semiannual list of non-Debian glibc/libpthread problems (and also gnumach this time). glibc: Add a GLIBC_2.22 { __mach_host_self_; } section to mach/Versions. Fix closing a block in hurd/Versions. There were undefined symbol errors from pthread timer sysdeps. I didn't look into a real solution to this one and just worked around it with `rm sysdeps/pthread/*timer*`. libpthread: Commit a87bf9a8eab3af79798131b60c1f7f92f995df8c breaks static linking (namely ext2fs.static) from missing pthread_setcancelstate. gnumach: The highmem patches left a conflicting definition of pmap_map_bd in linux/dev/glue/kmem.c. The panic update patches produce -Wformat-security warnings--errors with Fedora's CFLAGS. Use a literal "%s" instead of a variable as the format string. And as a minor request: Can the DDE branch be updated to apply the patch on current master? The branches have diverged enough that it no longer applies cleanly as a regular patch, though it only needs trivial adjustments. (I'm assuming the 70_dde commit is the "proper" upstream source of the gnumach DDE patch; let me know if there is somewhere else I should get it. (I need it for the Rump PCI drivers.)) Thanks. David
Time for another round of releases
Hello, it is October, therefore, it is time for a new set of releases :) I'll be going over the changes and update the NEWS files as usual, but feel free to beat me to that. Also, if anyone has some pet patches or fixes that would be nice to include, feel free to speak up or send patches. Personally, I'd love to include Shengyu Zhang's work on xattrs, so I'm going to see whether I can weed out the remaining issues in time. Also, I have a cleanup patch for Mach. I'm afraid there haven't been any commits for MIG. Does anyone have a patch for it? If not, are we going to make an release anyway, to keep the version numbers in sync with GNU Mach? Cheers, Justus signature.asc Description: PGP signature