Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Ludovic Courtès]

Hi zamfofex,

And sorry for the late reply…

zamfofex  skribis:

> hurdauth.c:166:1: error: conflicting types for ‘_S_msg_del_auth’; have 
> ‘kern_return_t(mach_port_t,  task_t,  const int *, mach_msg_type_number_t,  
> const int *, mach_msg_type_number_t)’ {aka ‘int(long unsigned int,  long 
> unsigned int,  const int *, unsigned int,  const int *, unsigned int)’}
>   166 | _S_msg_del_auth (mach_port_t me,
>   | ^~~
> In file included from hurdauth.c:19:
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.35.drv-0/build/hurd/hurd/msg_server.h:72:15:
>  note: previous declaration of ‘_S_msg_del_auth’ with type 
> ‘kern_return_t(mach_port_t,  mach_port_t,  int *, mach_msg_type_number_t,  
> int *, mach_msg_type_number_t)’ {aka ‘int(long unsigned int,  long unsigned 
> int,  int *, unsigned int,  int *, unsigned int)’}
>72 | kern_return_t _S_msg_del_auth
>   |   ^~~
> make[2]: *** [../o-iterator.mk:9: 
> /tmp/guix-build-glibc-cross-i586-pc-gnu-2.35.drv-0/build/hurd/hurdauth.o] 
> Error 1

Looking at this, glibc now has ‘const’ qualifiers for the ‘uids’ and
‘gids’ parameters:

--8<---cut here---start->8---
kern_return_t
_S_msg_del_auth (mach_port_t me,
 task_t task,
 const_intarray_t uids, mach_msg_type_number_t nuids,
 const_intarray_t gids, mach_msg_type_number_t ngids)
--8<---cut here---end--->8---

This comes from this glibc commit:

  commit 0eb230ccceee70c4b5d2a75807d2189aa4ed6e7c
  Date:   Sun Jan 16 18:28:40 2022 +

  hurd: Make RPC input array parameters const

  This follows mig's cf4bcc3f1435 ("Also add const qualifiers on server
  side")

My guess is that you’re running a version of MiG that’s older than
cf4bcc3f1435 (MiG commit), and thus it generates stubs (such as the
‘msg_server.h’ file mentioned in the error message above) that lack
those ‘const’ qualifiers.

If that reasoning is good, updating MiG should fix it.

HTH,
Ludo’.

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Svante Signell]

On Thu, 2022-12-15 at 12:17 +0100, Svante Signell wrote:
> 
> Hi,
> 
> The problem is probably that you need to add --enable-add-ons=libpthread to
> configure when building first version of cross-glibc. This is to obtain weak
> references when building libcstd++ of cross-gcc:
> 
> nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
> ...
> w __pthread_key_create
> w pthread_key_create
> w pthread_key_delete

I've been looking into this problem a little further: You need the attached
patch: libstdc++-hurd.diff, at least for gcc-11 and gcc-12 (and probably gcc-13
too)


Good luck!
This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.

The pthread_self() function can also always be used fine as it is on
GNU/Hurd.

libstdc++-v3/ChangeLog:

* config/os/gnu-linux/os_defines.h [!__linux__]
  (_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.

--- a/libstdc++-v3/config/os/gnu-linux/os_defines.h
+++ b/libstdc++-v3/config/os/gnu-linux/os_defines.h
@@ -49,22 +49,24 @@
 // version dynamically in case it has changed since libstdc++ was configured.
 #define _GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC __GLIBC_PREREQ(2,23)
 
-#if __GLIBC_PREREQ(2, 27)
-// Since glibc 2.27 pthread_self() is usable without linking to libpthread.
-# define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
-#else
+#ifdef __linux__
+# if __GLIBC_PREREQ(2, 27)
+// Since glibc 2.27 Linux' pthread_self() is usable without linking to libpthread.
+#  define _GLIBCXX_NATIVE_THREAD_ID pthread_self()
+# else
 // Before then it was in libc.so.6 but not libc.a, and always returns 0,
 // which breaks the invariant this_thread::get_id() != thread::id{}.
 // So only use it if we know the libpthread version is available.
 // Otherwise use (__gthread_t)1 as the ID of the main (and only) thread.
-# define _GLIBCXX_NATIVE_THREAD_ID \
-  (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
-#endif
+#  define _GLIBCXX_NATIVE_THREAD_ID \
+   (__gthread_active_p() ? __gthread_self() : (__gthread_t)1)
+# endif
 
-#if __GLIBC_PREREQ(2, 34)
-// Since glibc 2.34 all pthreads functions are usable without linking to
+# if __GLIBC_PREREQ(2, 34)
+// Since glibc 2.34 all Linux pthreads functions are usable without linking to
 // libpthread.
-# define _GLIBCXX_GTHREAD_USE_WEAK 0
+#  define _GLIBCXX_GTHREAD_USE_WEAK 0
+# endif
 #endif
 
 #endif

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Svante Signell]

On Thu, 2022-12-15 at 01:24 -0600, Nathan Dehnel wrote:
> You could try seeing what they're doing here to cross-build
> https://github.com/flavioc/cross-hurd
> It worked last time I ran it (which was admittedly a while ago)

Hi,

The problem is probably that you need to add --enable-add-ons=libpthread to
configure when building first version of cross-glibc. This is to obtain weak
references when building libcstd++ of cross-gcc:

nm --dynamic /cross-tools/lib/libstdc++.so.6.0.30|grep pthread
...
w __pthread_key_create
w pthread_key_create
w pthread_key_delete
...

Then that build of cross-gcc will succeed in building the Hurd version of
libstdc++ etc.
nm --dynamic /tools/lib/libstdc++.so.6.0.30|grep pthread


The problem is due to that with recent versions of glibc libpthread is included
for Linux, but not for Hurd.

Note that don't issue autoreconf gcc (in my case 12.2.0) unless you have only
autoconf2.69 installed (or what is needed for your version of upstream gcc).

My scripts to cross-build Hurd on Debian/GNU Linux: hurd-cross (hurdX) will soon
be published on Savannah under the Hurd umbrella. Note the name difference:
hurd-cross vs cross-hurd. As of current these scripts include up-to-date
versions of all packages used, with git versions of mig, gnumach and hurd.

(The scripts of hurd-cross were based on the work by Flavio in 2019, thank you
Flavio. However they have diverged considerably since then, and are not easily
merged into his work at github)

Good luck!

GMP GCC C++ Hurd cross-build failure on core-updates

[Nathan Dehnel]

You could try seeing what they're doing here to cross-build
https://github.com/flavioc/cross-hurd
It worked last time I ran it (which was admittedly a while ago)

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Ludovic Courtès]

Hi,

zamfofex  skribis:

> configure:10478: checking C++ compiler i586-pc-gnu-g++  -m32 -O2 -pedantic 
> -fomit-frame-pointer
> Test compile: 
> configure:10492: i586-pc-gnu-g++  -m32 -O2 -pedantic -fomit-frame-pointer 
> conftest.cc >&5
> i586-pc-gnu-ld: 
> /gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so:
>  undefined reference to `pthread_rwlock_unlock'
> i586-pc-gnu-ld: 
> /gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so:
>  undefined reference to `pthread_create'

It looks as if libstdc++.so lacked libpthread.so from its dependencies
(DT_NEEDED).

What does this say:

  objdump -x \
  
/gnu/store/g3p2j9pb7skjdwrgk4zxlbxhxq6zl5rh-gcc-cross-i586-pc-gnu-11.3.0-lib/lib/gcc/i586-pc-gnu/11.3.0/../../../../i586-pc-gnu/lib/libstdc++.so
 \
  | grep NEEDED

?

Thanks,
Ludo’.

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[zamfofex]

I realized it might also be useful to include GMP’s ‘config.log’ with 
‘--keep-failed’, so I’ll send it as an attachment in this email. Thank you in 
advance once again!This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by GNU MP configure 6.2.1, which was
generated by GNU Autoconf 2.69.  Invocation command line was

  $ ./configure CC_FOR_BUILD=gcc 
CONFIG_SHELL=/gnu/store/bphb827vv6jrja5wyp3gj4yn1f96bm99-bash-minimal-5.1.16/bin/bash
 SHELL=/gnu/store/bphb827vv6jrja5wyp3gj4yn1f96bm99-bash-minimal-5.1.16/bin/bash 
--prefix=/gnu/store/08x48463r73vvmxkwidy0rsvhhbdxs53-gmp-6.2.1 
--enable-fast-install --build=x86_64-unknown-linux-gnu --host=i586-pc-gnu 
--enable-fat --enable-cxx

## - ##
## Platform. ##
## - ##

hostname = localhost
uname -m = x86_64
uname -r = 6.0.7-gnu
uname -s = Linux
uname -v = #1 SMP PREEMPT_DYNAMIC 1

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = unknown
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /gnu/store/glj8i8s8gf3w0ich3f23ng7dp3z21yv2-m4-1.4.19/bin
PATH: 
/gnu/store/51c9khy6lz5ibv7nsd3i3whdbj8ks33s-gcc-cross-i586-pc-gnu-11.3.0/bin
PATH: 
/gnu/store/4arnacpgpn0ypdxdr587vbdg86lpyy7k-binutils-cross-i586-pc-gnu-2.38/bin
PATH: /gnu/store/wr7wgs3mbalc0zma63wwkq11ynsyjqpr-tar-1.34/bin
PATH: /gnu/store/p6qk3h2ymdhigj6gx3c65c7wc2k0q8i7-gzip-1.12/bin
PATH: /gnu/store/kbkd0m8fjb0px9pz13gwrllradkcmzja-bzip2-1.0.8/bin
PATH: /gnu/store/a4ryn93hagc26fp8xsdkyi94d7hpjyzl-xz-5.2.8/bin
PATH: /gnu/store/igl8d889yz56bl26giwn1v7b36zx4r7y-file-5.43/bin
PATH: /gnu/store/2gk12xwwb1yv18x7xd5bbh5pnvng8pm8-diffutils-3.8/bin
PATH: /gnu/store/8hfx2m8lginhlz06ilh82mmnj8kfz7dg-patch-2.7.6/bin
PATH: /gnu/store/0vx0mpdzc0a66gb4n35aazmzzi6s26pk-findutils-4.9.0/bin
PATH: /gnu/store/q709bgiyj34rzz6ljhy6zcanwb1cfp2a-gawk-5.2.1/bin
PATH: /gnu/store/kkwqizhba1z78n5006l3bvmafjd9vgg3-sed-4.8/bin
PATH: /gnu/store/k09y6lv4vmwv0iaxma1ss0mq31khmcb3-grep-3.8/bin
PATH: /gnu/store/3n73jz0nyskrq3i14j904kqdcny4vfxb-coreutils-9.1/bin
PATH: /gnu/store/37js5dn8pgv7palgyv4yhjldfpkmwccr-make-4.3/bin
PATH: /gnu/store/bphb827vv6jrja5wyp3gj4yn1f96bm99-bash-minimal-5.1.16/bin
PATH: /gnu/store/p5yx9jliryy5bb73smhja1qvzmcm4a1l-ld-wrapper-0/bin
PATH: /gnu/store/7yy335j70z4aygpcfdbx3xq3m1bm0057-binutils-2.38/bin
PATH: /gnu/store/cyjvqbhmfl4rmdqj870lckvd8ajj5lvk-gcc-11.3.0/bin
PATH: /gnu/store/jjmhkbm1k35fqjai897c5pb6bgl20k2d-glibc-2.35/bin
PATH: /gnu/store/jjmhkbm1k35fqjai897c5pb6bgl20k2d-glibc-2.35/sbin


## --- ##
## Core tests. ##
## --- ##

configure:3056: checking build system type
configure:3070: result: x86_64-unknown-linux-gnu
configure:3090: checking host system type
configure:3103: result: i586-pc-gnu
configure:3140: checking for a BSD-compatible install
configure:3208: result: 
/gnu/store/3n73jz0nyskrq3i14j904kqdcny4vfxb-coreutils-9.1/bin/install -c
configure:3219: checking whether build environment is sane
configure:3274: result: yes
configure:: checking for i586-pc-gnu-strip
configure:3349: found 
/gnu/store/4arnacpgpn0ypdxdr587vbdg86lpyy7k-binutils-cross-i586-pc-gnu-2.38/bin/i586-pc-gnu-strip
configure:3360: result: i586-pc-gnu-strip
configure:3425: checking for a thread-safe mkdir -p
configure:3464: result: 
/gnu/store/3n73jz0nyskrq3i14j904kqdcny4vfxb-coreutils-9.1/bin/mkdir -p
configure:3471: checking for gawk
configure:3487: found 
/gnu/store/q709bgiyj34rzz6ljhy6zcanwb1cfp2a-gawk-5.2.1/bin/gawk
configure:3498: result: gawk
configure:3509: checking whether make sets $(MAKE)
configure:3535: result: no
configure:3560: checking whether make supports nested variables
configure:3577: result: yes
configure:3706: checking whether to enable maintainer-specific portions of 
Makefiles
configure:3715: result: no
User:
ABI=
CC=
CFLAGS=(unset)
CPPFLAGS=(unset)
MPN_PATH=
GMP:
abilist=32
cclist=gcc icc cc
configure:5869: i586-pc-gnu-gcc 2>&1 | grep xlc >/dev/null
configure:5872: $? = 1
configure:5926: checking compiler i586-pc-gnu-gcc -m32 -O2 -pedantic 
-fomit-frame-pointer 
Test compile: 
configure:5940: i586-pc-gnu-gcc -m32 -O2 -pedantic -fomit-frame-pointer  
conftest.c >&5
configure:5943: $? = 0
Test compile: function pointer return
configure:5994: i586-pc-gnu-gcc -m32 -O2 -pedantic -fomit-frame-pointer  
conftest.c >&5
configure:5997: $? = 0
Test compile: cmov instruction
configure:6050: i586-pc-gnu-gcc -m32 -O2 -pedantic -fomit-frame-pointer  
conftest.c >&5
configure:6053: $? = 0
Test compile: double -> ulong conversion
configure:6107: i586-pc-gnu-gcc -m32 -O2 -pedantic -fomit-frame-pointer  
conftest.c >&5
configure:6110: $? = 0
Test compile: double negation
configure:6162: i586-pc-gnu-gcc -m32 -O2 -pedantic -fomit-frame-pointer  
conftest.c >&5
configure:6165: $? = 0
Test compile: double -> float conversion

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Ludovic Courtès]

Hello!

zamfofex  skribis:

> Updating Mig required a more recent glibc than what was available in Guix at 
> the time, so I worked on  to update glibc.

Nice!

> Now that the recent glibc is on core-updates, I picked up my work once again. 
> I updated the packages to the latest commits, and updated Mig! However, I ran 
> into an issue while trying to build a system image. The issue is that GMP 
> fails to cross‐compile during the ‘configure’ phase becase the 
> cross‐compiling ‘g++’ is not functional.

Could you paste the command you used and the tail of the build log?

I tried this:

   guix time-machine --branch=core-updates -- build --target=i586-pc-gnu gmp 

… but there are too many missing substitutes at this point.  :-)

> +++ b/gnu/system.scm
> @@ -771,9 +771,7 @@ (define (hurd-default-essential-services os)
>%boot-service
>%hurd-startup-service
>%activation-service
> -  (service shepherd-root-service-type
> -   (shepherd-configuration
> -(shepherd shepherd-0.8))) ;no Fibers
> +  (service shepherd-root-service-type)

We still need ‘shepherd-0.8’ here.

Thanks,
Ludo’.

Re: GMP GCC C++ Hurd cross-build failure on core-updates

[Joshua Branson]

zamfofex  writes:

> Hello, Guix! I have been trying to update the Hurd packages to their latest
> commits in the hopes that I can eventually get networking with netdde
> functioning.
>
> In , I got something that seemed to be
> working at first (at least it progressed farther than the status quo at the
> time), but eventually I got an error that seemed related to Mig, which I had 
> not
> updated in that patch set.
>
> Updating Mig required a more recent glibc than what was available in Guix at 
> the time, so I worked on  to update glibc.
>
> Now that the recent glibc is on core-updates, I picked up my work once again. 
> I
> updated the packages to the latest commits, and updated Mig! However, I ran 
> into
> an issue while trying to build a system image. The issue is that GMP fails to
> cross‐compile during the ‘configure’ phase becase the cross‐compiling ‘g++’ is
> not functional.
>
> When checking whether ‘g++’ can compile executables during ‘configure’, ‘g++’ 
> is
> unable to link the executables because some ‘pthread_*’ symbols required by
> libstdc++ are missing from libc. And when checking using ‘readelf’, they are
> indeed missing from the cross‐built libc, which instead contains similar
> ‘__pthread_*’ symbols.
>
> I don’t know for sure what the issue is, but I highly suspect libstdc++ is 
> being
> compiled against the native glibc headers, rather than the cross‐built glibc
> headers like it should.
>

I am way out of my depth here, but would it matter that on the hurd
pthread is not in glibc?

https://lists.gnu.org/archive/html/bug-hurd/2022-10/msg00069.html

>
> Note: Currently, trying to cross‐build packages from core‐updates for the Hurd
> will fail while compiling glibc, since the Hurd package is too outdated for 
> that
> version of glibc.
>
> I’ll attach a diff (for core-updates) with the updated Hurd packages to this 
> email. To verify the behavior I’m describing, try running:
>
> - - - - -
> ./pre-inst-env guix build --target=i586-pc-gnu gmp
> - - - - -
>
> Any kind of assistance would be appreciated! Thanks in advance.

GMP GCC C++ Hurd cross-build failure on core-updates

[zamfofex]

Hello, Guix! I have been trying to update the Hurd packages to their latest 
commits in the hopes that I can eventually get networking with netdde 
functioning.

In , I got something that seemed to be 
working at first (at least it progressed farther than the status quo at the 
time), but eventually I got an error that seemed related to Mig, which I had 
not updated in that patch set.

Updating Mig required a more recent glibc than what was available in Guix at 
the time, so I worked on  to update glibc.

Now that the recent glibc is on core-updates, I picked up my work once again. I 
updated the packages to the latest commits, and updated Mig! However, I ran 
into an issue while trying to build a system image. The issue is that GMP fails 
to cross‐compile during the ‘configure’ phase becase the cross‐compiling ‘g++’ 
is not functional.

When checking whether ‘g++’ can compile executables during ‘configure’, ‘g++’ 
is unable to link the executables because some ‘pthread_*’ symbols required by 
libstdc++ are missing from libc. And when checking using ‘readelf’, they are 
indeed missing from the cross‐built libc, which instead contains similar 
‘__pthread_*’ symbols.

I don’t know for sure what the issue is, but I highly suspect libstdc++ is 
being compiled against the native glibc headers, rather than the cross‐built 
glibc headers like it should.

Note: Currently, trying to cross‐build packages from core‐updates for the Hurd 
will fail while compiling glibc, since the Hurd package is too outdated for 
that version of glibc.

I’ll attach a diff (for core-updates) with the updated Hurd packages to this 
email. To verify the behavior I’m describing, try running:

- - - - -
./pre-inst-env guix build --target=i586-pc-gnu gmp
- - - - -

Any kind of assistance would be appreciated! Thanks in advance.

hurd.diff
Description: Binary data