Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi3 (ARM64) support #32

Merged
merged 17 commits into from
Apr 17, 2020
Merged

Raspberry Pi3 (ARM64) support #32

merged 17 commits into from
Apr 17, 2020

Conversation

brainstorm
Copy link
Contributor

@brainstorm brainstorm commented Apr 14, 2020

As discussed on the Discord server, here you have some ARM64 action without docker nor github actions (reusing the existing TravisCI recipe and deploy keys), hope the build doesn't fail too much ;)

It works fine locally using docker on OSX:

$ docker build --tag openpnp-capture-rpi3-arm64:latest . -f docker/Dockerfile.rpi3_arm64
(...)
$ docker run -v $PWD:/openpnp-capture openpnp-capture-rpi3-arm64 /bin/bash -c "./bootstrap_linux.sh && cd build && make"
$ file build/libopenpnp-capture.so
build/libopenpnp-capture.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=23504b1c2819e17d67904b63f44d8abdc4d0d685, not stripped

$ file build/libopenpnp-capture.so
build/libopenpnp-capture.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=23504b1c2819e17d67904b63f44d8abdc4d0d685, not stripped

Trying to reuse travisci instead of GitHub actions and sans Docker first... saving some transition pains for @vonnieda ;)
@brainstorm
Copy link
Contributor Author

Fixes #27, btw :)

@vonnieda vonnieda merged commit 49a6b06 into openpnp:master Apr 17, 2020
@vonnieda
Copy link
Member

Thanks @brainstorm. If you have a moment, can you verify that the resulting binary does not have any external dependencies? It looks to me like it might end up requiring libjpeg installed by the user, which makes the binary likely to fail in confusing ways for users. You can check the external dependencies with ldd library.so. If it is using libjpeg (or anything else) as a shared dependency, check out the CMakeLists.txt to see how we fix this issue using turbojpeg.

@vonnieda
Copy link
Member

There does seem to be some libjpeg issues here: https://travis-ci.org/github/openpnp/openpnp-capture/jobs/676039253

I'm suspicious about all three added dependencies:

    - build-essential
    - cmake
    - libjpeg-dev

Why were these needed?

@brainstorm
Copy link
Contributor Author

TL;DR: Sorry, yes, please, kill those 3 dependencies from .travisci.yml ;)

Sure (OSX does not have ldd, so resorting to the docker container itself). There doesn't seem to be such an external dep:

$ docker run -it -v $PWD:/openpnp-capture openpnp-capture-rpi3-arm64 bash
root@b7d320bc76de:/openpnp-capture# ldd build/libopenpnp-capture.so
	libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x00000040008d8000)
	libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000004000a65000)
	libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000004000b22000)
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000004000b46000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000004000b75000)
	/lib/ld-linux-aarch64.so.1 (0x0000004000000000)

Plus they are explicitly disabled on CMakeLists, right?:

https://github.com/openpnp/openpnp-capture/blob/master/CMakeLists.txt#L121

You are totally right on the three deps. Those dependencies are not needed on .travisci.yml because the TravisCI VMs already ships with them. Otherwise you find things like this on bare docker containers or VMs (what the users will find):

$ docker run -it -v $PWD:/openpnp-capture openpnp-capture-rpi3-arm64 ./bootstrap_linux.sh
/bin/mkdir: cannot create directory ‘build’: File exists
/openpnp-capture/bootstrap_linux.sh: 4: /openpnp-capture/bootstrap_linux.sh: cmake: not found


$ docker run -it -v $PWD:/openpnp-capture openpnp-capture-rpi3-arm64 ./bootstrap_linux.sh
/bin/mkdir: cannot create directory ‘build’: File exists
CMake Error at CMakeLists.txt:14 (project):
  The CMAKE_C_COMPILER:

    /usr/bin/cc

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.


CMake Error at CMakeLists.txt:14 (project):
  The CMAKE_CXX_COMPILER:

    /usr/bin/c++

  is not a full path to an existing compiler tool.

  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.


-- Configuring incomplete, errors occurred!
See also "/openpnp-capture/build/CMakeFiles/CMakeOutput.log".
See also "/openpnp-capture/build/CMakeFiles/CMakeError.log".

But you are spot on, they are not needed on this particular CI context and the error messages from TravisCI suggest that libjpeg-dev is interfering with newer libjpeg-dev headers and CMake/gcc.

@brainstorm
Copy link
Contributor Author

brainstorm commented Apr 17, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants