Re: [gentoo-dev] packages which won't support x32

[Mike Frysinger]

On Saturday 06 October 2012 21:05:14 Diego Elio Pettenò wrote:
> It's also interesting to note that
> Werner Koch of libgcrypt and gnupg fame is also not interested in
> supporting x32.

i'd say not terribly relevant considering he also finds pkg-config to be 
pointless new technology
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] packages which won't support x32

[Mike Frysinger]

On Friday 05 October 2012 10:28:45 Paweł Hajdan, Jr. wrote:
> This is the case with dev-lang/v8: it doesn't build on x32
> (), and upstream said they *won't*
> support x32
> ().

i think you misread.  they have no current plans to support it.  there are (or 
at least were) people from intel working on it, although i don't know how far 
they got.

> Note that with v8 it's not just about getting v8 itself to compile, but
> also making it generate correct JIT code on x32, which would require
> substantial changes to v8 code (in fact, a whole new 40K arch port, see
> the discussion linked to above).

i think upstream is mistaken there for various reasons.  (1) it probably makes 
no sense to try and re-use the ia32 port for x32 and (2) the x32 and x64 port 
will most likely share a vast majority of code.  after all, the entire 
register set is available to you in x32 the same as it is in x64.

> Should dev-lang/v8 get p.masked on x32 profile, or is there some better
> way to handle it?

p.mask it for now makes sense if there is no portable/C implementation we can 
fall back onto
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] packages which won't support x32

[Sergei Trofimovich]

> > This is the case with dev-lang/v8: it doesn't build on x32
> > (), and upstream said they *won't*
> > support x32
> > ().
> >
> > Note that with v8 it's not just about getting v8 itself to compile, but
> > also making it generate correct JIT code on x32, which would require
> > substantial changes to v8 code (in fact, a whole new 40K arch port, see
> > the discussion linked to above).
> >
> > Should dev-lang/v8 get p.masked on x32 profile, or is there some better
> > way to handle it? What are your suggestions?

Just mask it or port it. x32 is not user-ready yet. Only for curious devs.
Does v8 have portable non-JIT variant? Should be enough for the first time
to test/fix dependent packages.

> From what Diego wrote about it, I would say we shouldn't spend much
> time and effort on x32. I know it's the new and shiny thing, but it
> doesn't seem very useful. I think arm64/aarch64/armv8 is more
> promising, if you want to play around with a new arch.
> 
> > I had a crazy idea to just build v8 and v8-dependent packages using
> > non-x32 ABI, but I'm not sure if it's possible and if it would be the
> > right thing to do.

Not worth the effort IMO.

> If it's easy to do a kind of multilib setup, then it might be worth doing.

It's fine to have multilib with all the 3 ABIs all at once. It works today 
already.

-- 

  Sergei


signature.asc
Description: PGP signature

Re: [gentoo-dev] packages which won't support x32

[Diego Elio Pettenò]

On 06/10/2012 17:52, Walter Dnes wrote:
>   In other words, all or nothing.  An x32 distro is technically
> possible, but it would require every last single binary/library/object
> file/etc *INCLUDING PROPRIETARY PROGRAMS AND BINARY BLOBS* to be x32 and
> only, and no multilib stuff.  If amd64 did not support multilib and
> plugin-wrappers, it would be a lot less common today.

Sec, let me not be misunderstood. You can _still_ have multilib. And you
could still devise plugin wrappers. But things like nspluginwrapper
works only by chance with the design. If it was easy to do, we wouldn't
_need_ multilib to begin with.

In this case the problem is that Chrome uses v8 internally, and getting
it to use a different ABI library is likely more cumbersome than porting
and maintaining sid port.

For reference, what Ben referred to is all described in
http://blog.flameeyes.eu/tag/x32 . It's also interesting to note that
Werner Koch of libgcrypt and gnupg fame is also not interested in
supporting x32.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] packages which won't support x32

[Walter Dnes]

On Sat, Oct 06, 2012 at 11:06:04AM -0700, Diego Elio Petten?? wrote

> Nothing stops you from doing that. But if you want them to load from a
> non x32-ABI application, no way. As I said on my blog before, the big
> problem is that x32 is neither x86-64 nor x86 binary compatible (if they
> bumped x86 ABI that would have helped) so there is no way to cross-load
> or cross-call any more than you can load a 32-bit library on a 64-bit
> application or vice versa.
> 
> Of course you could build Chrome for amd64 as well. And Qt5 while you're
> at it. And KDE. And since you'll also have Skype (32-bit) you'll be
> wondering where the memory saving boasted by the ricers (on forums and
> so on) is, given that you're loading three libcs, three libssl, two Qt
> (as right now) and I don't know many more duplicates...

  In other words, all or nothing.  An x32 distro is technically
possible, but it would require every last single binary/library/object
file/etc *INCLUDING PROPRIETARY PROGRAMS AND BINARY BLOBS* to be x32 and
only, and no multilib stuff.  If amd64 did not support multilib and
plugin-wrappers, it would be a lot less common today.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] packages which won't support x32

[Diego Elio Pettenò]

On 05/10/2012 07:28, "Paweł Hajdan, Jr." wrote:
> 
> I had a crazy idea to just build v8 and v8-dependent packages using
> non-x32 ABI, but I'm not sure if it's possible and if it would be the
> right thing to do.

Nothing stops you from doing that. But if you want them to load from a
non x32-ABI application, no way. As I said on my blog before, the big
problem is that x32 is neither x86-64 nor x86 binary compatible (if they
bumped x86 ABI that would have helped) so there is no way to cross-load
or cross-call any more than you can load a 32-bit library on a 64-bit
application or vice versa.

Of course you could build Chrome for amd64 as well. And Qt5 while you're
at it. And KDE. And since you'll also have Skype (32-bit) you'll be
wondering where the memory saving boasted by the ricers (on forums and
so on) is, given that you're loading three libcs, three libssl, two Qt
(as right now) and I don't know many more duplicates...

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] packages which won't support x32

[Rich Freeman]

On Fri, Oct 5, 2012 at 11:22 PM, Ben de Groot  wrote:
> On 5 October 2012 22:28, "Paweł Hajdan, Jr."  wrote:
>> Should dev-lang/v8 get p.masked on x32 profile, or is there some better
>> way to handle it? What are your suggestions?
>
> From what Diego wrote about it, I would say we shouldn't spend much
> time and effort on x32. I know it's the new and shiny thing, but it
> doesn't seem very useful. I think arm64/aarch64/armv8 is more
> promising, if you want to play around with a new arch.

I wouldn't write it off, but the obvious thing to do for now is to
mask it.  Longer-term the cleaner solution would be to not keyword it,
assuming it takes off enough to have keywords in the first place.

If people want to work on it they will, and that's fine.  That said,
it took years for some of the big packages to be amd64-ready, and I'm
not sure x32 has nearly as much push behind it.

Rich

Re: [gentoo-dev] packages which won't support x32

[Ben de Groot]

On 5 October 2012 22:28, "Paweł Hajdan, Jr."  wrote:
> This is the case with dev-lang/v8: it doesn't build on x32
> (), and upstream said they *won't*
> support x32
> ().
>
> Note that with v8 it's not just about getting v8 itself to compile, but
> also making it generate correct JIT code on x32, which would require
> substantial changes to v8 code (in fact, a whole new 40K arch port, see
> the discussion linked to above).
>
> Should dev-lang/v8 get p.masked on x32 profile, or is there some better
> way to handle it? What are your suggestions?

>From what Diego wrote about it, I would say we shouldn't spend much
time and effort on x32. I know it's the new and shiny thing, but it
doesn't seem very useful. I think arm64/aarch64/armv8 is more
promising, if you want to play around with a new arch.

> I had a crazy idea to just build v8 and v8-dependent packages using
> non-x32 ABI, but I'm not sure if it's possible and if it would be the
> right thing to do.

If it's easy to do a kind of multilib setup, then it might be worth doing.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] packages which won't support x32

[Rich Freeman]

On Fri, Oct 5, 2012 at 2:11 PM, Davide Pesavento  wrote:
>
> Is it possible to disable the JIT engine?

Well, if you're going to wholesale disable functionality, how about
client-side rendering?  It drives me nuts as it is REALLY SLOW!!!
That is, unless the graphics hardware is local to the client (who has
that kind of configuration anyway?).

Ok, that's my tangent for the day - no need to respond - I'm one of
the 3 people who have starred it upstream, and I'll sit quiet and
watch it not happen like everybody else.  :)

Rich

Re: [gentoo-dev] packages which won't support x32

[Davide Pesavento]

On Fri, Oct 5, 2012 at 7:28 AM, "Paweł Hajdan, Jr."
 wrote:
> This is the case with dev-lang/v8: it doesn't build on x32
> (), and upstream said they *won't*
> support x32
> ().
>
> Note that with v8 it's not just about getting v8 itself to compile, but
> also making it generate correct JIT code on x32, which would require
> substantial changes to v8 code (in fact, a whole new 40K arch port, see
> the discussion linked to above).
>

Is it possible to disable the JIT engine?

> Should dev-lang/v8 get p.masked on x32 profile, or is there some better
> way to handle it? What are your suggestions?
>

Qt5 uses a forked version of v8 for QML/QtQuick. So this means that
x11-libs/qt-jsbackend:5 (available in qt overlay) and all the packages
depending on it, including qt-declarative:5 and kde, won't be
available on x32 :-/

> I had a crazy idea to just build v8 and v8-dependent packages using
> non-x32 ABI, but I'm not sure if it's possible and if it would be the
> right thing to do.
>
> Paweł
>

Thanks,
Davide

[gentoo-dev] packages which won't support x32

[Paweł Hajdan, Jr.]

This is the case with dev-lang/v8: it doesn't build on x32
(), and upstream said they *won't*
support x32
().

Note that with v8 it's not just about getting v8 itself to compile, but
also making it generate correct JIT code on x32, which would require
substantial changes to v8 code (in fact, a whole new 40K arch port, see
the discussion linked to above).

Should dev-lang/v8 get p.masked on x32 profile, or is there some better
way to handle it? What are your suggestions?

I had a crazy idea to just build v8 and v8-dependent packages using
non-x32 ABI, but I'm not sure if it's possible and if it would be the
right thing to do.

Paweł



signature.asc
Description: OpenPGP digital signature