Installing cmake on aarch64 using pip via wheel

[odidev]

Summary
Installing cmake on aarch64 linux platform via pip using command "pip3 install cmake" tries to build wheel from source code.

Problem description
Cmake don't have wheel for aarch64 on PyPI repository. So, while installing cmake via pip on aarch64, it builds wheel from source which takes more time to install cmake. Making wheel available for aarch64 will benefit aarch64 users by minimizing installation time.

Expected Output
Pip should be able to download cmake wheel from PyPI repository rather than building it from source code.

@thewtex , I was able to build wheel with command "python setup.py bdist_wheel" and wheel has been created for specific python version in dist folder. I have tried installing in aarch64 linux platform with command "pip install cmake-xxx.whl", it got installed successfully. Please let me know if any help required in building wheel and uploading it to PyPI repository.

[odidev]

Hi @thewtex ,

Installation of cmake is taking time while building from a source in aarch64. It will be efficient and helpful if wheel is added for the same as many packages are dependent on cmake.

[thewtex]

@odidev Since pypa/manylinux#84 is still open, my impression is that pip / manylinux support is a work in progress. This means that even if we create a wheel and upload it, pip will not recognize that it can use it. But, we can try to create it -- users may just need to download the *.whl file manually to install it.

@odidev would you like to try to create a wheel based on the toolchain provided in: https://github.com/pypa/manylinux/blob/manylinux2014/docker/Dockerfile-aarch64 ?

[thewtex]

It is also worth noting that dockcross may enable cross-compiling of the wheels from x86_64 systems, which could help alleviate build time and CI resource issues.

[jcfr]

If there is interest and human resources to make it happen, an approach similar to what was discussed in scikit-build/ninja-python-distributions#22 (comment) could be implemented for aarch64 wheels

In a nutshell, wheels for aarch64 would be hosted as assets in a github release associated with this project and could be installed using something like this:

pip install -f https://github.com/kit-build/cmake-python-distributions/releases/tag/aarch64-python-wheels

[jcfr]

And since we would need wheels for ninja and cmake, the project https://github.com/scikit-build/aarch64-python-wheels could be created ...

[odidev]

@odidev Since pypa/manylinux#84 is still open, my impression is that pip / manylinux support is a work in progress. This means that even if we create a wheel and upload it, pip will not recognize that it can use it. But, we can try to create it -- users may just need to download the *.whl file manually to install it.

@odidev would you like to try to create a wheel based on the toolchain provided in: https://github.com/pypa/manylinux/blob/manylinux2014/docker/Dockerfile-aarch64 ?

@thewtex ,

Thanks for the suggestion. I have created a dockerfile for creating wheel based on suggested toolchain. Please find below dockerfile used to create cmake wheel.

Dockerfile:

FROM quay.io/pypa/manylinux2014_aarch64:latest

RUN yum update -y
&& yum install -y epel-release git wget openssl-devel python3 python3-pip python3-devel
&& yum clean all

RUN mkdir /tmp/dl && cd /tmp/dl
&& wget https://github.com/Kitware/CMake/releases/download/v3.16.5/cmake-3.16.5.tar.gz && tar -xf cmake-3.16.5.tar.gz
&& cd cmake-3.16.5 && ./configure && make && make install

RUN git clone https://github.com/scikit-build/cmake-python-distributions && cd cmake-python-distributions
&& pip3 install -r requirements-dev.txt && python3 setup.py bdist_wheel && ls dist

Wheel(cmake-3.16.3.post1+g0f6336c-cp36-cp36m-linux_aarch64.whl) has been created in dist folder. Can you suggest me on how can we upload it to releases?

[odidev]

It is also worth noting that dockcross may enable cross-compiling of the wheels from x86_64 systems, which could help alleviate build time and CI resource issues.

Thanks for the suggestion. In https://github.com/dockcross/dockcross, we don't have dockerfile for manylinux2014_aarch64. We have only manylinux2014_x64. I think we require that to build wheel through dockcross or I may be wrong, please suggest me on how can we use that for manylinux2014_aarch64? Thanks.

[thewtex]

Please find below dockerfile used to create cmake wheel.

Awesome! Well done @odidev ! 🎉 🥇

In https://github.com/dockcross/dockcross, we don't have dockerfile for manylinux2014_aarch64.

The image to try is dockcross/linux-arm64.

Can you suggest me on how can we upload it to releases?

If cross-compiling works, you could configure a GitHub Action on your fork to build the wheel on push, then push to the GitHub Release. Once ready, create a pull request for this repository.

If cross-compiling does not work, a hosted GitHub Action worker could be possible if you have hardware you can keep available for the cause.

[odidev]

Hi @thewtex ,

Thanks for the suggestion.

I am able to successfully cross-compile using python crossenv and built aarch64 wheel. Checking on github actions for pushing wheel to release.

Dockerfile: Dockerfile_cmake_cross

Travis-CI has added support for arm64. We can build wheel for arm64 and deploy to github releases with tag aarch64-python-wheels.

Sample code to build in Travis:

language: python

matrix:
include:
- os: linux
arch: arm64
env:
- PYTHON_VERSION=3.7.4

script:
- if [ "${TRAVIS_CPU_ARCH}" == "arm64" ]; then
python setup.py bdist_wheel
fi

before_deploy:
- export TRAVIS_TAG=${aarch64-python-wheels:-$(date +'%Y%m%d%H%M%S')-$(git log --format=%h -1)}
- git tag $TRAVIS_TAG

deploy:
provider: releases
api_key:
secure: YOUR_API_KEY_ENCRYPTED
file: "Wheel created in dist folder"
skip_cleanup: true
on:
tags: true

If we can follow this, I think we can upload to git hub releases with tag aarch64-python-wheels.

Can we do this process as through this process it is easy to build and upload to releases?

[thewtex]

@odidev well done! 👏 🔢

Can we do this process as through this process it is easy to build and upload to releases?

Yes -- perhaps you can develop and test the TravisCI configuration and GitHub Action on your folk, then we can enable and merge here when ready.

arm64 CMake packages will very helpful to the community.

[ax3l]

I was setting up CD with cibuildwheel these days and its really simple to set up if you already have a great wheel recipe like yours in place.

You can drive Linux/Windows/OSX builds, the former for ppc64le, aarch64, s390x, i686 and amd64, with the popular open CI platforms in quite compact setups.

I was able to build cmake with it, but since I did not cache the wheel somewhere I am running into timeouts for my actual builds...

[odidev]

@odidev well done! 👏 🔢

Can we do this process as through this process it is easy to build and upload to releases?

Yes -- perhaps you can develop and test the TravisCI configuration and GitHub Action on your folk, then we can enable and merge here when ready.

arm64 CMake packages will very helpful to the community.

Hi @thewtex ,

I have successfully built aarch64 wheel with an aarch64 job. I have modified the travis file as per my requirement to build and deploy the wheel on git release. You can have a look at the same git release at https://github.com/odidev/cmake-python-distributions/releases/tag/aarch64-python-wheels. Using aarch64 job cmake wheel can successfully be deployed.

Travis link: https://github.com/odidev/cmake-python-distributions/blob/master/.travis.yml

Please check the travis file and we had to remove PyPI deployment phase to check deploying aarch64 wheel to git releases with tag.

Please suggest if any more changes are required.

[thewtex]

@odidev amazing work!

https://github.com/odidev/cmake-python-distributions/releases/download/aarch64-python-wheels/cmake-aarch64_python_wheels-cp36-cp36m-linux_aarch64.whl

💯

@jcfr what do you think about @odidev creating a PR with his current work, then you push a commit that updates the secret and repository?

[odidev]

Hi @thewtex and @jcfr ,

I think PyPI has added support for aarch64 wheels. I have tested 2 samples NumPy as NumPy-demo and lxml as lxml-odidev. We can install NumPy-demo and lxml-odidev packages from aarch64 wheel itself from pip 19.3 versions whereas with pip versions below 19.3 these packages are being installed from tar file rather than the wheel.

So, we tried testing cmake as cmake-odidev, wheel is building successfully but we are facing below issue in version while uploading wheel:
loading cmake_odidev-3.16.4.post5+ga73e1d4-cp37-cp37m-manylinux2014_aarch64.whl
100%|██████████| 14.6M/14.6M [00:11<00:00, 1.34MB/s]
NOTE: Try --verbose to see response content.
HTTPError: 400 Client Error: '3.16.4.post5+ga73e1d4' is an invalid value for Version. Error: Can't use PEP 440 local versions. See https://packaging.python.org/specifications/core-metadata for url: https://upload.pypi.org/legacy/
PyPI upload failed.

Deploy steps used:
deploy:
provider: pypi
user: mkp2020
password:
secure: xxx
on:
repo: odidev/cmake-python-distributions
skip_cleanup: 'true'
distributions: sdist bdist_wheel --plat-name manylinux2014_aarch64

I have tried giving static version in setup.py and versioneer.py but still, I am getting the same error.

Maybe, If we add deploy steps for aarch64 wheel as well in CMake Travis, we can upload CMake aarch64 wheel as well while uploading x86_64 wheels to PyPI. Please check on the same,

To proceed further on testing the process of uploading the cmake-odidev aarch64 wheel and reusing it, I require your suggestion regarding the version issue.

Please let me know if any more information is required.

[jcfr]

I think PyPI has added support for aarch64 wheels

That is exciting 🎉

As a side note, I am sorry for the slowness in reviewing your awesome contributions, and thanks again for your patience and perseverance. We will get there 💪 🙏

If we add deploy steps for aarch64 wheel as well in cmake travis, we can upload cmake aarch64 wheel as well while uploading x86_64 wheels to PyPI.

That makes sense.

Could you update this part of the the CI configuration to also run the tests:

https://github.com/odidev/cmake-python-distributions/blob/a73e1d407f5d7e2503ef80d8a92e2b4a62da6f56/.travis.yml#L22-L43

Once we confirm the tests pass, we will update the current CI to integrate with your changes and make sure the wheels are uploaded.

HTTPError: 400 Client Error: '3.16.4.post5+ga73e1d4' is an invalid value for Version

This error makes sense, in a nutshell only tagged version can be uploaded.

[ax3l]

I think PyPI has added support for aarch64 wheels

That is exciting 🎉

Awesome, looking forward to use the new wheels! 🚀

Just adding the reference to currently supported PyPI platforms that we can potentially build CMake packages for:
https://github.com/pypa/warehouse/blob/a364ac6b4db23326100d7fdf3268c89c8eecbc9f/warehouse/forklift/legacy.py#L98-L116

[jcfr]

An other task would be to add new images to dockcross for platforms we would like to build wheels for. See https://github.com/dockcross/dockcross

We could start with aarch64

Help would be greatly appreciated 🙏

This file could be used as a template, see https://github.com/dockcross/dockcross/tree/master/manylinux2014-x64

[odidev]

Could you update this part of the the CI configuration to also run the tests:

https://github.com/odidev/cmake-python-distributions/blob/a73e1d407f5d7e2503ef80d8a92e2b4a62da6f56/.travis.yml#L22-L43

I have updated the file with tests as well. Please check https://github.com/odidev/cmake-python-distributions/blob/arm64_test/.travis.yml

All tests are passing successfully. Please find below link for travis report.

Report: https://travis-ci.org/github/odidev/cmake-python-distributions/builds/681396733

Please let me know if any more updates are required.

[odidev]

@jcfr ,

HTTPError: 400 Client Error: '3.16.4.post5+ga73e1d4' is an invalid value for Version

This error makes sense, in a nutshell only tagged version can be uploaded.

As suggested, with the tagged release we are able to upload cmake-odidev aarch64 wheel to PyPI.

PyPI files: https://pypi.org/project/cmake-odidev/#files
Travis log: https://travis-ci.org/github/odidev/cmake-python-distributions/jobs/682550991
Travis file: https://github.com/odidev/cmake-python-distributions/blob/master/.travis.yml

Installation:
pip install cmake-odidev
Collecting cmake-odidev
Using cached cmake_odidev-3.17.3-cp37-cp37m-manylinux2014_aarch64.whl (15.3 MB)
Installing collected packages: cmake-odidev
Successfully installed cmake-odidev-3.17.3

root@eddbd327b464:/# cmake --version
cmake version 3.16.3

CMake suite maintained and supported by Kitware (kitware.com/cmake)

Please check and let me know if any more information is required.

[odidev]

@jcfr ,

An other task would be to add new images to dockcross for platforms we would like to build wheels for. See https://github.com/dockcross/dockcross

We could start with aarch64

I have started checking on adding manylinux2014-aarch64 into dockcross. You can check my findings in the comment dockcross/dockcross#367 (comment) and suggest if any resolutions on the issues.

[odidev]

@jcfr ,

May I know when the cmake aarch64 wheel will be uploaded? Do I need to raise a PR for uploading aarch64 wheel?

[jcfr]

I will so my best to get to it this week. Thanks for your patience 🙏

[odidev]

@jcfr ,

May I know if there any update on uploading cmake aarch64 wheel to PyPI. Thanks.

[jcfr]

I just submitted a PR to add support for building aarch64 wheel.

It turns out their are the following issues:

• variables AUDITWHEEL_ARCH and AUDITWHEEL_PLAT are improperly set. This will be fixed in manylinux2014-aarch64: Set AUDITWHEEL_ARCH and AUDITWHEEL_PLAT variables dockcross/dockcross#420
• Look like OpenSSL libraries built for aarch64 are missing. I think these should be built in the dockcross image

[jcfr]

Closing. This was fixed in #108 and #109

Thanks @odidev for the help 🙏

[odidev]

@jcfr ,

Thanks for uploading wheel.

I am able to successfully install cmake using wheel now as verified below:

pip install cmake
Collecting cmake
  Downloading cmake-3.18.0-py3-none-manylinux2014_aarch64.whl (15.1 MB)
     |████████████████████████████████| 15.1 MB 46 kB/s
Installing collected packages: cmake
Successfully installed cmake-3.18.0

But commands "cmake --version" or "cmake -h" are not giving any output.

root@88ffb51f30fe:/# cmake --version
root@88ffb51f30fe:/# cmake --help
root@88ffb51f30fe:/#

Can you please suggest what I am missing here?

Thanks.

[jcfr]

Can you please suggest what I am missing here?

What is the output of which cmake ?

What happen if you directly run the cmake executable shipped in the wheel ?

For example, assuming a virtualenv called test:

$ which cmake 
/home/jcfr/.virtualenvs/test/bin/cmake

$ /home/jcfr/.virtualenvs/test/lib/python3.5/site-packages/cmake/data/bin/cmake --version 
cmake version 3.18.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Background:

Since I had to disable the test (see 59e9f9d) because the python interpreter available in the dockcross image manylinux2014-aarch64 is for x86_64 or i686, the CI didn't cast the problem reported.

[odidev]

@jcfr ,

Please find below output of which and cmake commands:

$ which cmake
/home/arm137/.local/bin/cmake

$ /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cmake --version
Segmentation fault (core dumped)

It is giving segmentation fault.

[jcfr]

output of "file" command

Now what is the output of:

file /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cmake

and how does it compare with the output of an executable known to work on this system ?

simple hello world

Then, if you compile a simple hello world executable using dockcross/manylinux2014-aarch64, can you run it on your target system ?

First, run the image:

cd ~
dockcross-manylinux2014_aarch64 bash

Then compile small executable:

echo "#include <iostream>

int main(int, char*[])
{
  std::cout << \"Hello\" << std::endl;
  return 0;
}" > main.cpp

$CXX -o hello main.cpp

Last, copy hello onto the target system and try to run it.

For reference, here is the output of the file command:

$ file hello 
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 4.10.8, not stripped

Does it run ?

Additional experiment

The cmake wheel is compiled with the following flags:

cmake-python-distributions/CMakeLists.txt

Lines 190 to 191 in f18454b

	"set(CMAKE_C_FLAGS \"-D_POSIX_C_SOURCE=199506L -D_POSIX_SOURCE=1 -D_SVID_SOURCE=1 -D_BSD_SOURCE=1\" CACHE STRING \"Initial cache\" FORCE)
	set(CMAKE_EXE_LINKER_FLAGS \"-static-libstdc++ -static-libgcc -lrt\" CACHE STRING \"Initial cache\" FORCE)

I wonder if some of these flags are problematic on aarch64 ...

[odidev]

File command Output of cmake executable:

$ file /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cmake
/home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cmake: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 4.10.8, stripped

Created executable as suggested.

[root:/work] # echo "#include <iostream>
>
> int main(int, char*[])
> {
>   std::cout << \"Hello\" << std::endl;
>   return 0;
> }" > main.cpp
[root:/work] # ls
main.cpp
[root:/work] # $CXX -o hello main.cpp
[root:/work] # file hello
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 4.10.8, not stripped

Copied to the local arm64 system and ran hello executable. Output:

$ ./hello
Hello

$ file hello
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 4.10.8, with debug_info, not stripped

I am not sure on cmake flags. Need to analyze more on them.

[jcfr]

The hello world works, this means this is something wrong with cmake executable.

On the target system where you have the seg fault, could you update the setting so that it generate a coredump file ?

Reading this should give some hint: https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/Debug_Instructions#Analyze_a_segmentation_fault

Out of curiosity, are you able to run ctest or cpack ?

/home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cpack --version
/home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/ctest  --version

[odidev]

The output of ctest and cpack:

$ /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cpack --version
Segmentation fault (core dumped)
$ /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/ctest  --version
Segmentation fault (core dumped)

Please find below coredump files of cmake, cpack and ctest executables(shared as text files):
core-test.txt
core-cmake.txt
core-cpack.txt

Backtrace of gdb /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/ctest core-test:

(gdb) bt
#0  0x0000000000b985f8 in ?? ()
#1  0x0000000000b98674 in ?? ()
#2  0x0000000000bb7f68 in ?? ()
#3  0x0000000000b95e94 in ?? ()
#4  0x0000000000563a18 in ?? ()
#5  0x000000000041fb98 in ?? ()
#6  0x0000ffff861a2090 in __libc_start_main (main=0x41fa24, argc=2, argv=0xffffef3455f8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
#7  0x00000000004278b8 in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further

Backtrace of gdb /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cmake core-cmake:

(gdb) bt
#0  0x0000000000ab1ae8 in ?? ()
#1  0x0000000000ab1b64 in ?? ()
#2  0x0000000000ad18ec in ?? ()
#3  0x0000000000aaf384 in ?? ()
#4  0x000000000044ae20 in ?? ()
#5  0x000000000042c9cc in ?? ()
#6  0x000000000041f4e0 in ?? ()
#7  0x0000ffffa8f2c090 in __libc_start_main (main=0x41f420, argc=2, argv=0xffffc1b4f2c8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
#8  0x0000000000429800 in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further

Backtrace of gdb /home/arm137/.local/lib/python3.8/site-packages/cmake/data/bin/cpack core-cpack:

(gdb) bt
#0  0x0000000000ae11f8 in ?? ()
#1  0x0000000000ae1274 in ?? ()
#2  0x0000000000b00b20 in ?? ()
#3  0x0000000000adea94 in ?? ()
#4  0x00000000004a3b88 in ?? ()
#5  0x000000000041feb4 in ?? ()
#6  0x0000ffff9788e090 in __libc_start_main (main=0x41f2e8, argc=2, argv=0xfffffa381e38, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=<optimized out>) at ../csu/libc-start.c:308
#7  0x0000000000428f80 in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further

I am unable to get symbols information. Maybe, while generating cmake binary, we can enable symbols as well to check with gdb.

Please let me know if any more information is required.

[jcfr]

That doesn't provide us much information.

Could you look into creating a debug build of cmake using manylinux2014-aarch64 ?

I also suggest to try removing the static-* flags:

cmake-python-distributions/CMakeLists.txt

Lines 190 to 191 in f18454b

	"set(CMAKE_C_FLAGS \"-D_POSIX_C_SOURCE=199506L -D_POSIX_SOURCE=1 -D_SVID_SOURCE=1 -D_BSD_SOURCE=1\" CACHE STRING \"Initial cache\" FORCE)
	set(CMAKE_EXE_LINKER_FLAGS \"-static-libstdc++ -static-libgcc -lrt\" CACHE STRING \"Initial cache\" FORCE)

To create a debug build, you could simply pass -DCMAKE_BUILD_TYPE:STRING=Debug when building the wheel (e.g python setup.py bdist_wheel -DCMAKE_BUILD_TYPE:STRING=Debug . See https://scikit-build.readthedocs.io/en/latest/usage.html#usage-cmake-configure-options

Since you were already able to build cmake for aarch64 ... we are close:
https://discourse.cmake.org/t/regarding-cmake-aarch64-binary-in-releases-and-cmake-cross-build-host-x86-64-target-aarch64/1109

[odidev]

@jcfr ,

Thanks for the references and build steps.

I have built openssl from github, cmake binary is getting built but command cmake --version is giving below error:
cmake: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory

I have built openssl 1.1.1.g and trying to build cmake wheel with below command:

/opt/python/cp38-cp38/bin/python setup.py bdist_wheel --plat-name manylinux2014_aarch64 -- -DCMAKE_BUILD_TYPE:STRING=Debug -DOPENSSL_ROOT_DIR:PATH=/tmp/openssl-install -DCMAKE_JOB_POOL_COMPILE:STRING=compile -DCMAKE_JOB_POOL_LINK:STRING=link '-DCMAKE_JOB_POOLS:STRING=compile=4;link=3' -DSTRIP_EXECUTABLE:FILEPATH=$CROSS_ROOT/$CROSS_TRIPLE/bin/strip -DCMAKE_TOOLCHAIN_FILE:STRING=${CMAKE_TOOLCHAIN_FILE}

I am getting below error:

[5/611] Linking C executable Utilities/cmcurl/curltest
FAILED: Utilities/cmcurl/curltest
: && /usr/xcc/aarch64-unknown-linux-gnueabi/bin/aarch64-unknown-linux-gnueabi-gcc --sysroot=/usr/xcc/aarch64-unknown-linux-gnueabi/aarch64-unknown-linux-gnueabi/sysroot -D_POSIX_C_SOURCE=199506L -D_POSIX_SOURCE=1 -D_SVID_SOURCE=1 -D_BSD_SOURCE=1 -w -O3 -DNDEBUG  -static-libstdc++ -static-libgcc -lrt Utilities/cmcurl/CMakeFiles/curltest.dir/curltest.c.o  -o Utilities/cmcurl/curltest  -Wl,-rpath,/tmp/openssl-install/lib  Utilities/cmcurl/lib/libcmcurl.a  -ldl  /tmp/openssl-install/lib/libssl.so  /tmp/openssl-install/lib/libcrypto.so  Utilities/cmnghttp2/libcmnghttp2.a  Utilities/cmzlib/libcmzlib.a && :
Utilities/cmcurl/lib/libcmcurl.a(openssl.c.o): In function `ossl_connect_step1':
openssl.c:(.text+0x462c): undefined reference to `SSL_CTX_load_verify_file'
openssl.c:(.text+0x46d8): undefined reference to `SSL_CTX_load_verify_dir'
collect2: error: ld returned 1 exit status

Can you suggest if I am missing anything?

Thanks.

[odidev]

@jcfr ,

I have built cmake binary with symbols enabled using -g in linker_flags and please find below back trace messages for cmake core:

gdb cmake core
(gdb) bt
#0  0x0000000000ab1ae8 in __gnu_cxx::__exchange_and_add (__val=-1, __mem=0x8)
    at /dockcross/crosstool/toolchain/.build/aarch64-unknown-linux-gnueabi/build/build-cc-gcc-final/aarch64-unknown-linux-gnueabi/libstdc++-v3/include/ext/atomicity.h:49
#1  __gnu_cxx::__exchange_and_add_dispatch (__val=-1, __mem=0x8)
    at /dockcross/crosstool/toolchain/.build/aarch64-unknown-linux-gnueabi/build/build-cc-gcc-final/aarch64-unknown-linux-gnueabi/libstdc++-v3/include/ext/atomicity.h:82
#2  std::locale::_Impl::_M_remove_reference (this=0x8)
    at /dockcross/crosstool/toolchain/.build/aarch64-unknown-linux-gnueabi/build/build-cc-gcc-final/aarch64-unknown-linux-gnueabi/libstdc++-v3/include/bits/locale_classes.h:517
#3  0x0000000000ab1b64 in std::locale::operator= (this=this@entry=0xffffe38b70b8, __other=...)
    at /dockcross/crosstool/toolchain/.build/src/gcc-4.9.4/libstdc++-v3/src/c++98/locale.cc:116
#4  0x0000000000ad18ec in std::ios_base::_M_init (this=this@entry=0xffffe38b6fe8)
    at /dockcross/crosstool/toolchain/.build/src/gcc-4.9.4/libstdc++-v3/src/c++98/ios_locale.cc:44
#5  0x0000000000aaf384 in std::basic_ios<char, std::char_traits<char> >::init (this=0xffffe38b6fe8, __sb=0x0)
    at /dockcross/crosstool/toolchain/.build/aarch64-unknown-linux-gnueabi/build/build-cc-gcc-final/aarch64-unknown-linux-gnueabi/libstdc++-v3/include/bits/basic_ios.tcc:129
#6  0x00000000004fcd6c in cmSystemTools::FindCMakeResources(char const*) ()
#7  0x000000000041f478 in main ()

I have tried after removing static* flags but generated CMake binary is still giving segmentation fault. Can I get any suggestions on how can I resolve this issue?

[PhilMiller]

I was previously encountering similar segfaults, and was going to dig in on debugging it, since it's hindering my work.

Just now, I've got a working build, with minimal tweaking necessary.

OS: Ubuntu 18.04.4

For the OpenSSL dependency, I simply apt-get -y install libssl-dev

Then, to do the CMake build, inside a virtual environment

virtualenv -p python3 venv-cmake
source venv-cmake/bin/activate
pip install scikit-build

git clone [email protected]:scikit-build/cmake-python-distributions
cd cmake-python-distributions/

python setup.py bdist_wheel
pip install dist/cmake-3.18.0-cp36-cp36m-linux_aarch64.whl

That all went cleanly. Then, the results:

$ which cmake
/home/ubuntu/venv-cmake/bin/cmake

$ cmake --version
cmake version 3.18.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

So, either other changes in the build have resolved the crash, or there's a meaningful difference between the defaults I'm using and the detailed specification of your build.

[odidev]

@PhilMiller,

Thanks for the explanation. I suppose that you are following the above steps in the aarch64 machine. I am able to successfully build a wheel in aarch64 machines and run cmake binary after installation. But, I am facing an issue with cmake binary created from the aarch64 wheel built on x86 host using dockcross/manylinux2014-aarch64.

[PhilMiller]

Indeed, this was on an Amazon c6 instance, which is an aarch64 machine.

It might be wise to open a separate issue to track the further investigation of the bad build, especially so that others encountering the issue can find it.

In the meanwhile, would it be possible to remove the prebuilt wheel for cmake on aarch64 from PyPI, so that users running pip install cmake there (or getting it as a dependency) end up with a working local build, rather than a broken pre-made cross-compiled build?

[jcfr]

to remove the prebuilt wheel for cmake on aarch64 from PyPI

All set. Wheel has been removed.

[jcfr]

@odidev As discussed here, cmake binaries generated using dockcross/manylinux2014-aarch64 are not working, sadly I do not have the bandwidth to investigate further 😞

[odidev]

@jcfr,

Thanks for the reply. I am checking into that issue.

As a temporary solution, can we use qemu and build wheel directly in arm64 platform in Circle-CI. If it is fine, I will raise PR with the changes.

[SoundsSerious]

@jcfr ,

Thanks for uploading wheel.

I am able to successfully install cmake using wheel now as verified below:

pip install cmake
Collecting cmake
  Downloading cmake-3.18.0-py3-none-manylinux2014_aarch64.whl (15.1 MB)
     |████████████████████████████████| 15.1 MB 46 kB/s
Installing collected packages: cmake
Successfully installed cmake-3.18.0

But commands "cmake --version" or "cmake -h" are not giving any output.

root@88ffb51f30fe:/# cmake --version
root@88ffb51f30fe:/# cmake --help
root@88ffb51f30fe:/#

Can you please suggest what I am missing here?

Thanks.

Also seeing this issue on ubuntu20.04 Rpi 4