Mailing List Archive

On 18 Jan 2016 00:49, Alex McWhirter wrote:
> On 01/17/2016 10:53 AM, Mike Frysinger wrote:
> > sure, but you said "should we not remove support for sparcv8 and
> > older". you can't drop support for them w/out breaking the
> > embedded/cross case.
>
> I guess what i meant was don't release stage3's and ISO's for older
> archs, but in reality we are already doing that as the current SPARC
> port requires sparcv9 because of the kernel.

right, i think it's fine if our releases are only sparc v9+. if anyone
actually wanted to do a release for older/embedded stuff, they can figure
things out then.

> > correct, but we don't support this case with any other arch. you don't
> > do migration between them, you pick during initial download. this is
> > why we have x86 & amd64 stage3 tarballs, s390 & s390x tarballs, ppc &
> > ppc64 stage tarballs. we'd simply have sparc & sparc64 state3 tarballs.
>
> > here's where naming gets tricky. we do not want a new KEYWORD. i think
> > ppc/ppc64 was a mistake. we don't have mips/mips64 (and mipsn32) and
> > they've been fine. same for amd64 & x32. i.e. we just treat it as a
> > new ABI. as for profiles, we can create new subdirs under sparc where
> > it makes sense. so we'd take all the sparc32-specific stuff out and
> > move it to a new subdir, and create a sparc64 subdir to hold the new
> > specific bits. profiles/arch/sparc/ - common stuff here sparc32/ -
> > sparc32 stuff here sparc64/ - sparc64 stuff here
> > profiles/default/linux/sparc/ - common stuff here sparc32/ - sparc32
> > stuff here sparc64/ - sparc64 stuff here any time a package needs to
> > change its behavior based on 32-bit/64-bit, it should be doing compile
> > time tests.
>
> That's an interesting viewpoint and adding a keyword generally creates
> more work for everyone. In the case of a single sparc profile with
> various 32bit / 64bit sub-profiles how do you handle the case of an
> application that requires 32bit and only 32bit? Wine would be a good
> example. On x86 we have use flags and a use expand for ABI_X86, and wine
> consumes that flag. However, we don't have those flags on SPARC. So
> portage is going to use whatever the ABI variable is set to regardless
> of whether it will work or not.

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.

> I am told SILO will only run in a 32bit env, but ill cross that bridge
> when i get there. But having a use flag for 32bit would make crossing
> that bridge easier to cross. Or maybe theres a better way than how AMD64
> / X86 does it?

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

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.

On 18 Jan 2016 10:57, Alex McWhirter wrote:
> On 01/18/2016 06:49 AM, Mike Frysinger wrote:
> > 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.
>
> SILO also has a few dependencies, which i've just gone ahead and set to
> compile to multilib on all sparc64 profiles.

if they're used by the silo binary, then you don't need that.
if they're used by the *.b files, then you will need that.
-mike