[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rust
From: |
Ludovic Courtès |
Subject: |
Re: Rust |
Date: |
Sat, 30 Jul 2016 15:44:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Eric Le Bihan <address@hidden> skribis:
> Le Fri, 29 Jul 2016 17:16:29 +0200,
> address@hidden (Ludovic Courtès) a écrit :
[...]
>> > Some questions, though:
>> >
>> > 1. I can compile a sample program in a guix environment created
>> > using `guix environment gcc glibc binutils rust`, but the program
>> > generated fails to run because libgcc_s.so.1 can not be found. How
>> > can it be added to the environment?
>>
>> As Andreas notes, ‘gcc-toolchain’, which includes ‘ld-wrapper’, should
>> fix this.
>
> Yes. It solved my problem.
>
>> Does Rust use GCC, or just ld?
>
> It only uses the linker, i.e. ld on GNU/Linux.
Then it should be enough to add ‘ld-wrapper’ to the inputs (no need for
‘gcc-toolchain’ or ‘gcc’.) Just make sure Rust captures the absolute
file name of ‘ld’.
> IIUC, to provide a Guix package for Cargo, the following should be done:
>
> 1. write a crate importer.
> 2. list all the crates needed by Cargo to build itself.
> 3. package each crate with the importer.
> 4. add a Cargo package which depends on the newly-imported crates and
> uses a binary version of Cargo to bootstrap itself (though this is not
> the best option in terms of auditing/reproducibility).
>
> Unlike Rust, Cargo still uses an "anonymous" binary version of itself
> for bootstrapping. I hope this may change soon.
Something along these lines, yes. We may also need a
‘rust-build-system’, like we did for other languages:
https://www.gnu.org/software/guix/manual/html_node/Build-Systems.html
If that build system works without invoking Cargo, then we probably
don’t need a Cargo binary to build Cargo.
Anyway, we’re not there yet. :-)
>> > + (add-before 'build 'pre-build
>> > + (lambda _
>> > + (let* ((bindir (string-append (getcwd)
>> > "/bin"))
>> > + (cc (string-append bindir "/cc")))
>> > + (mkdir bindir)
>> > + (call-with-output-file cc
>> > + (lambda (port)
>> > + (format port
>> > + "#!~a\n\nexec gcc
>> > \"address@hidden"\n" (which "sh"))))
>> > + (chmod cc #o755))))
>>
>> Can we avoid this trick using a configure flag
>> (--with-compiler=/path/to/gcc) or a configure or environment variable
>> (CC=gcc)? If not, that’s fine.
>
> To build the Rust standard library, only the linker is needed. The
> default value is "cc". I thought this could be overridden using the
> "--default-linker=" of the ./configure script, but it looks like it is
> not properly handled. Hence the need for the wrapper.
OK, makes sense. Please leave this explanation as a comment in the
code.
>> > + #:tests? #f))
>>
>> We normally run test suites, unless we have a good reason not to do
>> so. :-) Any ideas why “make check” fails?
>
> Out of laziness, I skipped the tests. I'll give it a look.
Let us know how it goes, even if the outcome is “too painful, giving
up”. :-)
Thanks,
Ludo’.
- Re: rust work in progress conflicts, (continued)
Re: rust work in progress conflicts, David Craven, 2016/07/29