Re: [PATCH] support for the x32 architecture

Mattia Rizzolo <[email protected]> Tue, 28 Nov 2017 19:45:54 +0100
Newsgroups	gmane.comp.video.xine.devel
Message-ID	<[email protected]>
On Tue, Nov 28, 2017 at 06:03:39PM +0100, Torsten Jager wrote:
> 2) No such version. I guess you mean 13321:34ea545d4b88.

mh, no...

mattia@warren ..DONE/xine-lib-1.2/hg/xine-xine-lib-1.2 (hg)-[default] % hg log -r -1|cat
changeset:   13322:34ea545d4b88
tag:         tip
user:        Darren Salt <[email protected]>
date:        Sun Aug 13 00:27:57 2017 +0100
summary:     ‘color’ → ‘colour’ (and translation back for en_US).


> 4) Seems at least 1 of your cpp/gcc/gas has a bug.
>    As soon as a "operand type mismatch for" message shows up,
>    line numbers are off by at least 5. Hmm.

mhh, strange, but I wouldn't know what to look for in particular.

> 5) Found a possible scenario that can explain (almost?) all:
>    "configure" did _not_ recognize you want x32, and set
>    ARCH_X86_64 instead. "gcc" nevertheless switched to x32,
>    maybe it is the default for your sys.

clever of me of not saving the ./configure part of it as well... (and I
cleaned up the build directory in the meantime).
And yes of course, I'm using a native x32 compiler, so it defaults on
building for x32.

> "configure" relies on Autoconf to create a proper host string.
> If it is not x32 aware, trap hit right there. Next pit: there
> might be more text after "-gnux32". Tried to fix that.
> Anyway. please say
>   $ < config.log grep "host"
> and look for lines starting with "host=" and "host_alias=".
> What do they say?

For a ./configure run done without any argument:

|host='x86_64-pc-linux-gnu'
|host_alias=''
|host_cpu='x86_64'
|host_os='linux-gnu'
|host_vendor='pc'

Then I  tried configuring it with --host=x86_64-linux-gnux32
--build=x86_64-linux-gnux32:

|host='x86_64-pc-linux-gnux32'
|host_alias='x86_64-linux-gnux32'
|host_cpu='x86_64'
|host_os='linux-gnux32'
|host_vendor='pc'

And damn me, it did built just fine!

meh, pretty lame I didn't notice it and I spent hours wondering what
could be wrong with it.


I suppose this means the configure script is not clever enough though.
Consider that I'm running a regular x86-64 kernel, not sure if you're
doing checks on it (which you shouldn't, imho).

> > > Speaking of tests, It would be nice if someone could test the x32
> > > _functionality_. Your initial patch did fix x32 _build_ but actually
> > > did not care about (and possibly broke) some other assembly parts.
> 
> > Sure, do you have any suggestions on how to do it?  xine-lib doesn't
> > seem to have any testsuite in it, I would I go on properly testing it?
> 
> A test suite for a general purpose media player? Really?

heh :3

> Do you (and more importantly, hg.debian.org) have lots of harddisk
> space for test movies?

As a matter of fact, the host behind hg.debian.org (which is the same as
git.debian.org, sadly) is being decomissioned, and we are a bit
uncertain how things will turn out.  Anyway, I don't really deal with hg
myself, I'm keeping the packaging of xine-lib-1.2 in git:
https://anonscm.debian.org/git/collab-maint/xine-lib-1.2.git
(probably OT here though ^^)

> For now, you can try to
> 1) Build a sane x32 binary at all.
> 2) Set "memcpy method" to "kernel" or "SSE".
> 3) Set "audio visualzation" to "goom".
> 4) Play a sound file.

I tried to build xine-ui (debian package of it anyway) against the just
built library, and xine-ui opened up, I could select an audio file and
it started playing it.  I couldn't hear anything, probably because I'm
not running jackd... (indeed in the terminal it was giving out related
errors).  Overall I think it's working fine?


> > FWIW, in the meantime I'll see about getting version 1.2.8 in use in
> > Debian, and then will probably wait for the 1.2.9 release, as the
> > commits don't apply cleanly enough (you also did a lot of changes in the
> > indentation!) on top of 1.2.8)
> 
> You really need to recreate every single patch? Thank god I am using
> suse and not debian...

Well, I *could* take a snapshot of the hg repository and package it up,
but I don't particularly like to do it, I just prefer to use released
tarballs and add patches on top.
Were you thinking/suggesting to do that?

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
xine-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xine-devel
signature.asc (application/pgp-signature, 833 B)