FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-05-2012, 02:28 PM
"Paweł Hajdan, Jr."
 
Default packages which won't support x32

This is the case with dev-lang/v8: it doesn't build on x32
(<https://bugs.gentoo.org/423815>), and upstream said they *won't*
support x32
(<https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ>).

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ł
 
Old 10-05-2012, 06:11 PM
Davide Pesavento
 
Default packages which won't support x32

On Fri, Oct 5, 2012 at 7:28 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> This is the case with dev-lang/v8: it doesn't build on x32
> (<https://bugs.gentoo.org/423815>), and upstream said they *won't*
> support x32
> (<https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ>).
>
> 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
 
Old 10-05-2012, 06:31 PM
Rich Freeman
 
Default packages which won't support x32

On Fri, Oct 5, 2012 at 2:11 PM, Davide Pesavento <pesa@gentoo.org> 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
 
Old 10-06-2012, 03:22 AM
Ben de Groot
 
Default packages which won't support x32

On 5 October 2012 22:28, "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> wrote:
> This is the case with dev-lang/v8: it doesn't build on x32
> (<https://bugs.gentoo.org/423815>), and upstream said they *won't*
> support x32
> (<https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ>).
>
> 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
 
Old 10-06-2012, 12:33 PM
Rich Freeman
 
Default packages which won't support x32

On Fri, Oct 5, 2012 at 11:22 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 5 October 2012 22:28, "Paweł Hajdan, Jr." <phajdan.jr@gentoo.org> 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
 
Old 10-06-2012, 06:06 PM
Diego Elio Pettenò
 
Default packages which won't support x32

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 10-07-2012, 12:52 AM
"Walter Dnes"
 
Default packages which won't support x32

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 <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications
 
Old 10-07-2012, 01:05 AM
Diego Elio Pettenò
 
Default packages which won't support x32

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/
 
Old 10-07-2012, 09:14 PM
Sergei Trofimovich
 
Default packages which won't support x32

> > This is the case with dev-lang/v8: it doesn't build on x32
> > (<https://bugs.gentoo.org/423815>), and upstream said they *won't*
> > support x32
> > (<https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ>).
> >
> > 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
 
Old 10-09-2012, 09:32 PM
Mike Frysinger
 
Default packages which won't support x32

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
> (<https://bugs.gentoo.org/423815>), and upstream said they *won't*
> support x32
> (<https://groups.google.com/d/msg/v8-users/c-_URSZqTq8/7wHl095t2CMJ>).

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
 

Thread Tools




All times are GMT. The time now is 01:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org