From: Antoine Poinsot <darosior@protonmail.com>
To: "help-guix@gnu.org" <help-guix@gnu.org>
Subject: Bootstrappable Release Build of Rust Application
Date: Wed, 17 Apr 2024 10:28:51 +0000 [thread overview]
Message-ID: <l35UMCOJPQtly2iOjSkmvZunmzRIFpesb7Jyq7JpoeZb78Dl1FW3u_HU0I5BI_pfqtXB9Kbl9sihkQj0OiTxTQV8nvMoFV4XiG_La6Z0Crk=@protonmail.com> (raw)
Good morning all,
I've been working on using Guix for the reproducible builds of my Rust software. My main question is about linking my program against an older glibc version (or better yet, statically linking it against musl). But first let me give a bit of context.
We are developing a Rust software and releasing binaries. For Linux binaries we use Guix for reproducible release builds. We need to link against a reasonable glibc version to support older systems. For the past year i've been using a `guix shell` container in a `guix time-machine` in which i would `cargo rustc` my project. This allowed us to target an older glibc, at the expense of requiring compatibility with older rustc compilers. As new rustc releases are frequent (and Rust libraries tend to require bleeding edge versions of the compiler...) i knew this was only a short-term solution. Well, short term lasted a year and a half! Not bad. Now i need to do a proper Guix packaging of my Rust program.
To write the backbone of my package with the insane number of dependencies a Rust project may have, i hacked a small program which would translate a `Cargo.lock` into a `mypackage.scm`. Some of our dependencies are git repos, and surprisingly `cargo-build-system` doesn't support them correctly (they don't get unpacked in the vendor directory). This is only a small annoyance, i can package them and upload them to crates.io myself. So far so good.
Now this links against glibc 2.35. I need to target ideally 2.29 or at most 2.31. That's what i'm seeking help for. I've tried the obvious:
```
guix build -f test2.scm --with-input=glibc=glibc@2.29
```
But i immediately hit a dependency cycle on perl:
```
gnu/packages/perl.scm:106:2: error: perl@5.36.0: dependency cycle detected:
perl@5.36.0 -> linux-libre-headers@5.15.49 -> glibc@2.29 -> glibc-utf8-locales@2.35 -> coreutils@9.1 -> tar@1.34 -> perl@5.36.0 -> texinfo@6.8 -> gdb@12.1 -> rust@1.75.0 -> liana_gui@5.0.0
```
For what it's worth you can simply reproduce this with other crates. For instance trying to build the `log` crate will give the same error:
```
guix build rust-log --with-input=glibc=glibc@2.29
```
Then i've tried using `with-c-toolchain` and `make-gcc-toolchain` (not sure it would even help but i tried anyways):
```
(define gcc-toolchain-2.29
(make-gcc-toolchain gcc-7 glibc-2.29))
(package-with-c-toolchain rust-liana_gui-5.0.0 `(("toolchain" ,gcc-toolchain-2.29)))
```
This one keeps failing to compile no matter the flavour (different glibc / gcc versions). For instance for gcc-7 + glibc-2.29:
```
g++ -std=gnu++98 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/wry6srbz3wr35kdqnwyls9ypkkfq172j-glibc-2.29/lib -Wl,-dynamic
-linker -Wl,/gnu/store/wry6srbz3wr35kdqnwyls9ypkkfq172j-glibc-2.29/lib/ld-linux-x86-64.so.2 gcov-dump.o \
hash-table.o ggc-none.o\
libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-dump
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(stdexcept.o): in function `std::logic_error::~logic_error()':
(.text._ZNSt11logic_errorD2Ev+0x43): undefined reference to `__libc_single_threaded'
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(stdexcept.o): in function `std::runtime_error::~runtime_error()':
(.text._ZNSt13runtime_errorD2Ev+0x43): undefined reference to `__libc_single_threaded'
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(stdexcept.o): in function `std::logic_error::logic_error(std::string const&)':
(.text._ZNSt11logic_errorC2ERKSs+0x63): undefined reference to `__libc_single_threaded'
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(stdexcept.o): in function `std::runtime_error::runtime_error(std::string const&)':
(.text._ZNSt13runtime_errorC2ERKSs+0x63): undefined reference to `__libc_single_threaded'
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(cow-stdexcept.o): in function `_txnal_cow_string_D1_commit(void*)':
(.text._Z27_txnal_cow_string_D1_commitPv+0x13): undefined reference to `__libc_single_threaded'
ld: /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libstdc++.a(cow-stdexcept.o):(.text._ZNSt11logic_errorC2ERKS_+0x63): more undefined references to `__libc_single_threaded' follow
g++ -std=gnu++98 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -Wl,-rpath=/gnu/store/wry6srbz3wr35kdqnwyls9ypkkfq172j-glibc-2.29/lib -Wl,-dynamic
-linker -Wl,/gnu/store/wry6srbz3wr35kdqnwyls9ypkkfq172j-glibc-2.29/lib/ld-linux-x86-64.so.2 gcov-tool.o libgcov-util.o libgcov-driver-tool.o libgcov-merge-tool.o libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-tool
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:2851: gcov] Error 1
```
But anyways would this help at all to have a gcc-toolchain with an older glibc? Isn't this just building gcc against an older glibc? Would this also make cargo-build-system link against this glibc?
Finally, i've tried both with musl as well. In both cases it complains that the musl package doesn't provide a "static" output.
I'm running out of options to try here. Does anyone have any pointer on how to link against an older glibc in Guix? Is it at all supposed to be supported without using the time-machine? Is my approach misguided? Any pointer or partial answer is appreciated, even if it's only "you clearly don't understand how Guix works go read resource X and Y and come back".
Thanks,
Antoine
next reply other threads:[~2024-04-17 14:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 10:28 Antoine Poinsot [this message]
2024-04-17 15:17 ` Bootstrappable Release Build of Rust Application Philip McGrath
2024-04-18 8:07 ` Antoine Poinsot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='l35UMCOJPQtly2iOjSkmvZunmzRIFpesb7Jyq7JpoeZb78Dl1FW3u_HU0I5BI_pfqtXB9Kbl9sihkQj0OiTxTQV8nvMoFV4XiG_La6Z0Crk=@protonmail.com' \
--to=darosior@protonmail.com \
--cc=help-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.