From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6P49HO7Qp2HWqgAAgWs5BA (envelope-from ) for ; Wed, 01 Dec 2021 20:45:50 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id 8MfaF+7Qp2HzAwAAB5/wlQ (envelope-from ) for ; Wed, 01 Dec 2021 19:45:50 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 748972F621 for ; Wed, 1 Dec 2021 20:45:49 +0100 (CET) Received: from localhost ([::1]:46694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1msVY4-0000JO-GJ for larch@yhetil.org; Wed, 01 Dec 2021 14:45:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1msVPr-0000Vd-C3 for guix-devel@gnu.org; Wed, 01 Dec 2021 14:37:20 -0500 Received: from [2607:f8b0:4864:20::836] (port=39620 helo=mail-qt1-x836.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1msVPd-0000q3-GU; Wed, 01 Dec 2021 14:37:07 -0500 Received: by mail-qt1-x836.google.com with SMTP id l8so25234006qtk.6; Wed, 01 Dec 2021 11:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=VkdMGKyhZTOM6VM1j0XLMFOs32v9Vs/FCSby4VlpkoY=; b=iIHyYyYrQd7wJL6zTyfJrjVoQVukq9y//xFBB8HQ2DDq5aH4nzKPVYIaHCdlAnp0K7 VYCYys8CKa6vtRuP+g/Zi5TASzRL137jGcUWgpLbUNqLVBu8eZqJCpp9h676JIicuRRU 2DgCB76Wxe4evTbhbwraCzrPJOdBR4vfoQnQ1iQmUGSqyeyHFT2Yp3ovOnLaLvy/enpE VAuw/RXzr3vWWTiiqKDWZVClAucTNUEp+7BH0+jjYPQFjiEWkjTRwC4gla68wLz5rbkm RTlxEN4UZrmh5gxKN5uHvgUwIiqKmqo4NboeeJ+9V/HO1JVjzkNbhCLwlDgKCC8s5M6e 3nog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=VkdMGKyhZTOM6VM1j0XLMFOs32v9Vs/FCSby4VlpkoY=; b=RurZT5/tvvCWljR5rCh/MLmgTUgI6xXdp4/0HKF5sBVoUiowh66DdhG6lEfkcpfzXM w+t/zQkcaWbhfQXDGtX0NBgi1bONQ2k1u6avwnZrrUZVcBPU0UtD2i3ZbaTqTEhgJVua dz1l7P5BBtmPXy0o5ZSoHp/Yd2PyiBO+PwUoI9q0jMwR10H+NkQZbQ7I1l1fn1nK9n89 1/JgimxHW6AFmjNFkyQi4h5b6CGfVlW0Wj/slbEosUZiMbw+S/nEZxsseVYBaZ2Xqzkp nA0pDRKd/42okzcz5ZJ16tlp61/YYeIh72GuQI44zMgTnaYbyNuXhJ7BWseWhZcJKI1t MBGw== X-Gm-Message-State: AOAM533GlmhgaWlfSZi5DeZWkHEOo68pBjHau9L1z3OL+33voKfnZWTC b2YglJOFJe6KRyAgDl/rTfAjbF8pCrvMMw== X-Google-Smtp-Source: ABdhPJyEU36CkdYpj7GYJ7YwnDVwgGW0G57nIbg8MRrRX2tfJxGISq7QekxpC4mrfvAdvf2sUU49gg== X-Received: by 2002:a05:622a:4e:: with SMTP id y14mr9364060qtw.106.1638387422333; Wed, 01 Dec 2021 11:37:02 -0800 (PST) Received: from hurd (dsl-10-146-213.b2b2c.ca. [72.10.146.213]) by smtp.gmail.com with ESMTPSA id v9sm323106qkf.90.2021.12.01.11.37.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Dec 2021 11:37:01 -0800 (PST) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: Desktops on non-x86_64 systems References: <8735nh8bvw.fsf@inria.fr> <87sfvhnrm2.fsf@elephly.net> <87pmql6kug.fsf@gmail.com> <87lf196jrg.fsf@gmail.com> <874k7w9nm9.fsf@gnu.org> <87pmqghqiy.fsf@gmail.com> <87mtlkz03c.fsf@gnu.org> Date: Wed, 01 Dec 2021 14:37:00 -0500 In-Reply-To: <87mtlkz03c.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Wed, 01 Dec 2021 18:49:59 +0100") Message-ID: <87k0goazhf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::836 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::836; envelope-from=maxim.cournoyer@gmail.com; helo=mail-qt1-x836.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1638387949; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=VkdMGKyhZTOM6VM1j0XLMFOs32v9Vs/FCSby4VlpkoY=; b=lw2gwYiUd6GUB5pJDikbvi5SPa3FHxL/C0N2DZs/E10O/V/5eSrKeQZ4BpIUwUiD0aca1z HT7vitE+Y3oTpx9bN/uYr799VFeovzYRfRKFGuXBjZSiK9lTbz2hjNHV0cW6R+ttbdvWQy AzjnNlOYOwzLl26mEouZSlUTdnNO0vAyisejzBWsU1Hqnn2jmCye2eGItueLfCoJ1NPIql PLDgmKvIF07IJaHbtQ37Q+RlkaeLuav2g2Kw9RXdKILmsGLAdJHC0vL52leDVK/+yWo2hX r1zDzvFfonE95xq7/4Fztu8t6vy1HSoLgUybIYZm0Mpfgnq0oDnXVA51mIZgtA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1638387949; a=rsa-sha256; cv=none; b=CXr2+wLIaZgf/tt6AKDqkHEfpCpH7SXobDU6UrepCP/Tyr8k7ZnQzYeHI8IDWkvsFdQ5AJ SVV/KccPqGu5KvyUIXBJ1FfPyJw9FsDYAyqWNDjxxyW4AQ7h4JFS3NTH/FLcDgNSGmLamd AXlCXOoNTj6ZCeE83xcYgO+qoQ8R3Wru7gJh0FOGS7YVY2oWT85/XSGkLdZ4ylnKxmgyat PLwpZcA9U01hg1VflZj2AbYiauNT8jhywu7BlOZdwlTANUpwh1t3dPtl3s+fxV96akxG7z EvVtCapdrHHsnVBMHcfz11AQnovCO4tVTO7L9wrdpAm2V+yI0ONF5+N1xFMxDQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=iIHyYyYr; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -1.82 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=iIHyYyYr; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 748972F621 X-Spam-Score: -1.82 X-Migadu-Scanner: scn0.migadu.com X-TUID: bFtRVPdIe8qF Hi Ludovic, Ludovic Court=C3=A8s writes: > Hi! > > Maxim Cournoyer 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=E2=80=99s not possible as it would imply that i686 is able to run x86_= 64 > code. > > What we=E2=80=99d need to do is =E2=80=9Ccut the dependency graph=E2=80= =9D at the architecture > boundary, similar to what=E2=80=99s described in > . > > Concretely, we=E2=80=99d cross-build Rust for i686 once; we=E2=80=99d 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 =E2=80=98guile-bootstrap=E2=80=99 packag= e.) 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=20 // 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" sh= ortcut // This code is editable, feel free to hack it! // You can always return to the original code by clicking the "Reset" butto= n -> // 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), dynamic= ally linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=3D5458fb195357d0= 2ff6de3d429201d69c16f03e1b, for GNU/Linux 2.6.32, with debug_info, not stri= pped $ 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_inter= rupt 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_jiffi= es64.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_off= sets_now 0.04% 0.01% hello [kernel.kallsyms] [k] perf_event_task_tick 0.04% 0.01% hello [kernel.kallsyms] [k] perf_pmu_disable.par= t.92 0.04% 0.00% hello [kernel.kallsyms] [k] irq_work_interrupt 0.04% 0.00% hello [kernel.kallsyms] [k] smp_irq_work_interru= pt --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) typ= e: 0xc0008002 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-= linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) typ= e: 0xc0010001 BFD: warning: /gnu/store/miwzifnpn3lgzd6kvkcmz1i0hx7vvdfm-glibc-cross-i686-= linux-gnu-2.33/lib/../lib/libdl.so.2: unsupported GNU_PROPERTY_TYPE (5) typ= e: 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/miwzifnpn3lgzd6kvkcmz1i0hx7vvdf= m-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=3D0xb7fff584 <_rtld_global+1= 348>) 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