#317 Failure to build 1.21 on armv7hl with Python scripting enabled

[Alexander Ploumistos]

Hello,

I thought we had fixed all the issues in Fedora, so I submitted v1.21 for review. While waiting for the reviewer, I noticed that somewhere between 1.D8 and 1.D9, the previous maintainer had disabled python scripting, so I enabled it and submitted updated builds to our buildsystem.

However, they failed on armv7hl in a way that seems suspiciously similar to bug 180.

This is a build of 1.21 with python disabled: https://koji.fedoraproject.org/koji/taskinfo?taskID=21806163

This is after enabling it: https://koji.fedoraproject.org/koji/taskinfo?taskID=21822435

And this is a build just on armv7hl, with “make -j1”, as we thought the problem was with parallel building: https://koji.fedoraproject.org/koji/taskinfo?taskID=21826998

The error that pops up every time is about a missing generated file:

src/PythonScripting.cpp:65:10: fatal error: sipAPIscidavis.h: No such file or directory

There is also this in the armv7hl build logs:

sip: src/scidavis.sip:175: ::Column::replaceValues() unsupported function argument type - provide %MethodCode and a C++ signature

Just in case, here is my spec file.

Is this bug 180 again or is it something else?

[High Performance Coder]

Does you spec file include a dependency on PyWt4-devel and sip-devel?
You need both those packages for that header file to be generated.

Actually, I just noticed that you included the following error message below:

sip: src/scidavis.sip:175: ::Column::replaceValues() unsupported function argument type - provide %MethodCode and a C++ signature

I took a gander at replaceValues, and noticed that the function
signature had a double in it - to wit const QVector<double>&.

ARM does not support double precision, IIUC, so double should probably
be replaced by qreal everywhere. See
https://sourceforge.net/p/scidavis/scidavis-bugs/225/

Just took a sqizz at 180, and it seems to be related to the qreal
thing too.

Did you want to try to test changing double->qreal everywhere, and
submitting a pull request when you get something working? I'm not
really set up to test ARM here (although I do have a Raspberry Pi in
the corner I could press into service if things get too desperate.

Cheers

---

Dr Russell Standish Phone 0425 253119 (mobile)
Principal, High Performance Coders
Visiting Senior Research Fellow hpcoder@hpcoders.com.au
Economics, Kingston University http://www.hpcoders.com.au

---

[Alexander Ploumistos]

Did you want to try to test changing double->qreal everywhere, and
submitting a pull request when you get something working? I'm not
really set up to test ARM here (although I do have a Raspberry Pi in
the corner I could press into service if things get too desperate.

I was looking at Miquel Garriga's patch for 313 and he used a conditional to switch from double to float on ARM.

In Qt's documentation there's this:

typedef qreal

Typedef for double unless Qt is configured with the -qreal float option.

Does this mean that every variable type set to qreal can be either double or float, depending on how qmake or qwhatever is invoked?

The thing is I don't think a find and replace is going to do the job and I know nothing about Qt and next to nothing about C++…

I do have access to the armv7hl builders in Fedora though, so if anyone would be willing to step forward and do the patching, I could do the testing.

In the meantime, I can either ExcludeArch armv7hl, or disable scripting in order to get the package accepted in Fedora.

Sorry I can't be of any more help…

[gbm]

Yes, the compile errors in your log files [1,2] point to a 'qreal' issue.
Note that GCC 7.1 (your compiler) [3, last point in 'Caveats'] fixed an old bug on ARM targets and prints this warning when the calling signature of a function may introduce ABI changes:

"note: parameter passing for argument of type '...' changed in GCC 7.1"

Please try attached patch (that includes an alternative to my previous armv7hl-build.patch) and publish the link to build.log if it doesn't fix the bug.

Also note that your build scripts use python3.6 and SciDAVis only works with python2.7

Miquel

[1] https://kojipkgs.fedoraproject.org//work/tasks/6999/21826999/build.log
[2] https://kojipkgs.fedoraproject.org//work/tasks/2446/21822446/build.log
[3] https://gcc.gnu.org/gcc-7/changes.html

[Alexander Ploumistos]

Hello Miquel,

Please try attached patch (that includes an alternative to my previous armv7hl-build.patch) and publish the link to build.log if it doesn't fix the bug.

Robert-André Mauchin, another Fedora contributor, had sent me the same patch for scidavis.sip and I was about to submit a PR, when you send yours. Since it was a 2 in 1, I went with that.

Thank you very much yet again!

Sure enough, the builds are now successful:
https://koji.fedoraproject.org/koji/taskinfo?taskID=21843516

Would you care to submit the changes to the github repo?

Also note that your build scripts use python3.6 and SciDAVis only works with python2.7

I have "BuildRequires: python2-devel" in the spec file, so I would expect python2.7 to be used for the build, which is:

g++ […] -I/usr/include/python2.7 […]

If you are referring to these messages

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/mockbuild/trace_decorator.py", line 89, in trace

python3.6 is used in the buildsystem tools.

[High Performance Coder]

Is this still an issue? SciDaVis currently builds on both the aarch64 and armv7l OpenSUSE targets at https://build.opensuse.org/package/show/home:hpcoder1/scidavis.

[Alexander Ploumistos]

And you can close this one as well.