Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 20 August 2014 22:57:31 Wookey wrote:
> +++ Lisandro Damián Nicanor Pérez Meyer [2014-08-16 12:02 -0300]:
[snip]
> The kernel calls it 'arm64' and so does Apple in their webkit patches,
> so we are not the only ones, but aarch64 is often used internally, as
> despite being a silly name is at least easily identiifed as unique.

That's excelent data, specially because I decided to go with all the patch 
(using both aarch64/arm64).

Thanks!


-- 
"No es el crecimiento de la tecnología lo que excluye, sino la
protección sistemática de los derechos de uso de la misma,
lo cual se puede aplicar al arte."
  David Cuartielles

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Wookey]

+++ Lisandro Damián Nicanor Pérez Meyer [2014-08-16 12:04 -0300]:
> WRT the mkspecs changes I am currently asking upstream if adding an mkspec 
> just for getting rid of -m64 is the right way to go. Maybe we can add an 
> exception somewhere without the need of adding another mkspec.

Yes. I think that can be done better. I didn't add that mkspec :-)

I suspect it can be removed, but I don't know the codebase well enough
to decide exctly how.

-m64 is bad practice anyway IMHO. Compilers should use -gcc
 everywhere and it would just work, and be unambiguous, instead of
 various different flags for 'some other multilib' on various
 compilers/cross-compilers. Sadly it's probably too ingrained to get
 rid of on x86.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Saturday 16 August 2014 11:35:10 Lisandro Damián Nicanor Pérez Meyer wrote:
> I have a doubt: why do you disable javascript-jit for arm64? Should this be
> happening in other archs? Because I have not received any bug reports wrt
> this yet.

I have already asked you this before and you replied, sorry for that.

AFAIU it is not needed in Debian's qt4-x11 because we are not building webkit 
from this source but from qtwebkit.

That being said, all the patches have been respined upstream, including your 
change to configure. Part of them have been already merged upstream.

Except for the qatomic one the rest has a nice chance to get accepted.

The big patch you sent us also has some changes for qtwebkit, but as we are 
near to updating it I think it would be better to wait until we have qt4-x11 
built on arm64 and then take alook at the current qtwebkit at that time.

-- 
"In college, I cooked some hot dogs by putting metal forks in each end of the
hot dog and running 120 volts through it. Hot dogs have just enough
conductivity so that this works well"
  greenroom(576281) - on a truly geeky way to cook hot dogs.
  Posted in Slashdot, also found in The Open Source Cookbook for Geeks.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 15 August 2014 22:05:44 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip] 
> > OK. So I've brought the atomic queries to the attention of Steve
> > Capper, who understands this stuff. He observed that the memory
> > barriers are not the right type. They'll work (as they are the 'mos
> > expensive' type) but will be slower than is necessary. Hopefully he'll
> > find time to have a look at that reasonably soon, but he's a busy man
> > at the moment.
> 
> To be honest this is not what I remember, IIRC they will not work. But I'll
> double check the comments upstream did to the patches.

[snip] 

> Please allow me to recheck the assertion wrt the atomic stuff. If I'm
> remembering right and the atomics did pose some problems then we would have
> an instant RC bug. And if this is true and arm64 becomes a release arch we
> Qt maintainers have a bug we can't fix ourselves, not to mention we would
> be doing a disservice to our users.
> 
> Now if the atomics are really not such a big problem count on me with the
> patching

I've been told by upstream that they just don't know so I'll go ahead with the 
atomics patches. Let's just not forget that qt4 will be slower than necessary 
with this.

I'll try to do my best and push the changes during saturday argentinian time.

-- 
If little green men land in your back yard, hide any little green women
you've got in the house.
  Mike Harding, "The Armchair Anarchist's Almanac"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

WRT the mkspecs changes I am currently asking upstream if adding an mkspec 
just for getting rid of -m64 is the right way to go. Maybe we can add an 
exception somewhere without the need of adding another mkspec.

-- 
20:57  * m4rgin4l patento el proceso de invencion
20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar
regalias por inventar algo
20:57  * m4rgin4l tiene la patente pendiente del metodo cientifico

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

WRT the mkspecs changes I am currently asking upstream if adding an mkspec 
just for getting rid of -m64 is the right way to go. Maybe we can add an 
exception somewhere without the need of adding another mkspec.

-- 
20:57  * m4rgin4l patento el proceso de invencion
20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar
regalias por inventar algo
20:57  * m4rgin4l tiene la patente pendiente del metodo cientifico

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Friday 15 August 2014 23:46:19 Wookey wrote:
[snip] 
> In an attempt to solve the -fpermissive thing, I updated the patches
> for the current qt4-x11 package to try and get an example build log
> (without -fpermissive) to wave at people who grokked C++ and
> arm64. This involved some tweaking of the arch/ABI identification
> logic wich was bust and by using dpkg_arch ('arm64') in place of uname
> -m ('aarch64') then checking for arm* later, it incorrectly identified
> the ABI as 'arm' and tried to build wrong assembler. So I've fixed
> that up to not use the hacky mechanism and re-order the checks/extend
> the regeps so both arm64 and aarch64 end up pointing at QTs internel
> 'aarch64', and other arm* names refer to QTs internal 'arm'.

Part of this can be upstreamed (will do so) and a little part (the one that 
adds arm64) will need to be kept as a Debian (and probably Ubuntu) delta, as 
we seem the only ones using that name for aarch64.

-- 
Lo que me sorprende de las mujeres es que se arrancan los pelos desde
la raíz con cera caliente y aún así le temen a las arañas.
  Jerry Seinfeld

lis: comentario sobre tu frase
yo soy mujer, yo me arranco los pelos y VOS le tenes miedo a las arañas
  María Luján Pérez Meyer (mi hermana)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

I have a doubt: why do you disable javascript-jit for arm64? Should this be 
happening in other archs? Because I have not received any bug reports wrt this 
yet.

-- 
La mejor prueba de que la navegación en el tiempo no es posible, es el hecho
de no haber sido invadidos por masas de turistas provenientes del futuro.
  Stephen Hawking

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Wookey]

+++ Lisandro Damián Nicanor Pérez Meyer [2014-08-15 22:05 -0300]:
> I was really expecting this mail :)
> 
> First of all, allow me to congratulate you an the rest of the arm64 porters 
> for it's inclusion in the archive :)

Cheers. We're making good progress there.
 
> This is a "quick and dirty" mail to let you know that I'm looking at this, 
> but 
> please give me some time to check this facts. Tip: I'm not currently very 
> available, so it might take me time, although some of my team mates might 
> show 
> up too.

Cheers. I am at bootstrap sprint for next 4 days. Then debconf 3 days after 
that.

> On Friday 15 August 2014 23:46:19 Wookey wrote:
> [snip] 
> > OK. So I've brought the atomic queries to the attention of Steve
> > Capper, who understands this stuff. He observed that the memory
> > barriers are not the right type. They'll work (as they are the 'mos
> > expensive' type) but will be slower than is necessary. Hopefully he'll
> > find time to have a look at that reasonably soon, but he's a busy man
> > at the moment.
> 
> To be honest this is not what I remember, IIRC they will not work. But I'll 
> double check the comments upstream did to the patches.

OK. Steve was planning to comment there too.

> > In an attempt to solve the -fpermissive thing, I updated the patches
> > for the current qt4-x11 package to try and get an example build log
> > (without -fpermissive) to wave at people who grokked C++ and
> > arm64. This involved some tweaking of the arch/ABI identification
> > logic wich was bust and by using dpkg_arch ('arm64') in place of uname
> > -m ('aarch64') then checking for arm* later, it incorrectly identified
> > the ABI as 'arm' and tried to build wrong assembler. So I've fixed
> > that up to not use the hacky mechanism and re-order the checks/extend
> > the regeps so both arm64 and aarch64 end up pointing at QTs internel
> > 'aarch64', and other arm* names refer to QTs internal 'arm'.
> > 
> > And now it seems that the -fpermissive problem has gone away. The
> > package builds without -fpermissive on arm64 (maybe updated compiler,
> > maybe updated sources, maybe updated something else - who knows?
> 
> 
> \o/ I skimmed trough the patch an indeed it seems sensible. Moreover, it has 
> high chances of getting upstreamed. Did you do this part of the patch (namely 
> the part that touches configure)?

Yes. I hereby licence my (minor changes to existing work) under BSD or expat.
 
> You know that I would *love* to get this upstreamed but in order to do so I 
> need to:
> 
> a) in case the patch is really simple or not really copyrighteable I might 
> push it directly. But it is much much better if at least I can write down who 
> the original coder was.

I just adjusted the existing configure stuff so it was right. I
removed 3 lines, swapped position of 4 lines and changed a regexp. I
don't think that's copyrightable, and you already have suitable
licence on the previous patch.

> b) In the case the patch is copyrighteable (ie, just not a couple of 
> "obvious" 
> changes) I need to find the original coder and convince him/her to either:
> 
>   b1) push the patch him/herself to upstream's gerrit instance (preferred 
> because it allows upstream to make questions or ask for changes directly to 
> the people who code them).
> 
>   b2) publicly announce (could be a mail to this very same bug, a gined mail 
> is a plus) that the patch is licensed with a permissive enough license like 
> some BSD one. The downside of this approach is that in case upstream finds 
> something they don't like I need to be a proxy between them.
> 
> I would really *love* if you can help me with this, as I don't know exactly 
> who did what (I might infer some of that data from the previous splitted 
> patches).

I just took the previous patch and made above changes. 

> > Anyway I guess we can call it fixed until we see evidence otherwise.
> 
> Definitely.
> 
> > Attached is current patch (obviously with atomics stuff unchanged)
> > 
> > (The nice neat separated patches did not work for me and I've not had
> > time to separate this one out into nice pieces, sorry).
> 
> No problem, I'll take care of it.
> 
> > Can we upload this so we at least have a working package in the
> > archive (which will very soon be needed by our nice new official
> > buildds), and refine the atomics patch for upstreaming in due course?
> 
> Please allow me to recheck the assertion wrt the atomic stuff. If I'm 
> remembering right and the atomics did pose some problems then we would have 
> an 
> instant RC bug. And if this is true and arm64 becomes a release arch we Qt 
> maintainers have a bug we can't fix ourselves, not to mention we would be 
> doing a disservice to our users.
> 
> Now if the atomics are really not such a big problem count on me with the 
> patching, but please help me identifying who did which part of them. We 
> really 
> want this upstreamed.

I hope I've provided enough info for that above. Bug me more if

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

I was really expecting this mail :)

First of all, allow me to congratulate you an the rest of the arm64 porters 
for it's inclusion in the archive :)

This is a "quick and dirty" mail to let you know that I'm looking at this, but 
please give me some time to check this facts. Tip: I'm not currently very 
available, so it might take me time, although some of my team mates might show 
up too.

On Friday 15 August 2014 23:46:19 Wookey wrote:
[snip] 
> OK. So I've brought the atomic queries to the attention of Steve
> Capper, who understands this stuff. He observed that the memory
> barriers are not the right type. They'll work (as they are the 'mos
> expensive' type) but will be slower than is necessary. Hopefully he'll
> find time to have a look at that reasonably soon, but he's a busy man
> at the moment.

To be honest this is not what I remember, IIRC they will not work. But I'll 
double check the comments upstream did to the patches.


> In an attempt to solve the -fpermissive thing, I updated the patches
> for the current qt4-x11 package to try and get an example build log
> (without -fpermissive) to wave at people who grokked C++ and
> arm64. This involved some tweaking of the arch/ABI identification
> logic wich was bust and by using dpkg_arch ('arm64') in place of uname
> -m ('aarch64') then checking for arm* later, it incorrectly identified
> the ABI as 'arm' and tried to build wrong assembler. So I've fixed
> that up to not use the hacky mechanism and re-order the checks/extend
> the regeps so both arm64 and aarch64 end up pointing at QTs internel
> 'aarch64', and other arm* names refer to QTs internal 'arm'.
> 
> And now it seems that the -fpermissive problem has gone away. The
> package builds without -fpermissive on arm64 (maybe updated compiler,
> maybe updated sources, maybe updated something else - who knows?


\o/ I skimmed trough the patch an indeed it seems sensible. Moreover, it has 
high chances of getting upstreamed. Did you do this part of the patch (namely 
the part that touches configure)?

You know that I would *love* to get this upstreamed but in order to do so I 
need to:

a) in case the patch is really simple or not really copyrighteable I might 
push it directly. But it is much much better if at least I can write down who 
the original coder was.

b) In the case the patch is copyrighteable (ie, just not a couple of "obvious" 
changes) I need to find the original coder and convince him/her to either:

  b1) push the patch him/herself to upstream's gerrit instance (preferred 
because it allows upstream to make questions or ask for changes directly to 
the people who code them).

  b2) publicly announce (could be a mail to this very same bug, a gined mail 
is a plus) that the patch is licensed with a permissive enough license like 
some BSD one. The downside of this approach is that in case upstream finds 
something they don't like I need to be a proxy between them.

I would really *love* if you can help me with this, as I don't know exactly 
who did what (I might infer some of that data from the previous splitted 
patches).

> Anyway I guess we can call it fixed until we see evidence otherwise.

Definitely.

> Attached is current patch (obviously with atomics stuff unchanged)
> 
> (The nice neat separated patches did not work for me and I've not had
> time to separate this one out into nice pieces, sorry).

No problem, I'll take care of it.

> Can we upload this so we at least have a working package in the
> archive (which will very soon be needed by our nice new official
> buildds), and refine the atomics patch for upstreaming in due course?

Please allow me to recheck the assertion wrt the atomic stuff. If I'm 
remembering right and the atomics did pose some problems then we would have an 
instant RC bug. And if this is true and arm64 becomes a release arch we Qt 
maintainers have a bug we can't fix ourselves, not to mention we would be 
doing a disservice to our users.

Now if the atomics are really not such a big problem count on me with the 
patching, but please help me identifying who did which part of them. We really 
want this upstreamed.

JFTR, I have already asked upstream about this in 


Kinds regards, Lisandro.

-- 
12: Es posible insertar imagenes en los documentos y archivos al
trabajar con Word
* No o Si
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Wookey]

Package: src:qt4-x11
Followup-For: Bug #735488


OK. So I've brought the atomic queries to the attention of Steve
Capper, who understands this stuff. He observed that the memory
barriers are not the right type. They'll work (as they are the 'mos
expensive' type) but will be slower than is necessary. Hopefully he'll
find time to have a look at that reasonably soon, but he's a busy man
at the moment.

In an attempt to solve the -fpermissive thing, I updated the patches
for the current qt4-x11 package to try and get an example build log
(without -fpermissive) to wave at people who grokked C++ and
arm64. This involved some tweaking of the arch/ABI identification
logic wich was bust and by using dpkg_arch ('arm64') in place of uname
-m ('aarch64') then checking for arm* later, it incorrectly identified
the ABI as 'arm' and tried to build wrong assembler. So I've fixed
that up to not use the hacky mechanism and re-order the checks/extend
the regeps so both arm64 and aarch64 end up pointing at QTs internel
'aarch64', and other arm* names refer to QTs internal 'arm'.

And now it seems that the -fpermissive problem has gone away. The
package builds without -fpermissive on arm64 (maybe updated compiler,
maybe updated sources, maybe updated something else - who knows?

Anyway I guess we can call it fixed until we see evidence otherwise.

Attached is current patch (obviously with atomics stuff unchanged)

(The nice neat separated patches did not work for me and I've not had
time to separate this one out into nice pieces, sorry). 

Can we upload this so we at least have a working package in the
archive (which will very soon be needed by our nice new official
buildds), and refine the atomics patch for upstreaming in due course?

-- 
Wookey
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog	2014-07-25 17:07:51.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/changelog	2014-08-14 11:25:08.0 +
@@ -1,3 +1,10 @@
+qt4-x11 (4:4.8.6+git49-gbc62005+dfsg-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Add arm64/aarch64 support
+
+ -- Wookey   Thu, 14 Aug 2014 11:24:00 +
+
 qt4-x11 (4:4.8.6+git49-gbc62005+dfsg-1) unstable; urgency=medium
 
   * New upstream GIT snapshot.
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install	2014-07-25 16:54:39.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/libqt4-dev.install	2014-08-15 10:19:56.0 +
@@ -161,6 +161,7 @@
 usr/include/qt4/Qt/qanimationgroup.h
 usr/include/qt4/Qt/qapplication.h
 usr/include/qt4/Qt/qatomic.h
+usr/include/qt4/Qt/qatomic_aarch64.h
 usr/include/qt4/Qt/qatomic_alpha.h
 usr/include/qt4/Qt/qatomic_arch.h
 usr/include/qt4/Qt/qatomic_arm.h
@@ -1345,6 +1346,7 @@
 usr/include/qt4/QtCore/qalgorithms.h
 usr/include/qt4/QtCore/qanimationgroup.h
 usr/include/qt4/QtCore/qatomic.h
+usr/include/qt4/QtCore/qatomic_aarch64.h
 usr/include/qt4/QtCore/qatomic_alpha.h
 usr/include/qt4/QtCore/qatomic_arch.h
 usr/include/qt4/QtCore/qatomic_arm.h
diff -Nru qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch
--- qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch	1970-01-01 00:00:00.0 +
+++ qt4-x11-4.8.6+git49-gbc62005+dfsg/debian/patches/aarch64.patch	2014-08-15 10:36:18.0 +
@@ -0,0 +1,619 @@
+Index: qt4-x11-4.8.6+git49-gbc62005+dfsg/configure
+===
+--- qt4-x11-4.8.6+git49-gbc62005+dfsg.orig/configure
 qt4-x11-4.8.6+git49-gbc62005+dfsg/configure
+@@ -2856,6 +2856,9 @@ if [ "$CFG_EMBEDDED" != "no" ]; then
+ *86_64)
+ PLATFORM=qws/linux-x86_64-g++
+ ;;
++aarch64)
++PLATFORM=linux-g++-aarch64
++;;
+ *)
+ PLATFORM=qws/linux-generic-g++
+ ;;
+@@ -3289,18 +3292,18 @@ if [ -z "${CFG_HOST_ARCH}" ]; then
+ 	fi
+ 	CFG_HOST_ARCH=s390
+ 	;;
+-*:*:arm*)
+-if [ "$OPT_VERBOSE" = "yes" ]; then
+-echo "ARM (arm)"
+-fi
+-CFG_HOST_ARCH=arm
+-;;
+-*:*:aarch64*)
++*:*:aarch64*|*:*:arm64*)
+ if [ "$OPT_VERBOSE" = "yes" ]; then
+ echo "AArch64 (aarch64)"
+ fi
+ CFG_HOST_ARCH=aarch64
+ ;;
++*:*:arm*)
++if [ "$OPT_VERBOSE" = "yes" ]; then
++echo "ARM (arm)"
++fi
++CFG_HOST_ARCH=arm
++	;;
+ Linux:*:sparc*)
+ if [ "$OPT_VERBOSE" = "yes" ]; then
+ echo "Linux on SPARC"
+Index: qt4-x11-4.8.6+git49-gbc62005+dfsg/mkspecs/linux-g++-aarch64/qmake.conf
+===

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Thursday 16 January 2014 00:16:03 Wookey wrote:
[snip]
> The whole log is 2.5MB. Want it all? A useful excerpt is attached.

I've taken a look at the excerpt and checked with the team. We will need a 
proper fix without ussing -fpermissive. In the example from the build log, we 
might get strange crashes in qtscript if something goes wrong.


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

Dmitry Shachnev points me at [0], it makes things easier :)

[0] 


-- 
I still maintain the point that designing a monolithic kernel in 1991 is a
fundamental error.  Be thankful you are not my student.  You would not get a
high grade for such a design :-)
(Andrew Tanenbaum to Linus Torvalds)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 15 January 2014 16:42:42 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Wednesday 15 January 2014 15:57:47 Lisandro Damián Nicanor Pérez Meyer
> 
> wrote:
> > On Wednesday 15 January 2014 15:30:51 Lisandro Damián Nicanor Pérez Meyer
> 
> [snip]
> 
> > > > 1) It uses autotools-dev and the dh_ helpers to ensure
> > > > config.{sub,guess}
> > > > are up to date rather than patching them directly. This is cleaner,
> > > > will
> > > > keep working in the future, and allows rebuilds as the clean target
> > > > works
> > > > correctly.
> > > 
> > > This part I like it, I'll try to test it soon.
> > 
> > On a second thought, I don't even know if they are used at all. I think
> > all
> > 3rd party stuff is being built using qmake, but I might be wrong (or
> > confused with Qt5).
> 
> I'm currently testing this.

I've patched out the autotools helpers files, recompiled and everything went 
OK. I have also taken a look at the builded stuff and they seem not to be used 
at all. Moreover, we are building against the system version of the involved 
libs, but better double check.

I've just added lintian oveerides with an explanation of the issue.

I'll be taking a look at the rest as time permits.

Kinds regards, Lisandro.

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity.
  Dennis Ritchie

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 15 January 2014 15:57:47 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Wednesday 15 January 2014 15:30:51 Lisandro Damián Nicanor Pérez Meyer
[snip]
> > > 1) It uses autotools-dev and the dh_ helpers to ensure
> > > config.{sub,guess}
> > > are up to date rather than patching them directly. This is cleaner, will
> > > keep working in the future, and allows rebuilds as the clean target
> > > works
> > > correctly.
> > 
> > This part I like it, I'll try to test it soon.
> 
> On a second thought, I don't even know if they are used at all. I think all
> 3rd party stuff is being built using qmake, but I might be wrong (or
> confused with Qt5).

I'm currently testing this.

On the other hand, mitya57 has asked doko and it seems that the original code 
comes from a Red hat employee who signed Qt's CLA. And maybe even this is code 
that comes from Qt5 itself. If this is the case, specially the last one, then 
things are much easier.


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 15 January 2014 18:17:19 Wookey wrote:
> Source: qt4-x11
> Version: 4.8.5
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertag: arm64
> 
> This package fails to build on arm64 without this patch. It is largely
> based on the ubuntu patches in  4:4.8.4+dfsg-0ubuntu15,
> 4:4.8.4+dfsg-0ubuntu17, and the important fix in
> 4:4.8.4+dfsg-0ubuntu18), but has a few changes.

[snip]

> 2) It uses linux-g++ PLATFORM and adds the -fpermissive CFLAG to enable
> it to build rather than defining a new almost-identical
> linux-g++-aarch64 PLATFORM because that seems to be unnecessary and less
> clean. However I am no QT expert so there may be a good reason for doing
> it the other way. I have left that definition file in so you can see
> what was done, but so far as I can see the linux-g++ definitions are
> correct. A look at why -fpermissive is needed might be a good thing, but
> is beyond my ken.

OK, I have taken a look at this. Indeed defining a new mkspec *just* for arm64 
doesn't sounds right at all.

WRT the fpermissive, well, I would need to see which errors are being 
triggered without that flag. Do you have an arm64 build log without -
fpermissive at hand? Else, are you able to create one for seeing what's going 
on?

= JIT stuff: except for the stuff in debian/rules, it is actually conflicting 
with other patches we are currently having in that respect:

rejects in file src/3rdparty/webkit/Source/JavaScriptCore/wtf/Platform.h

But I have modified those already so there is nothing to fear there, it's a 
simple matter of touching the current patches.

Kinds regards, Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 15 January 2014 15:30:51 Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Wednesday 15 January 2014 18:17:19 Wookey wrote:
> > Source: qt4-x11
> > Version: 4.8.5
> > Severity: normal
> > Tags: patch
> > User: debian-...@lists.debian.org
> > Usertag: arm64
> > 
> > This package fails to build on arm64 without this patch. It is largely
> > based on the ubuntu patches in  4:4.8.4+dfsg-0ubuntu15,
> > 4:4.8.4+dfsg-0ubuntu17, and the important fix in
> > 4:4.8.4+dfsg-0ubuntu18), but has a few changes.
> > 
> > 1) It uses autotools-dev and the dh_ helpers to ensure config.{sub,guess}
> > are up to date rather than patching them directly. This is cleaner, will
> > keep working in the future, and allows rebuilds as the clean target works
> > correctly.
> 
> This part I like it, I'll try to test it soon.

On a second thought, I don't even know if they are used at all. I think all 
3rd party stuff is being built using qmake, but I might be wrong (or confused 
with Qt5).

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 15 January 2014 18:17:19 Wookey wrote:
> Source: qt4-x11
> Version: 4.8.5
> Severity: normal
> Tags: patch
> User: debian-...@lists.debian.org
> Usertag: arm64
> 
> This package fails to build on arm64 without this patch. It is largely
> based on the ubuntu patches in  4:4.8.4+dfsg-0ubuntu15,
> 4:4.8.4+dfsg-0ubuntu17, and the important fix in
> 4:4.8.4+dfsg-0ubuntu18), but has a few changes.
> 
> 1) It uses autotools-dev and the dh_ helpers to ensure config.{sub,guess}
> are up to date rather than patching them directly. This is cleaner, will
> keep working in the future, and allows rebuilds as the clean target works
> correctly.

This part I like it, I'll try to test it soon.

> 2) It uses linux-g++ PLATFORM and adds the -fpermissive CFLAG to enable
> it to build rather than defining a new almost-identical
> linux-g++-aarch64 PLATFORM because that seems to be unnecessary and less
> clean. However I am no QT expert so there may be a good reason for doing
> it the other way. I have left that definition file in so you can see
> what was done, but so far as I can see the linux-g++ definitions are
> correct. A look at why -fpermissive is needed might be a good thing, but
> is beyond my ken.

I'll take a look.

> 3) The ubuntu patch disabled the docs build, but that is now working
> correctly so no need for that any more.
> 
> This is obviously an important package in the bootstrap so I hope this
> patch can go in the archive reasonably soon. Obviously I am happy to
> answer questions  if you have any queries about what is correct for the
> arm64/aarch64 build.

If it where just patches to debian/* stuff I would have really no problem. But 
as this patches touches upstream's stuff like 
src/corelib/arch/qatomic_aarch64.h , configure, qmake.conf et al, we ask first 
for an upstream's ACK. But to do this the **author** of the changes needs to 
push the patches to gerrit and get it either accepted into the Qt4 tree or at 
least ACKed by upstream (because maybe they don't want to extend the 
funcionality of Qt 4 anymore).

As we have gerrit in the middle (and so the Qt CLA) I'm not able to forward 
the patches anymore.

If the author pushes the patches to gerrit please tell him/her to add me as 
reviewer, same for the bug she(he could fill to get attention on it.

Kinds regards, Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#735488: qt4-x11: Add arm64 support

[Wookey]

Source: qt4-x11
Version: 4.8.5
Severity: normal
Tags: patch
User: debian-...@lists.debian.org
Usertag: arm64

This package fails to build on arm64 without this patch. It is largely
based on the ubuntu patches in  4:4.8.4+dfsg-0ubuntu15,
4:4.8.4+dfsg-0ubuntu17, and the important fix in
4:4.8.4+dfsg-0ubuntu18), but has a few changes.

1) It uses autotools-dev and the dh_ helpers to ensure config.{sub,guess}
are up to date rather than patching them directly. This is cleaner, will
keep working in the future, and allows rebuilds as the clean target works
correctly.

2) It uses linux-g++ PLATFORM and adds the -fpermissive CFLAG to enable
it to build rather than defining a new almost-identical
linux-g++-aarch64 PLATFORM because that seems to be unnecessary and less
clean. However I am no QT expert so there may be a good reason for doing
it the other way. I have left that definition file in so you can see
what was done, but so far as I can see the linux-g++ definitions are
correct. A look at why -fpermissive is needed might be a good thing, but
is beyond my ken.

3) The ubuntu patch disabled the docs build, but that is now working
correctly so no need for that any more.

This is obviously an important package in the bootstrap so I hope this
patch can go in the archive reasonably soon. Obviously I am happy to
answer questions  if you have any queries about what is correct for the
arm64/aarch64 build.


-- System Information:
Debian Release: 7.3
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-kvm-i386-20110111 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog	2013-12-06 19:38:48.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/changelog	2063-04-30 00:08:35.0 +
@@ -1,3 +1,9 @@
+qt4-x11 (4:4.8.5+git192-g085f851+dfsg-2arm64) unstable; urgency=low
+
+  * Add arm64/aarch64 support
+
+ --Mon, 30 Apr 2063 00:00:20 +
+
 qt4-x11 (4:4.8.5+git192-g085f851+dfsg-2) unstable; urgency=low
 
   * Fix typo created when refreshing a patch for s390x which created a FTBFS.
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control	2013-10-11 23:49:32.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/control	2063-04-30 00:53:04.0 +
@@ -9,6 +9,7 @@
Lisandro Damián Nicanor Pérez Meyer ,
Timo Jyrinki 
 Build-Depends: debhelper (>= 9),
+	   autotools-dev,
dpkg-dev (>= 1.16.1),
firebird-dev [amd64 armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sh4 sparc],
flex,
diff -Nru qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch
--- qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch	1970-01-01 00:00:00.0 +
+++ qt4-x11-4.8.5+git192-g085f851+dfsg/debian/patches/aarch64.patch	2063-04-30 01:11:32.0 +
@@ -0,0 +1,653 @@
+Index: qt4-x11-4.8.5+git192-g085f851+dfsg/configure
+===
+--- qt4-x11-4.8.5+git192-g085f851+dfsg.orig/configure	2063-04-29 23:57:10.0 +
 qt4-x11-4.8.5+git192-g085f851+dfsg/configure	2063-04-29 23:57:10.0 +
+@@ -264,6 +264,9 @@
+ 	armhf)
+ 		UNAME_MACHINE="armv6"
+ 	;;
++	arm64)
++		UNAME_MACHINE="aarch64"
++	;;
+ 	hppa)
+ 		UNAME_MACHINE="parisc"
+ 	;;
+@@ -2856,6 +2859,9 @@
+ *86_64)
+ PLATFORM=qws/linux-x86_64-g++
+ ;;
++aarch64)
++PLATFORM=linux-g++-aarch64
++;;
+ *)
+ PLATFORM=qws/linux-generic-g++
+ ;;
+@@ -3294,6 +3300,12 @@
+ echo "ARM (arm)"
+ fi
+ CFG_HOST_ARCH=arm
++	;;
++*:*:aarch64*)
++if [ "$OPT_VERBOSE" = "yes" ]; then
++echo "AArch64 (aarch64)"
++fi
++CFG_HOST_ARCH=aarch64
+ ;;
+ Linux:*:sparc*)
+ if [ "$OPT_VERBOSE" = "yes" ]; then
+Index: qt4-x11-4.8.5+git192-g085f851+dfsg/mkspecs/linux-g++-aarch64/qmake.conf
+===
+--- /dev/null	1970-01-01 00:00:00.0 +
 qt4-x11-4.8.5+git192-g085f851+dfsg/mkspecs/linux-g++-aarch64/qmake.conf	2063-04-29 23:57:10.0 +
+@@ -0,0 +1,28 @@
++#
++# qmake configuration for linux-g++
++#
++# Written for GNU/Linux platforms that have both lib and lib64 directories,
++# like the AMD Opteron.
++#
++
++MAKEFILE_GENERATOR	= UNIX
++TARGET_PLATFORM		= unix
++TEMPLATE		= app
++CONFIG			+= qt warn_on release incremental link_prl gdb_dwarf_index
++QT			+=