Add ARM64 deb to KLayout website

[adrienluitot]

It would be cool to have Arm64 .deb on the page https://www.klayout.de/build.html.

This would allow to install more recent packages than default ones.

[klayoutmatthias]

I don't have hardware to do that currently.

[adrienluitot]

I have a Raspberry Pi so I can build it for you if you want.
It’s pretty slow to build but it doesn’t matter I guess. Maybe I should try cross compiling too.

[klayoutmatthias]

Cross-compiling means it builds, but cannot be tested. And I cannot offer untrusted binaries for download.

[adrienluitot]

That's true indeed, once the compilation is done, I'll try the test procedure. The compilation is very slow on the Raspberry :')
You are right not to offer untrusted binaries, how do you do with Kazzz-S for Mac binaries?

Did you have any attempt cross compiling KLayout so far?

PS: It seems that compilation also builds Qt modules. Isn't it possible to use pre-compiled or shared libraries to speed to compilation?

[adrienluitot]

So after too many hours, compilation of 0.29.8 is finished. I ran the test (with -goption) and got these fails:

Failed in non-editable mode
        bdStrmrunTests:1
        klayout_main_tests:main
        pymod_tests:import_QtNetwork
        tlVariantTests:4
Failed in editable mode
        bdStrmrunTests:1
        klayout_main_tests:main
        pymod_tests:import_QtNetwork
        tlVariantTests:4
        tlWebDAVTests:1

tlVariantTests:4 fail is caused by: Exception caught: ../../../src/tl/unit_tests/tlVariantTests.cc, line 874: v.can_convert_to_char () does not equal true

tlWebDAVTests:1 is caused by: Exception caught: Error 99: Network API error, fetching http://www.klayout.org/svn-public/klayout-resources/trunk/testdata
Which is strange because other tlWebDAVTests passed. I will re run the test to ensure it's not an error from my network.
EDIT: After re running the tests today, I don't have a fail on tlWebDAVTests:1 any more.

The other ones seem all related to:

Warning: Unable to find GSI class binding for: N4QSsl11SslProtocolE
Warning: Unable to find GSI class binding for: N15QNetworkRequest12KnownHeadersE
Warning: Unable to find GSI class binding for: 15QNetworkRequest
...

I also have the same warning when I launch klayout or the ut_runner script.

I didn't take the time to debug or search for similar issues yet, I might later. Maybe someone already knows how to fix that.

EDIT: The tests seem to fail when comparing strings, the warnings seem to be added to the string compared.
I don't have an exact example right now, but I have something like:

Received: "< [...] Warning: Unable to find GSI class binding for: N4QSsl11SslProtocolE\nHello World!"
Expected: "Hello World!"

I saw in #130 there might be something related to the python path. I started a compilation python setup.py, I'll see if it changes something.
However I'm not sure those warnings should make the tests fail? I think there is a strange behaviour with the being crapped into the compared string.

PS: Even when setting -prefix I need to set LD_LIBRARY_PATH when I run klayout. But this is maybe because I didn't set it for the first build, then I used -prefix for a second build with cleaning, so maybe it didn't recompile the part with RPATH?

[s910324]

Glad to see someone also tried to compile an ARM verizon of KLayout, I've been doing this several times on my android tablet and phone, just to serve as an emergency contingency solution.

The compile time for the package takes around 3 hr or so on my 3yo devices

Generally speaking, it works fine as a viewer, but often encounter some warnings here and there but normally those warnings does not followed by a crash, so I won't try to do serious stuff at least on the ones I've compiled.

User experience wise, aside from having some minor UI rendering issues, I'll say it feels smooth and has a performance that is almost on part as my main machine.

[stefanottili]

Glad to see someone also tried to compile an ARM verison of KLayout

I've been using klayout on MacOS M1 (apple clang for arm64) for the last four years.
Besides some Mac specific qt5/6 bugs, it just compiles and works.
Incremental build times are < 1 min, it takes 8 min to build without qt-bindings.
build4mac.py -r HB33 -p HBAuto -q Qt5Brew -m '--jobs=8' -n -u

Warning: Unable to find GSI class binding for:

I've seen these on MacOS when I have several versions of dylib's in the same build directory.
So when there is a new version e.g 0.29.9, I delete all xxx.0.29.8 dylib's.

[stefanottili]

I stand corrected, when having multiple versions of dylibs, I get
Warning: Duplicate GSI declaration of name

[adrienluitot]

The compile time for the package takes around 3 hr or so on my 3yo devices

I takes much more for me on my Raspberry pi 4, but maybe because I didn't enable multiple jobs. Also maybe you don't recompile qt?

[adrienluitot]

I've been using klayout on MacOS M1 (apple clang for arm64) for the last four years. Besides some Mac specific qt5/6 bugs, it just compiles and works. Incremental build times are < 1 min, it takes 8 min to build without qt-bindings. build4mac.py -r HB33 -p HBAuto -q Qt5Brew -m '--jobs=8' -n -u

I'm pretty sure the M1 outperforms the 4-core 1.4GHz processor of the Raspberry Pi x)
I will try without QtBinding to see how much time it takes.

I stand corrected, when having multiple versions of dylibs, I get
Warning: Duplicate GSI declaration of name

Sad, I thought you might have the solution... But it is probably a good track already. I will continue to search.