From: Alex McWhirter <alexmcwhirter@triadic.us>
To: gentoo-sparc@lists.gentoo.org
Subject: Re: [gentoo-sparc] Pure SPARC64 Port (Was Re: Sparc64 OpenSSL)
Date: Mon, 18 Jan 2016 10:57:59 -0500 [thread overview]
Message-ID: <569D0B87.70805@triadic.us> (raw)
In-Reply-To: <20160118114945.GP4894@vapier.lan>
On 01/18/2016 06:49 AM, Mike Frysinger wrote:
> correct -- we will want to add ABI flags for sparc32/sparc64 like we have
> for ppc32/ppc64 and s390/s390x and such. just grep for "abi_s390_32" in
> the tree to see what kind of setup we'd need.
>
> then it's simply a matter of masking out the few odd packages that do not
> work in a 64-bit env via the profile's package.mask file.
Just finished that up this morning. I was under the impression that
packages had to consume use flags in order for them to be applied. Thats
probably true for normal flags, but the ABI flags seem to different. I
also setup an ABI_SPARC use expand.
> the x86/amd64 way seems fine to me. in a multilib setup, they can build
> the 32-bit version directly. in a non-multilib setup, there's the static
> grub ebuild. so we can also add a silo-static that is simply built using
> the latest silo-from-source.
>
> keep in mind though that the toolchain is biarch. that means a sparc32
> userland can produce sparc64 object code even if it doesn't have any of
> the 64-bit libraries/headers. same goes for sparc64 userland and sparc32
> code. the reason this matters is that (afaik) most of the silo package
> is the /boot/*.b files which need to be 32-bit. but the silo program can
> still be 64-bit, or at least i assume we can make it work. so even under
> a pure 64-bit (and no multilib) system, we might be able to build silo as
> we use -m32 to compile the *.b files.
>
> this is also how you can build a 64-bit linux kernel image using a 32-bit
> toolchain. the kernel will add -m64 everywhere for you.
> -mike
SILO also has a few dependencies, which i've just gone ahead and set to
compile to multilib on all sparc64 profiles. If anyone wants to track
the status of this i have a fork of the portage tree on my github.
https://github.com/TriadicTek/TriOS
The new profile structure symlinks to the old profile structure as well
the the experimental multilib profile. Anyone currently using the sparc
port should be able to migrate to it without any issues.
So far i have successfully built stage1's for sparc32, sparc32-multilib,
sparc64, and sparc64-multilib. Working on stage2's now.
next prev parent reply other threads:[~2016-01-18 15:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <569A305F.5090208@triadic.us>
[not found] ` <20160116184935.GG4894@vapier.lan>
[not found] ` <569B07EB.2090901@triadic.us>
[not found] ` <20160117084239.GI4894@vapier.lan>
[not found] ` <569B8CBD.3010304@triadic.us>
[not found] ` <20160117155314.GK4894@vapier.lan>
2016-01-18 5:49 ` [gentoo-sparc] Pure SPARC64 Port (Was Re: Sparc64 OpenSSL) Alex McWhirter
2016-01-18 11:49 ` Mike Frysinger
2016-01-18 15:57 ` Alex McWhirter [this message]
2016-01-18 19:27 ` Mike Frysinger
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=569D0B87.70805@triadic.us \
--to=alexmcwhirter@triadic.us \
--cc=gentoo-sparc@lists.gentoo.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox