Hi Manolis, Thanks for the report!
Manolis Ragkousis <manolis...@gmail.com> skribis: > 3) Found a circular dependency between glibc-hurd-headers and > hurd-minimal. Resolved it > and sent a patch to the list. (Ludovic please give it a look :-)) Will do shortly, sorry for the delay! > 4) tarball-package in make-bootstrap.scm does not give the right name > to the packages it produces. > Changed tarball-package so now we can pass the target to it and as a > result it will use the proper name. > > 5) gcc-4.7 passes "--with-native-system-header-dir=" which points to > the wrong libc. According to my > understanding this should point to the proper libc to be used in the > target system. Am I right? > > 6) So the problem with %gcc-static is that libdecnumber: sets "dpd" > while libgcc: sets "no" and we get > a build failure because it can't find "no" in libdecnumber. Found a > similar case here > https://gcc.gnu.org/ml/gcc/2007-03/msg00941.html . Turned everything > in make-bootstrap.scm into procedures > so I am sure it evaluates to the right libc, Note that all three points are related, AIUI. That is, using procedures in make-bootstrap.scm means that the right glibc package gets chosen, which in turn means that #4 and #5 get fixed. > patched libdecunmber's and libgcc's configure.ac so they run > AC_CANONICAL_{BUILD,HOST,TARGET} and made sure with the repl that the > right glibc is used. And still can't find how to solve it. Any > suggestions? Does the issue reported in the 2007 message above still holds? What exactly was the error when cross-compiling libgcc? The Hurd folks may have seen it before. Thanks for all the uneasy & frustrating work! Ludo’.
