Attempting to compile a rust program for usage on Mac. Configured Github Action as follows:
build_macos:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- name: Install required tools
run: sudo apt install libdbus-1-dev pkg-config libudev-dev libglfw3-dev libglew-dev
- name: Install required target
run: rustup target add aarch64-apple-darwin
- name: Build
run: cargo build --verbose
- name: Run tests
run: cargo test --verbose
- name: Build Release
run: cargo build --verbose --release --target=aarch64-apple-darwin
- name: Artifact MacOS
uses: actions/upload-artifact#v3
with:
name: Build MacOS
path: ./target/aarch64-apple-darwin/release/control_harts
retention-days: 5
which fails on Build Release Image
Investigating the log further points me to the following (full log):
= note: cc: error: unrecognized command-line option '-arch'
cc: error: unrecognized command-line option '-framework'
cc: error: unrecognized command-line option '-framework'
What would be the best way to solve this? If any further information is required, please let me know.
P.S. the program uses quite some libraries, but it does not appear to fail when compiling those, but only on the project itself. This makes me believe it maybe a configuration error on my end, but I cannot seem to figure that out.
P.P.S. the windows and linux tasks pass and produce a functioning executable, with all tests passing.
P.P.P.S. If it is preferable that I make a minimal piece of code or a repo that runs into this issue I could, but I am hoping the issue is just a simple oversight.
I was expecting a MacOS executable to pop out like the files for windows and linux do, but unfortunately the task runs into this error.
I tried looking for existing solutions for this problem, and I found:
(1, 2, 3 found after searching for the first line (-arch), 4 and 5 for the second line (-framework))
1. -> I cannot seem to configure these flags myself, as (from my very limited understanding) they are either part of the packages' build scripts or generated by rustc.
2. -> Unsolved github issue
3. -> Potentially solved github issue but it seems this is just part of the build script of that lib
4. -> Requires access to the MakeFile, which I may have but I cannot seem to figure out where it is.
5. -> for GoLang, and also without solution.
I was building with runs-on: ubuntu-latest as Azeem pointed out. After changing this to runs-on: macos-latest and removing the Install required tools task, it ran smoothly and created the distr as I wanted.
I cannot test this because I do not have a Mac, but the test cases pass so it seems ok.
Related
Let's consider the following problem, I have for example a project on Github for macOS in swiftUI.
I would like to make sure that through a Github action, I can create a dmg file for a release.
At the moment I haven't found Github action that allow you to do this.
I only found two libs that allow you to create dmg:
https://github.com/sindresorhus/create-dmg
https://github.com/create-dmg/create-dmg
If I wanted to create a Github Action that uses one of the two libs to create the dmg file, what could I do?
I thought of using the first one for example that I can install it via npm.
I thought of such a thing:
name: Release
on:
workflow_dispatch:
inputs:
jobs:
build:
name: Build
runs-on: macos-12
steps:
- uses: actions/checkout#master
- name: Install
run: npm install create-dmg
- name: Create
run: create-dmg 'NameApp.app' Build/Releases
But I get the following error:
Can you give me a hand?
Upon modifying my YAML file (see below) and initiating a push to GitHub, Travis CI does not want to start running the tests.
language: r
os:
- osx
- linux
before_install:
- brew install llvm libomp
- export CPP=/usr/local/opt/llvm/bin/clang
notifications:
email:
- never
branches:
only:
- master
I have run my YAML file through the YAML Lint checker:
http://www.yamllint.com
and the file checks as valid.
I have also updated and upgraded Homebrew, but the issue still persists.
Anyone know what might be the culprit here?
I want to cross-compile my Rust application on macOS to a Raspberry Pi 2. I searched a lot, but did not find a working solution. The last solution I tried was following this answer, but I couldn't get it to work.
macOS version: 10.13.5 (High Sierra)
rustup version: 1.11.0
cargo version: 1.26.0
What I did:
I cloned raspberrypi/tools
Installed arm-unknown-linux-gnueabihf and
armv7-unknown-linux-gnueabihf toolchains via rustup
Created .cargo/config file in the root of my project with following content
[target.armv-unknown-linux-gnueabihf]
linker = "/Users/user/Documents/Programming/RustProjects/hello-pi/../../Utils/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc"
Then I run cargo build --target=arm-unknown-linux-gnueabihf
I get the following error:
linking with /Users/user/Documents/Programming/RustProjects/hello-pi/../../Utils/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-gcc failed: exit code: 126
....
cannot execute binary file
It seems that I cannot run the ...gcc binary on my macOS machine. What would be the right way to cross-compile my Rust application from macOS to the ARM architecture for a Raspberry Pi 2?
rust-std library relies on glibc for things like syscalls and other low-level stuff, in order to cross-compile a Rust binary, one needs the appropriate C toolchain to be present as well. And this is where crosstool-NG comes into play.
crosstool-NG is in the toolchain building business. You’re going to use it to build yourself a toolchain for linking against ARMv7-compatible glibc, which will in turn allow you to successfully build your Rust binary for the Pi.
Clone the repo to a good location and bootstrap it:
cd /Users/USER
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
./bootstrap
Configure the installation and run it. To set where the tool goes on install, run:
./configure --prefix=$PWD
make
make install
export PATH="${PATH}:${PWD}/bin"
If all things went as expected, you should be able to run ct-ng version and verify the tool’s ready to go.
Configure the tool to build your ARMv7 toolchain. Luckily, crosstool-NG comes with some preset configurations, namely armv7-rpi2-linux-gnueabihf. Run:
ct-ng armv7-rpi2-linux-gnueabihf
There should be some output indicating that it’s now configured for armv7-rpi2-linux-gnueabihf. You just need to tell ct-ng where the toolchain ought to go:
mkdir /Users/USER/ct-ng-toolchains
cd /Users/USER/ct-ng-toolchains
ct-ng menuconfig
It can be overwhelming, as there are a ton of options, but stick to the Paths and misc options ---> menu option. Highlight it and hit Enter.
Under *** crosstool-NG behavior ***, scroll down until you see this long string:
(${CT_PREFIX:-${HOME}/x-tools}/${CT_HOST:+HOST-${CT_HOST}/}${CT_TARGET}) Prefix directory
- Hit Enter, delete the contents, and replace it with /Users/USER/ct-ng-toolchains.
- When you’re finished, hit Enter to confirm, scroll over and save, and then exit the configurator.
Build your toolchain (this may take half an hour):
ct-ng build
If it worked successfully, You should see a great many binaries now in /Users/USER/ct-ng-toolchains/armv7-rpi2-linux-gnueabihf/bin, namely armv7-rpi2-linux-gnueabihf-gcc.
For cargo to build using your new cross-compiler, you must:
Add the bin folder listed above to your PATH:
export PATH="${PATH}:/Users/USER/ct-ng-toolchains/armv7-rpi2-linux-gnueabihf/bin"
Update (or create) your global /Users/USER/.cargo/config file with (you can avoid this and use it in local .cargo/config):
[target.armv7-unknown-linux-gnueabihf]
linker = "armv7-rpi2-linux-gnueabihf-gcc"
3.Return to your Rust project and rerun cargo build:
cd /Users/USER/rust/hello
cargo build --target=armv7-unknown-linux-gnueabihf
The output should be something similar to:
Compiling hello v0.1.0 (file:///Users/USER/rust/hello)
Finished dev [unoptimized + debuginfo] target(s) in 0.85 secs
SCP your file over to the RPi and run the binary remotely:
scp target/armv7-unknown-linux-gnueabihf/debug/hello pi#192.168.1.43:
ssh pi#192.168.3.155 'chmod +x ~/hello && ~/hello'
Hello, world!
Credit goes to Kappel Codes I tried to summarize it here, as I found this question hours before I get that article :)
I have setup a simple go repository and configured TravisCI in the following way
language: go
go:
- 1.8.x
- master
gobuild_args: -ldflags "-X main.Version=${TRAVIS_TAG} -X main.buildTime=`date -u '+%Y-%m-%d_%I:%M:%S%p'` -X main.commitId=${TRAVIS_COMMIT}"
env:
- GOOS=linux GOARCH=amd64
- GOOS=windows GOARCH=amd64
after_success:
- ./build.sh
matrix:
allow_failures:
- go: master
This will essentially create 4 different builds in TravisCI. This is great for building a cross compilation project where I can build windows and linux binaries separately.
What I have been struggling to do is to create 1 single release in Github from all the binaries generated across those builds?
TravisCI documentation says they support releases but it is very vague on how to handle such a scenario.
Don't all the the build run on different virtual servers? If so how do I specify the file in each
If I setup a release will it run for each build? How does work with github, will it fail because the release will be attempted to be created several times?
Has anybody attempted this?
I've managed to setup TravisCI for my C++ hosted on Github project, it works fine.
I would like to move on to static analysis of my C++ code with Coverity Scan.
Automatic upload with TravisCI to Scan Coverity is possible but I can't find a way to make it work.
My git repository is simple, there are two branches: master and coverity_scan.
To avoid triggering static analysis each time I'm pushing something, all stuff related to Scan Coverity is filled in coverity_scan branch:
language: cpp
env:
global:
# The next declaration is the encrypted COVERITY_SCAN_TOKEN, created
# via the "travis encrypt" command using the project repo's public key
- secure: "UEHXnbNPk49F6Ta/+d+UZl74EhtIevExwCo1l6qBndw+LvIXQDNSfsFiIJsZVfSgacBEOtd7CSY6rtccDpGeS9oX5/G/pnCz/2Cu+NOCCWlpy/S3qcUtdz52nMVatTgRhEi14WfrghpHk7nxxSi1W5+VIBfew+In11V1Xln3W06hhGOOK17Ljik18LbjSY1K9yVwK60r3tzwzSBMm/MArsqCeigzw15c0THQUtLlaLg/5nfP31f1QV9W1WlF4zIHjzd0970M385vNDDPyG+qRCfMPDEJrWb9/hJVi5x2poHLDObSE25rSQqfzc5nfiSDbH888mkdbBZXSwMVveVEhufyEk0nxI0Tddh/WNYFs+7g1gyV9409Tj288Omx++zpb0jM7/++wgkRwvBnqfBN7GWxoZJ9rHTxauJ+IIOR1jvskCTFMFMLI3C1+IpT4SgV0i6v2PtRsdGbXgI9qywhmPEjC+lS6Nu/rZQItr27rZowvw1ITYwJrDX4YQOAZxJkYNLFdGfqEMSjx0nfq6Kpl/4PaHQ7X0OtnJNgssMk3LNcYEwV1tLhTt+qODONjB7yWilcsWo8yVurr4vnFS2nIV7N4XgBvJcZHWfovxiQhfJU2UQxDvCYlDJ0RpM8kxpze+LR2vh+BbYOgPcr7YKG9MoAbsQXDGiF7yTz1VjVQr4="
addons:
coverity_scan:
project:
name: LeFlou/Citadel
build_command_prepend: "cmake"
build_command: "make"
branch_pattern: coverity_scan
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- gcc-4.8
- g++-4.8
- clang
compiler:
- gcc
- clang
before_script:
- cmake .
script:
- make
install:
# Use g++4.8 and not 4.6 (C++11 missing)
- if [ "$CXX" = "g++" ]; then export CXX="g++-4.8" CC="gcc-4.8"; fi
branches:
only:
- coverity_scan
I want to trigger static analysis only when I push to coverity_scan, not building on TravisCI.
However, continuous integration must be working on master branch.
For the moment, code is only built but never uploaded to Coverity Scan.
What's wrong in my configuration ?
Edit:
I noticed in TravisCI validator multiple addons generate errors, only the last entry is processed. On the other hand, coverity_scan seem to build without trouble (I need apt to install more recent versions of g++, this is related to C++11 features).
Edit 20150910:
I merged both addons sections and this works.
But I'm still stuck on "Submitted first build" step.
I also changed COVERITY_SCAN_TOKEN, still this does not submit the build to Coverity Scan
TravisCI build with these changes
I think your problem is in build_command_prepend, it's cmake . and not cmake.
I think the problem might be that you indicated the branch you are using as coverity_scan here:
branch_pattern: coverity_scan
but you said you are pushing to the branch scan_coverity. So you might want to try pushing to coverity_scan instead?
I had trouble too but got it working eventually.
First go to your "Project Settings" in Coverity. Copy the token
Install the travis gem locally.
Then run:
travis encrypt -r <coverity_project_name> COVERITY_SCAN_TOKEN=<token>
For "coverity_project_name", use the name that is shown in your Coverity dashboard exactly as it appears.
You need to put the key generated by 'travis encrypt' into the "secure" field. So you should wind up with something like this:
- os: linux
dist: bionic
compiler: gcc
env:
- secure: "key generated by travis -r"
before_install:
- echo -n | openssl s_client -connect scan.coverity.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-
addons:
coverity_scan:
project:
name: "theimpossibleastronaut/rmw"
description: "Console recycle bin written in C"
notification_email:
build_command_prepend: "./configure"
build_command: "make"
branch_pattern: coverity_scan