Re: Hurd port for gcc go PATCH 1-4(23)

[Svante Signell]

On Sun, 2016-11-27 at 18:02 +0100, Samuel Thibault wrote:
> Hello,
...
> > But as you wish, an updated patch is attached.
> 
>  _Bool
>  Continued (uint32_t *w)
>  {
> +#ifndef WCONTINUED
> +  *w = 0;
> +  return 0;
> +#else
>    return WIFCONTINUED (*w) != 0;
> +#endif
>  }
> 
> Err, recheck the semantic of WCONTINUED again, it doesn't modify its
> parameter, it just tests its value.
> 
> Do as I said, just return 0.
> 

No I can't the compiler complains about an unused variable. Maybe
adding an __attribute__((unused)) to the function header?

...
<about renaming files>
> 
> > This is for upstream to decide.
> 
> I'm just afraid they'd just frown on the code submission and not take
> the time to explain how they want it to look like if we don't raise
> the
> discussion ourselves.
> 

Should we propose these changes upstream? Or do you mean something
else? 

> > > And
> > > src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > >   Define Type and Whence as 32bit in syscall.Flock_t
> > > 
> > > Again, you'll probably have to discuss with upstream to see how
> > > they
> > > prefer to make it configurable rather than forking the whole
> > > file.
> > > 
> > 
> > I tried to patch the syscall_unix_test.go file, but did not
> > succeed. 
> > Definitely if runtime.GOOS == "GNU" ... else ... or switch
> > runtime.GOOS
> > ... does not work. The compiler sees all code and complains, also
> > the
> > else part of the code :( Therefore I created a new file.
> 
> Then ask upstream how they think it can and should be done.
> 

Upstream would be Ian Lance Taylor, right?

> > > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum
> > > > libgo.log
> > > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > > 
> > > This seems unrelated?
> > > 
> > No, this is not unrelated: With this patch you can
> > make -C build/i686-gnu/libgo clean
> > make -C build/i686-gnu/libgo
> > to rebuild libgo. Otherwise libcalls.go is not regenerated,
> > mksysinfo.sh is not run etc. 
> 
> That's still unrelated to the matter here: porting go to
> GNU/Hurd.  It
> looks like a bug fix which is completely independant from GNU/Hurd.

Yes it is not Hurd-related. Maybe this should be filed as a separate
bug. To gcc upstream directly?

> > > 
> > > 
> > > We could rather just implement the comm field in ps, AIUI it's
> > > just an alias for the command field.
> > 
> > Your choice. When implemented this patch wouldn't bee needed.
> 
> Then please do implement it :)

Sorry, I need help for doing this. Any other Hurd developer listening?

Thanks for reviewing :) Nice to see that anybody cares.