Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Hi! > > Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > >> I've updated the branch wip-cross-built-rust; it seems to build and run >> OK (although running the binary produced by compiling hello.rs with the >> cross-built i686-linux rustc in a 32 bit VM took 47 sec (!?)), >> apparently hanging on something before outputting correctly the message >> and exiting with 0. >> >> I'd now like to figure out the top-level plumbing required to get this >> rust-i686-linux x86-64 package accepted in the real of i686-linux >> packages (cross the architecture boundary). Is this even possible in >> Guix? >> >> In other words, I'd like the i686 architecture to be able to use this >> rust-i686-linux cross built from x86_64 as if it was a *native* package. > > It’s not possible as it would imply that i686 is able to run x86_64 > code. > > What we’d need to do is “cut the dependency graph” at the architecture > boundary, similar to what’s described in > <https://guix.gnu.org/manual/devel/en/html_node/Porting.html>. > > Concretely, we’d cross-build Rust for i686 once; we’d put it in a > tarball, store it at ftp.gnu.org, and make the rust 1.54 package (or > whatever that is) be equal so that tarball, unpacked, when the current > system is i686. (Similar to the ‘guile-bootstrap’ package.) OK! Good to know that it's been done before! Thanks for the pointer. > It does mean that the cross-built Rust must be statically linked. OK. That's probably not too difficult, given the cozy relationship Rust enjoys with static linking. Where does this requirement come from though? And would we need to use something else than glibc, as IIUC it cannot be completely statically linked in the produced binaries. > To reduce the risks associated with binary blobs, the Rust build should > ideally be reproducible, so that anyone can verify that the thing we put > at ftp.gnu.org is indeed Rust as cross-compiled from x86_64. > > How long is the road ahead in your opinion? I currently have this runtime problem with the build, where the correctly compiled hello.rs program below: --8<---------------cut here---------------start------------->8--- $ cat hello.rs // This is a comment, and is ignored by the compiler // You can test this code by clicking the "Run" button over there -> // This is a comment, and is ignored by the compiler // You can test this code by clicking the "Run" button over there -> // or if you prefer to use your keyboard, you can use the "Ctrl + Enter" shortcut // This code is editable, feel free to hack it! // You can always return to the original code by clicking the "Reset" button -> // This is the main function fn main() { // Statements here are executed when the compiled binary is called // Print text to the console println!("Hello World!"); } $ time rustc hello.rs real 0m3.465s user 0m1.113s sys 0m1.217s $ file hello hello: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=5458fb195357d02ff6de3d429201d69c16f03e1b, for GNU/Linux 2.6.32, with debug_info, not stripped $ time ./hello Hello World! real 0m41.361s user 0m41.319s sys 0m0.028s --8<---------------cut here---------------end--------------->8--- 41 s to print hello world, eh. The problem seems to lie somewhere in the cross-compiled glibc, which spends lots of time on initializing libpthreads and acquiring mutexes: --8<---------------cut here---------------start------------->8--- # perf record --call-graph dwarf /path/to/hello_world # perf report --no-inline Samples: 12K of event 'cycles', Event count (approx.): 85948101927 Children Self Command Shared Object Symbol + 88.62% 0.00% hello libpthread-2.33.so [.] _init + 88.62% 11.37% hello libpthread-2.33.so [.] __pthread_initialize_minimal_internal + 41.84% 34.58% hello libpthread-2.33.so [.] __pthread_mutex_lock_full + 35.37% 35.18% hello libpthread-2.33.so [.] __pthread_mutex_lock + 11.19% 11.16% hello libpthread-2.33.so [.] __x86.get_pc_thunk.di + 7.10% 7.02% hello libpthread-2.33.so [.] __x86.get_pc_thunk.si 0.59% 0.14% hello [kernel.kallsyms] [k] apic_timer_interrupt 0.45% 0.00% hello [kernel.kallsyms] [k] smp_apic_timer_interrupt 0.35% 0.00% hello [kernel.kallsyms] [k] hrtimer_interrupt 0.28% 0.02% hello [kernel.kallsyms] [k] __hrtimer_run_queues 0.25% 0.00% hello [kernel.kallsyms] [k] tick_sched_timer 0.19% 0.00% hello [kernel.kallsyms] [k] tick_sched_handle 0.19% 0.01% hello [kernel.kallsyms] [k] update_process_times 0.16% 0.00% hello [unknown] [k] 0xf4a15ff8 0.13% 0.01% hello [kernel.kallsyms] [k] scheduler_tick 0.05% 0.01% hello [kernel.kallsyms] [k] irq_exit 0.05% 0.00% hello [kernel.kallsyms] [k] tick_sched_do_timer 0.05% 0.00% hello [kernel.kallsyms] [k] tick_do_update_jiffies64.part.12 0.05% 0.05% hello [kernel.kallsyms] [k] native_write_msr 0.04% 0.00% hello [kernel.kallsyms] [k] try_to_wake_up 0.04% 0.04% hello [kernel.kallsyms] [k] restore_all 0.04% 0.00% hello [kernel.kallsyms] [k] call_on_stack 0.04% 0.00% hello [kernel.kallsyms] [k] do_softirq_own_stack 0.04% 0.01% hello [kernel.kallsyms] [k] ktime_get_update_offsets_now 0.04% 0.01% hello [kernel.kallsyms] [k] perf_event_task_tick 0.04% 0.01% hello [kernel.kallsyms] [k] perf_pmu_disable.part.92 0.04% 0.00% hello [kernel.kallsyms] [k] irq_work_interrupt 0.04% 0.00% hello [kernel.kallsyms] [k] smp_irq_work_interrupt --8<---------------cut here---------------end--------------->8--- gdb reports: --8<---------------cut here---------------start------------->8--- (gdb) set auto-load safe-path / (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /home/user/Desktop/hello BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libpthread.so.0: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0008002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010001 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libc.so.6: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0010002 [Thread debugging using libthread_db enabled] Using host libthread_db library "/gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-linux-gnu-2.33/lib/../lib/libthread_db.so.1". ^C Program received signal SIGINT, Interrupt. 0xb7f86003 in __GI___pthread_mutex_lock (mutex=0xb7fff584 <_rtld_global+1348>) at ../nptl/pthread_mutex_lock.c:71 71 ../nptl/pthread_mutex_lock.c: No such file or directory. --8<---------------cut here---------------end--------------->8--- Perhaps this problem will resolve with static linking, but I doubt it given it has to do glibc. If we could understand/resolve this issue, I'm confident the rest would mostly be busywork, a couple evenings worth of work at most. Thank you! Maxim
