glibc i686 build

2016-05-30 Thread Samuel Thibault
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 binaries, so I had to use
  export libc_cv_ld_gnu_indirect_function=no
  before running configure, to disable the feature.

Samuel



Re: [PATCH] drop the deprecated malloc/free hooks in hurd/mach-defpager

2016-05-30 Thread Samuel Thibault
Justus Winter, on Wed 18 May 2016 13:27:13 +0200, wrote:
> As Richard said in #hurd, implement mlockall and MCL_FUTURE and just
> use the default allocator.

Indeed.

> I'd suggest reverting that change,

Better be safe for now, yes.  I have also implemented the other hooks,
just to be on the safe side.

> or is the removal of that deprecated interface imminent?

I don't think it's that imminent.

Samuel



[GSoC] Porting GuixSD to GNU/Hurd Update 1

2016-05-30 Thread Manolis Ragkousis
Hello everyone,

One week passed since the beginning of the coding phase of GSoC, so I
think it's time to give you an update on my progress.

In the previous weeks I tried to get me prepared as much as possible and
get a better idea of what needs to be done.  I concentrated on getting
familiar with the parts of Guix and Hurd that are more relevant to this
project and I found out some interesting things.

We already knew that the guix-daemon was not working properly on the
Hurd.  I looked more into it and I found that if you do a build with
Guix and it fails, and then you retry again, the next one will create a
new build directory in /tmp/ as it should, but it will still use the
first one.  What this means is that the status of the previous build
leaks into the new one and there is no isolation.  With this in mind
build isolation in the daemon is currently my first priority.

I also found out that guix publish may sometimes crash if a client asks
for a big substitute.  I will investigate this one as soon as possible.

Now on the coding part, in Guix I updated the gnumach/mig/hurd packages
to the latest version and worked on getting wip-hurd in a state which
can eventually merge to master.  A part of wip-hurd is already on master
and after this core-updates cycle is merged to master, we will be able
to get the rest of wip-hurd merged as well. Package glibc/hurd will also
be updated then as well.

On debian/hurd I am using Guix every day and in my github wip-hurd I
have some patches which I need to clean up and apply to the Guix repo.
These patches are for various packages of various importance.

And on the Hurd side, I created a new library called libhurdutil and
moved the settrans implementation there.  For implementation info please
read this email[1]. I am currently improving that library after
Guillem's and Justus' input. (Thank you :-))  On the Guix side I will
just write a wrapper to use this call and we will be able to control
translators really easily.  This way the non existing mount() is not a
problem anymore :-).

I think that's enough for now.  If you have any questions/suggestions
please feel free to tell me. :-)

Thank you,
Manolis

[1]https://lists.gnu.org/archive/html/bug-hurd/2016-05/msg00041.html