Re: glibc failing to build with undefined reference to `__vm_object_sync`

I think we are using the latest tarball, but we will check. On Thu, Jan 30, 2020, 19:18 Samuel Thibault wrote: > Efraim Flashner, le jeu. 30 janv. 2020 18:36:06 +0200, a ecrit: > > We ran into a bug during Guix Days pre-FOSDEM where we were unable to > > build a cross glibc for hurd. > > Are you

Re: glibc failing to build with undefined reference to `__vm_object_sync`

The version of libc we are using is the upstream glibc 2.29. No debian patches are applied and we could not figure any that were related. On Thu, Jan 30, 2020, 17:36 Efraim Flashner wrote: > We ran into a bug during Guix Days pre-FOSDEM where we were unable to > build a cross glibc for hurd. > >

Re: hurd package

Hello Rene On 8/15/18 11:09 AM, Samuel Thibault wrote: > Hello, > > Rene, le mer. 15 août 2018 02:47:51 +, a ecrit: >> I'm compiling hurd package from git 06429d67b7e9be332d1012ed4c2bba694e5ddabb >> through Guix and I've the following error: >> >> wire.c:227:9: warning: implicit declaration

Re: Fwd: The GNU C Library version 2.28 is now available

On 08/01/18 18:37, Samuel Thibault wrote: > About glibc repositories, we should upgrade the Hurd glibc repository to > 2.28, when would that be fine for people using it? (I'm thinking about > Guix & Arch people) > > Samuel > This is really great!! I will update our glibc-hurd package and we w

Re: Upstreaming the glibc Hurd port

Hello, On 01/19/18 12:10, Thomas Schwinge wrote: > Beware that this script is from many years ago -- from times before my > dear CodeSourcery colleagues taught be how to ;-) properly build > cross-compilers. But yes, cross-gnu did work back then. > > Another thing to look into nowadays is David'

Re: boot the Hurd with Guix

Hello Rene :D On 11/27/17 21:05, ren...@openmailbox.org wrote: > Hello, > > This is the demo generated with Guix: > > https://github.com/methalo/boot-hurd > > The binary files were generated in Debian/Hurd and placed in an 'img' file. > > The command used to generate the binaries is: > > './p

Re: boot the Hurd with Guix

Hello everyone, On 11/16/2017 12:13 PM, Ludovic Courtès wrote: > Hi Samuel, :-) > > Samuel Thibault skribis: > >> Ludovic Courtès, on lun. 13 nov. 2017 11:42:01 +0100, wrote: >>> PS: guix-daemon no longer depends on ‘lsof’, but it still depends on /proc. >> >> Does our procfs have everything i

Re: boot the Hurd with Guix

This is awesome Rene!! Have you uploaded your changes anywhere? On November 11, 2017 8:02:11 PM GMT+02:00, ren...@openmailbox.org wrote: >Hola, > >Finally I was able to start the Hurd with the binaries generated with >the guix package manager. > >At the moment the image of Hurd I have built it man

Re: Question with moving mount/umount logic in glibc

Hello Samuel, can you send me a freelink? Thank you, Manolis On 04/03/2017 11:49 AM, Samuel Thibault wrote: > Hello, > > FWIW, Linux is considering to introduce another API to replace > mount(), that will be more fd-ish, and actually more hurdish, see > https://lwn.net/Articles/718638/ (I can pr

guile 2.0.14 assertion failure

Hello everyone, In guile 2.0.14 while running test 00-repl-server.test with ./check-guile 00-repl-server.test I get: FAIL: 00-repl-server.test: repl-server: simple expression - arguments: (expected-value "scheme@(repl-server)> $1 = 42\n" actual-value "scheme@(repl-server)> While reading express

Re: Porting with Guix

Hello everyone, Continuing my last email the deadlock in "gctest" originates from file phtread_support.c:2007 #ifndef NO_PTHREAD_TRYLOCK if (1 == GC_nprocs || GC_collecting) { pthread_mutex_lock(&GC_allocate_ml) } else { GC_generic_lock(&GC_allocate_ml); } When it tries

Re: Porting with Guix

Hello everyone, On 01/05/17 02:23, ren...@openmailbox.org wrote: > gnu/store/1h7p18gpn84kdww5i542k93arw4hhgs8-libgc-7.6.0/lib > make[2]: Leaving directory > '/tmp/guix-build-libgc-7.6.0.drv-0/gc-7.6.0' > make check-TESTS > make[2]: Entering directory > '/tmp/guix-build-libgc-7

Re: Porting with Guix

Hello Rennes, Please pull the latest changes from my github repo, try again and report back. Manolis

Re: Porting with Guix

Hello Rennes, your previous error is becase Guix uses 4.9 as default which doesn't support non-static initializers. I am currently rebuilding the bootstrap-binaries so you can try again with gcc-5. This error is probably because you are missing guile-2.0-dev. Manolis On 12/30/16 22:40, ren...@op

Re: Porting with Guix

Hello Rennes On 12/28/16 23:22, ren...@openmailbox.org wrote: a345sgsq1c7gb5biaqb8zmyf7934-glibc-bootstrap-0/include/pthread/pthread.h:757:27: > error: initializer element is not constant > #define PTHREAD_ONCE_INIT __PTHREAD_ONCE_INIT >^ > glthread/lock.c:454:42: note

Re: Porting with Guix

Hello Rennes, Did you update your daemon and restart it? Manolis On 12/28/16 21:16, ren...@openmailbox.org wrote: > Hi Manolis, > > After successfully compiling with the new branch. > > I run 'guix build hello --no-substitutes', and shows: > > The following derivations will be built: >/gn

Re: Porting with Guix

Sorry I forgot this. > Are there additional changes needed compared to Guix 0.12.0? Do you > happen to have a write-up on how to get started with the Hurd and Guix? Well I need to clear my daemon work and merge with guix proper. I haven't and I need to do that.

Re: Porting with Guix

Hey Ricardo, :-D I don't think we have i586 binaries in Guix proper yet. We need to first build them with hydra. Manolis On 12/28/16 20:15, Ricardo Wurmus wrote: > > Hi Manolis, > >> Now on the problem, I suppose you are using the Guix version from my >> github repo? The wip-hurd branch is an

Re: Porting with Guix

Hello Rennes, First of all thank you for helping with this! Now on the problem, I suppose you are using the Guix version from my github repo? The wip-hurd branch is an older version which is probably why you have those issues. I created a new branch in my github repo called wip-hurd-native for yo

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 > gn

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 [

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:

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-cros

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

On 08/20/16 20:47, Samuel Thibault wrote: > Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? Of course :-)

Re: [GSoC] Porting GuixSD to GNU/Hurd Update

Hey Samuel, Actually the Hurd part of Guix uses 2.19 as it is in ftp://alpha.gnu.org/gnu/hurd/ The glibc tarballs use 2.19 as their version, which is the one I am using as the version in our glibc/hurd recipe. Check (gnu packages base) glibc/hurd. Manolis On 08/20/16 19:24, Samuel Thibault wro

[GSoC] Porting GuixSD to GNU/Hurd Update

Hello Guix, Hello Hurd, As GSoC is coming to an end I think it's time to sum up my work till now, report issues I had and then talk about what our next steps are. First I would like to mention what were the two main objectives of the project and also what was the status of the port when the proje

[GSoC] Porting GuixSD to GNU/Hurd Update 1

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

[PATCH] libhurdutil: New library containing utils to be used by Guix.

to be changed. settrans_flags_cleanup() needs some work and I need to add more comments. It's still work in progress so please feel free to correct/suggest anything. :-) Thank you, Manolis From 4fe21e255e483a711f898227b90b130afd969b33 Mon Sep 17 00:00:00 2001 From: Manolis Ragkousis Date: Thu, 1

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hey On 03/24/16 15:22, Ludovic Courtès wrote: > So, let’s say PID isolation will be optional, and we can always adjust > later on. Sounds good? > > Manolis, make sure to read about how the various Hurd servers provides > these parts of POSIX personality: file systems, UIDs, PIDs, networking, > a

Re: [GSoC] Porting GuixSD to GNU Hurd draft

On 03/24/16 13:38, Justus Winter wrote: > Otoh if we could properly build packages, we could provide the > substitutes, so people could try Guix on the Hurd without going > through the 12h+ bootstrap procedure. Here the problem is not isolation but the fact that we don't have a substitutes server.

Re: [GSoC] Porting GuixSD to GNU Hurd draft

Hello Justus, Hello Ludo On 03/23/16 18:55, Justus Winter wrote: > Quoting Ludovic Courtès (2016-03-23 14:40:38) >>> 2. The Project >>> >>> The project consists of four main stages >>> >>> 1. Modify Guix so it will be able to create and mount the file-system >>> needed to boot into a system with

[GSoC] Porting GuixSD to GNU Hurd draft

google.com/document/d/1NEEz_PHM2YZTm8okd2BgPRSc4c89I1fGnwbyeeEUrhw/edit?usp=sharing This is the time to share your ideas/corrections :-) Manolis Porting GuixSD to GNU/Hurd Manolis Ragkousis manolis...@gmail.com March 17, 2016 1. Summary In this project, we would like to port the Guix Software Distr

Re: GSoC ideas

Hey On 03/02/16 23:31, Ludovic Courtès wrote: > Do you have examples of GNU/Linux uses that would make no sense? > After a quick look in mount's man page I think that maybe Roland was referring to some flags (like relatime for example) that when passed to mount, expect the Linux kernel to handle

Re: [gscriv...@gnu.org: [IMPORTANT] Ideas for Summer of Code 2016]

Hey On Feb 14, 2016 12:40 PM, "Justus Winter" <4win...@informatik.uni-hamburg.de> wrote: > * https://www.gnu.org/software/hurd/community/gsoc/project_ideas/package_manager.html > > This talks about replacing Guix symlink-tree with a specialized > translator. That would be a nice addition. Manoli

Re: GSoC ideas

Hello everyone, As I am still a student I would like to suggest continuing the project of porting Guix to GNU/Hurd in this GSoC as well, with the objective of having a working GuixSD/Hurd by the end of the summer. After discussions with Justus and Samuel in FOSDEM about the Guix-Hurd port I am st

Re: fosdem talk?

Well the bulk of the work has been done and Guix does run on Hurd. It is still ongoing but now I am mostly solving per package problems and eliminating Linuxism in Guix now but I am not sure if this is enough for another gsoc. We can talk about it tomorrow. Btw Samuel I have a talk tomorrow at 10

Re: Rolling new releases

There is also a patch in the debian glibc called "unsubmitted-clock_t_centiseconds.diff" that fixes some test failures for programs like guile. Could this patch be included as well, if a new glibc+libpthread snapshot is created? Thanks, Manolis

[PATCH] Check sysheaders when looking for Mach and Hurd headers

Hello everyone, With this patch, glibc's configure takes into account the "--with-headers" argument when checking for Mach and Hurd header. This patch applies on glibc master. From 163cac91f3e5d8e200cf2ddd4a44fe582b989f48 Mon Sep 17 00:00:00 2001 From: Manolis Ragkousis Date: W

Re: [PATCH] Check sysheaders when looking for Mach and Hurd headers.

On 27 August 2015 at 00:44, Samuel Thibault wrote: > Please do, the patch looks completely sane (and is actually what other > configure.ac files do). Will do :)

[GSoC update] Porting Guix to GNU/Hurd

Hello everyone, As the hard pencil down date approaches, I believe it's time for a detailed report on my progress till now. I will start with what we have right now and then continue with what problems I had and what I did. First let's see what we have now, working. 1) Guix can successfully cross

Re: AC_NO_EXECUTABLES

On 19 August 2015 at 20:06, Samuel Thibault wrote: > I'll see around that, but it'd be more convenient that ac_no_link makes > link test fail only, not abort... That sounds great. :) Manolis

[PATCH] Check sysheaders when looking for Mach and Hurd headers.

y there. I will send to libc-alpha an updated patch that applies to their tree. From 39b09d8cb8ee3b3ca0ca9fcd772df3fab41c02f8 Mon Sep 17 00:00:00 2001 From: Manolis Ragkousis Date: Fri, 14 Aug 2015 01:20:59 +0300 Subject: [PATCH] Check sysheaders when looking for Mach and Hurd headers. * sysdeps/ma

Problem with natively built binaries on Hurd from Guix

Hello guys, I asked the same question yesterday in the irc, but I thought I should repost it to the mailing list so more people can see it. When I try to run the binaries, I get "error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory" li

Question with moving mount/umount logic in glibc

Hello everyone, Time for glibc questions :) I have a question about utils/mount.c. In the contribution page it says "Move the mount/umount logic from utils/{,u}mount.c into glibc". After a short conversation with Thomas here 's how I think I will implement it : (glibc)/sysdeps/mach/hurd/mount.h

Re: [GSoC] Guix + Hurd continuation

Hello everyone, On 2 July 2015 at 12:12, Ludovic Courtès wrote: > 0. Run Guix’s ‘./configure --with-courage && make’ and see what > happens. > 1. ‘guix-daemon’ must work correctly on GNU/Hurd. Already started working on them. Will report back today on my first results. > > 2. When bu

Re: glibc build log (TLS-related issue)

Hi again On 24 June 2015 at 12:17, Thomas Schwinge wrote: >> and the same command with the tarballs sources end up with >> >> http://paste.lisp.org/display/150437 > > That looks like , >

Re: glibc build log (TLS-related issue)

On 24 June 2015 at 12:17, Thomas Schwinge wrote: > That looks like something's going wrong with IFUNCs, > . What's your > exact configure command line? In particular, are you using > --disable-multi-arch (if I remember correctly)? No I am

Re: glibc build log (TLS-related issue)

On 23 June 2015 at 16:10, Samuel Thibault wrote: > Ok, the change which made my glibc work with static linking is: > > --host=i586-gnu --build=i586-gnu > > I guess the default i686 variant introduces bugs. > Trying to run "make lib" in darnassus using i586-gnu, with the debian sources, fails with

Re: glibc build log (TLS-related issue)

On 23 June 2015 at 16:10, Samuel Thibault wrote: > Ok, the change which made my glibc work with static linking is: > > --host=i586-gnu --build=i586-gnu > > I guess the default i686 variant introduces bugs. > Trying to run "make lib" in darnassus using i586-gnu, with the debian sources, fails with

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Hello > Now, from a discussion we had on IRC, I think the problem reported at > the beginning of this thread is fixed. Manolis, can you confirm? Yes, I am doing a local cleanup and I am sending the patches to the list. > Also, I think the target should be 4.9 or 4.8, but definitely not 4.7. > S

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Hello Thomas Actually I did a mistake last time, I should have told you to build gcc-4.8, not gcc-4.7, because that's what make-bootstrap.scm use. Btw I managed to build the bootstrap-tarballs. Per Ludo's suggestion I removed "--disable-decimal-float" flag from %gcc-static and we got the binaries

Re: GSoC: Porting Guix to Hurd week 3+4 report.

Hey Thomas, thank you for looking into this. On 2 June 2015 at 18:55, Thomas Schwinge wrote: > Shame on me, but I've never actively used/built Guix before. I do know > about , and that there must be > a Guix manual existing -- but can you help me get st

GSoC: Porting Guix to Hurd week 3+4 report.

Hello Guix, Hello Hurd Last week I didn't send a report on my progress because I didn't believe I have anything of importance to report. So here is a recap of what I did these two weeks, the problems I came up with, and the problems I currently have. 1) I sent the patches of the two previews week

GSoC: Porting Guix to Hurd week 2 report

Hello Guix, Hello Hurd Time for the second report. Will report what happened in chronological order like the last time. 1) I modified gnumach-headers and hurd-headers packages so they will use "--build=i686-pc-gnu" only when not cross-building. 2) Mig needs flex for both build and run time. So I

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Hello everyone, Everything works great with those branches. Thomas please have a look at uploading a tarball. :-) Manolis

Re: GSoC: Porting Guix to Hurd week 1 report

Hey Ludo On 8 May 2015 at 17:44, Ludovic Courtès wrote: > guix build --target=i686-pc-gnu coreutils sed tar > > works as expected on wip-hurd, right? > Yes > Did you try running the resulting binaries on GNU/Hurd? ISTR there were > problems in the past. > Will report back on that. Manolis

GSoC: Porting Guix to Hurd week 1 report

Hello Guix, Hello Hurd I think it's time for my first report so everyone is up to date . I will describe what happened in chronological order: 1) Pushed acl patch to wip-hurd so coreutils can be built for target=i686-pc-gnu. 2) Simplified our glibc-hurd and hurd minimal package, thanks to the lat

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Good morning Samuel, > > seems to be going fine. Thomas, can you have a look at uploading a > tarball of this so it can be used as a base for Guix? I will try to build it as well and I'll report back. Samuel, Thomas, thank you for working on this. :-) Manolis

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Hey Andreas :D On 30 Apr 2015 00:53, "Andreas Enge" wrote: > I am not quite sure how this is supposed to make things easier. Why not simply > use a branch in the guix repo (like the existing wip-hurd, or wip-wip-hurd for > very experimental changes)? Then every commit of yours will be sent to ou

Re: GSoC: Manolis to work on Guix port to GNU/Hurd

Hello everyone and thank you :-) On 29 April 2015 at 22:40, Ludovic Courtès wrote: > Manolis, Samuel: feel free to mention whatever I forgot! > I just wanted to add that I will keep a repo at github which I will upload any (serious) local changes before I send them as patches so anyone can keep

Re: Release process & rolling new releases

Congratulations guys, awesome work!! Manolis

Re: 'struct flock' has no member named 'l_end'

One last thing, in libpthread commit 8b48173fdc8f52a234ff9d3d1de5277c60d7eea4 the Makefile expects shm-directory.c to be present in sysdeps/generic/ but it is not. This file only exists in glibc 2.21 and is not yet implemented in our libpthread. Thanks you, Manolis

Re: 'struct flock' has no member named 'l_end'

Hello, On 25 March 2015 at 01:39, Samuel Thibault wrote: > This was not up to date to some oddness in the tls-threadvar branch, but > I've now fixed it, and thus contains the fix from the corresponding > branch. Thank you. > BTW, I think the latest libpthread source will save you some unnecessa

'struct flock' has no member named 'l_end'

Hello Samuel, Hello Hurd hackers Glibc, branch tschwinge/Roger_Whittaker fails to build with " 'struct flock' has no member named 'l_end' ". The problem was introduced with commit 0a137670752d07827ce8612505c85f4dafb70d28 in file sysdeps/mach/hurd/fcntl.c with + return __f_setlk (fd, fl

Re: FOSDEM

On 28 January 2015 at 15:56, Thomas Schwinge wrote: > Better late than never! Please edit/extend > . > with your data. Sorry, I don't have an account either. I am arriving on Friday 11:00 AM and leaving on Monday around 12PM.

Re: FOSDEM talk?

Nice idea. I will be able to join you this year. Looking forward. Manolis

Re: nscd fails to build

First of all we get the error that Ludo sent in the previous message if we leave nscd enabled. Now the problem is in nscd/connection.c at struct database_dyn dbs[lastdb]. The macro PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP is used, but it's nowhere to be found in libpthread as one would

Re: [PATCH] nscd: Remove unused typedef and variable.

Tested on Hurd. Manolis

Re: State of patch in debian/hurd glibc

That's great thank you :-) Manolis

State of patch in debian/hurd glibc

What is the state of the patch unsubmitted-pthread_posix-option.diff from the debian/hurd glibc package? It is critical in building glibc, as without it fails with > In file included from gai_sigqueue.c:22:0: > ./gai_misc.h:32:5: error: unknown type name 'pthread_cond_t' > pthread_cond_t *

Re: Circular dependency with glibc libpthread libihash

> Could you try > > AC_MSG_WARN("cross-compiling, disabling linking") > > ? diff --git a/configure.ac b/configure.ac index ecabfdf..7ede6db 100644 --- a/configure.ac +++ b/configure.ac @@ -83,6 +83,13 @@ AC_PROG_INSTALL AC_PROG_AWK AC_PROG_SED +if test "x$cross_compiling" = "xyes"; then + # I

Re: Circular dependency with glibc libpthread libihash

I sent the mail by mistake incomplete, I am sorry. > Could you try this patch for the Hurd’s configure.in? I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with >> syntax error near unexpected token `fi'. Other than that it works as expected for me. diff --git a/config

Re: Circular dependency with glibc libpthread libihash

> Could you try this patch for the Hurd’s configure.in? I had to put one more line after AC_NO_EXECUTABLES, otherwise it would fail with >> syntax error near unexpected token `fi'.

Problem with glibc and libihash

First of all libihash and any of the hurd libraries cannot be built without a working glibc. Hurd libs depend heavily on header files found in glibc like "lowlevellock.h", so even after making the build system of the hurd repository to accept not to be able to build programs (as Samuel suggested),

Re: Circular dependency with glibc libpthread libihash

0:00 Ludovic Courtès : > > Could you show what test tries to compile a program? (Send config.log.) > Here it is This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Hurd configure 0.5, which was genera

Circular dependency with glibc libpthread libihash

When libpthread tries to link against "libihash.so" I get the error: /lib/libihash.so: file not recognized: File format not recognized. This happens because libihash was built using the native compiler. So I changed the flag in libihash configure to "--host" so it will use the cross-compiler. But

Re: Glibc building procedure error report.

2014-04-07 21:05 GMT+00:00 Samuel Thibault : > Which version of libpthread is this? I don't have this in my copy of the > tree. We got rid of these a long time ago. I am using the master branch, commit 3b391db91f70b2166951413ee1eccc78cd398a44

Re: Glibc building procedure error report.

I am having some problems with building the libpthread addon. I get the error > ../libpthread/sysdeps/mach/hurd/pt-sysdep.h:38:32: error: > '_HURD_THREADVAR_DYNAMIC_USER' undeclared (first use in this function) > #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER <-- but I > can't s

Re: RFC: upstreaming debian/patches/exec_filename_* and the dde stuff

As I said in the irc it would be really helpfull if the debian patches got merged with the upstream. Right now whenever I get an error, I am searching in them, handpicking the part that solves it. Actually some of the debian patches are necessary to built glibc and libpthread. I will report exactly

Re: Glibc building procedure error report.

>> However, it adds the start/stop symbols for the hurd_fork hooks, but not >> for the hurd_atfork hooks. Do we need something like this: I added the following lines to the shlib.lds part of Makerules so I can bypass the problem and it seems to work. +PROVIDE(__start__hurd_atfork

Re: Glibc building procedure error report.

> Mmm, I wonder why. The libc_add_on_subdirs=. line in configure should > have made the build system take the libpthread/sysdeps path into account > (at least in the Debian package it does). It takes into account the libpthread/sysdeps tree path. I have pasted the corresponding output of the co

Re: Glibc building procedure error report.

As I said in the irc I managed to bypass the previous error by deleting #define _EXTERN_INLINE in signal/sigsetops.c I am now getting the error > /../build/libc_pic.os: In function `__fork': > /../source/posix/../sysdeps/mach/hurd/fork.c:71: undefined reference to > `__start__hurd_atfork_prepa

Glibc building procedure error report.

I came across on some issues in the building procedure which are not solved in the debian patches so I think I should report them, ask for comments on them and be as solid as possible in my descriptions. First there are 2 definitions of "sigset_t" One in "(path_to_glibc)/libpthread/signal/signal.

Re: libpthread fails to build as an add-on

In the debian package I saw there are 2 patches that add this. > +libc_add_on_canonical=libpthread > +libc_add_on_subdirs=. How does this change the configure process?

Re: libpthread fails to build as an add-on

As Ludovic wrote > Actually libc's configure doesn't use the normal AC_CONFIG_SUBDIRS > mechanism, and instead runs add-on configure scripts by itself, without > arguments AFAICS. The part responsible for this is in the attached file and specifically the part: > libc_add_on_frag=$libc_add

Re: libpthread fails to build as an add-on

> (This is libpthread's config.log, right?) It's the config.log generated in the build folder of glibc. There is no config.log file generated from libpthread. Manolis > starting phase `configure' source directory: "/tmp/nix-build-glibc-hurd-cross-i686-pc-gnu-2.18.drv-4/source" (relative from

Re: [GSoC] Porting Guix to GNU/Hurd

Hi David > I'm not really a Hurd developer, but I've been cross-compiling > Hurd-from-scratch from git for a little over a year now. Let me know > if you get stuck or just want to see some relevant code, and we can > share scripts and notes (at least for the earlier stages of your > project). Th

[GSoC] Porting Guix to GNU/Hurd

or questions that can help me. Manolis Ragkousis