guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: i686-linux GCC package on x86_64


From: Chris Marusich
Subject: Re: i686-linux GCC package on x86_64
Date: Fri, 04 Oct 2019 21:54:09 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Danny Milosavljevic <address@hidden> writes:

> On Fri, 04 Oct 2019 17:46:43 +0200
> Jelle Licht <address@hidden> wrote:
>
>> Mathieu Othacehe <address@hidden> writes:
>> 
>> >
>> > --8<---------------cut here---------------start------------->8---
>> >     (native-inputs
>> >      `(,@(if (not (string-prefix? "i686" (%current-system)))
>> >            `(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
>> >              ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
>> >            '())))
>> > --8<---------------cut here---------------end--------------->8---
>> >
>> > that uses the current gcc if you're already building on an i686 system,
>> > or define and use a cross-gcc targeting i686 systems otherwise.  
>> 
>> This snippet might make a lot of sense to seasoned schemers/guixfolk,
>
> Basically just ignore the birdshit characters to understand what it does :)
>
> The first unquote is to evaluate (%current-system) at the toplevel which is
> what interprets the package definitions in the first place.
>
> "`(,@" is a no-op.  Not sure why it's written like that.
>
>>            `(("cross-gcc" ,(cross-gcc "i686-unknown-linux-gnu"))
>>              ("cross-binutils" ,(cross-binutils "i686-unknown-linux-gnu")))
>
> is like we always write inputs, but it's calling the "cross-gcc" function in 
> the
> toplevel in order to get the package to use.

Perhaps it's because of the "if" expression.

>> with the multiple levels of (un)quoting and what not. It does not seem
>> like what somebody with little experience in either would think of by
>> themselves.
>> 
>> Would it make sense to have a section/stub in the cookbook about cross
>> compilation?
>
> I don't think that cross-gcc is stable API that much--and it's not
> common that you need it anyway.  A normal user just cross compiles
> by using
>
>    guix build --target=i686-linux pkg
>
> or better yet, uses qemu to natively compile it for a foreign system
>
>    guix build --system=i686-linux pkg
>
> .
>
> The above is only necessary when for some reason your package has
> parts which only compile on one system and other parts which only
> compile on another system--that's very rare.
>
> Nowadays, packages are supposed to be cross-platform, so using cross-gcc
> directly is unnecessary, too.
>
> Right now cross-gcc is not documented, so I guess that counts as
> "not a public interface".

Yeah.  I'm inclined to agree with Danny.  With Guix, it is best to
cross-compile in the way Danny is suggesting.  If there are projects
that require other tricks to cross-compile, perhaps they would be
interesting to discuss.  I feel like there may be a lot of "quick and
dirty" projects with non-standard build logic that can't easily be
packaged into Guix for cross-compilation.

That said, I am curious about something.  If I want to make a
cross-compiler available for the purpose of hacking around on some code
and cross-compiling it, is there an equivalent to "guix package -i
gcc-toolchain" which will give me a cross-compilation toolchain?  My
feeling was that Guix can create cross-compilation toolchains on demand,
but there is no UI exposed for making it available via a guix command,
since people are encouraged to just ask for the cross-built product.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]