Re: Time for another round of releases

[Justus Winter]

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

[Thomas Schwinge]

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

[Samuel Thibault]

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

[Svante Signell]

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

[Justus Winter]

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

[Manolis Ragkousis]

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

[Samuel Thibault]

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

[Manolis Ragkousis]

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

[Richard Braun]

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

[Justus Winter]

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

[Thomas Schwinge]

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

[Samuel Thibault]

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

[Manolis Ragkousis]

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

[Samuel Thibault]

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

[Samuel Thibault]

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

[David Michael]

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]

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

[Samuel Thibault]

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

[Manolis Ragkousis]

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

[Samuel Thibault]

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

[Ludovic Courtès]

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

[Samuel Thibault]

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]

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

[Samuel Thibault]

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

[Richard Braun]

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

[Ludovic Courtès]

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

[Samuel Thibault]

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

[Svante Signell]

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

[David Michael]

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

[Samuel Thibault]

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

[David Michael]

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]

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

[David Michael]

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

[Justus Winter]

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