How can I use gcc7 / llvm7 on my project

As per topic, I have the following YAML file

language: node_js
env:
global:
- NODEVER=10.16.2
- GCCMAINVER=7
- RUBY_VER=2.6.3
- arch=x64
- mode=release
- NODEC_TESTS_TMPDIR=/tmp/nodec_tests_tmpdir
- LINPRJDIR=/home/travis/build/slee047/node-packer
- OSXPRJDIR=/Users/travis/build/slee047/node-packer

matrix:
include:

  • os: osx
    osx_image: xcode11
    node_js: $NODEVER
    env: TEST_SCRIPT=coffeescript_1
  • os: linux
    dist: bionic
    node_js: $NODEVER
    env: TEST_SCRIPT=coffeescript_1
  • os: osx
    osx_image: xcode11
    node_js: $NODEVER
    env: TEST_SCRIPT=coffeescript_2
  • os: linux
    dist: bionic
    node_js: $NODEVER
    env: TEST_SCRIPT=coffeescript_2
  • os: osx
    osx_image: xcode11
    node_js: $NODEVER
    env: TEST_SCRIPT=datetime
  • os: linux
    dist: bionic
    node_js: $NODEVER
    env: TEST_SCRIPT=datetime
    before_install:
  • if [ “$TRAVIS_OS_NAME” = “linux” ]; then sudo apt-get install nasm squashfs-tools gcc g++; CXX=“g+±${GCCMAINVER}” && CC=“gcc-${GCCMAINVER}”; fi
  • if [ “$TRAVIS_OS_NAME” = “osx” ]; then brew update; brew install nasm openssl squashfs “llvm@$GCCMAINVER”; fi
  • rvm install “${RUBY_VER}”
    addons:
    apt:
    sources:
    • ubuntu-toolchain-r-test
      packages:
    • “gcc-${GCCMAINVER}”
    • “g+±${GCCMAINVER}”
      install:
  • if [ “$TRAVIS_OS_NAME” = “osx” ]; then export PRJROOT_DIR=“$OSXPRJDIR”; clang --version; fi
  • if [ “$TRAVIS_OS_NAME” = “linux” ]; then export PRJROOT_DIR=“$LINPRJDIR”; fi
  • mkdir -p $NODEC_TESTS_TMPDIR
  • git clone --depth 1 GitHub - jashkenas/coffeescript: Unfancy JavaScript
  • cd $PRJROOT_DIR
    before_script:
  • python --version
  • gcc --version
  • g++ --version
  • nasm -v
  • mksquashfs -version
  • ruby --version
  • node --version
  • npm --version
    script:
  • ruby tests/$TEST_SCRIPT || exit $?

Basically, I am compiling an executable that requires Node.js, Ruby and C or C++ or both (I am not sure) as I am forking a project here: https://github.com/slee047/node-packer

Here is my build URL: https://travis-ci.org/slee047/node-packer/builds/569336291

I have been consistently failing in macOS test case because it is not using GCC-7 despite I have tried to install it via homebrew. This is what the system show when I run gcc --version:

Configured with: --prefix=/Applications/Xcode-11.0.app/Contents/Developer/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple clang version 11.0.0 (clang-1100.0.32.5) Target: x86_64-apple-darwin18.5.0 Thread model: posix InstalledDir: /Applications/Xcode-11.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Log URL: https://api.travis-ci.org/v3/job/569336294/log.txt

So how can I change my YAML file such that it will start using GCC 7 for the compilation?

By default gcc and g++ on OSX point to the AppleClang compiler. Like you do on Linux you can choose a specific compiler executable.

before_install:
- |
  if [[ ${TRAVIS_OS_NAME} == "osx" ]]; then
    eval "CC=gcc-7 && CXX=g++-7"
  fi

Note: In your script you are installing LLVM on OSX, not GCC.
Is this what you intended? Then you’ll have to call the compiler not with gcc and g++, but with clang-7 and clang++-7.
If you want to use GCC-7 on both Linux and OSX, than you can drop the test for the OS.

Suggestion: Why use such extensive scripts to set versions?
The YAML configuration to install the dependencies, seems to me easier to read and maintain:

addons:
  apt:
    packages:
    - nasm
    - squashfs-tools
  homebrew:
    packages:
    - nasm
    - openssl
    - squashfs
    - gcc@7

Both GCC 7 and LLVM/clang 7 come pre-installed on the Linux image bionic.

1 Like

In an OSX job, did you notice this message from the llvm@7 formula in the log?

To use the bundled libc++ please add the following LDFLAGS:
  LDFLAGS="-L/usr/local/opt/llvm@7/lib -Wl,-rpath,/usr/local/opt/llvm@7/lib"

llvm@7 is keg-only, which means it was not symlinked into /usr/local,
because this is an alternate version of another formula.

If you need to have llvm@7 first in your PATH run:
  echo 'export PATH="/usr/local/opt/llvm@7/bin:$PATH"' >> ~/.bash_profile

For compilers to find llvm@7 you may need to set:
  export LDFLAGS="-L/usr/local/opt/llvm@7/lib"
  export CPPFLAGS="-I/usr/local/opt/llvm@7/include"
1 Like

Eventually, I have found that the reason why I have failed to compile is due to the use of XCode 11 and some test cases may need some bug fix (Non-YAML / GCC / LLVM related).

I can pass the test in OSX now even with the much simplified YAML (Previously, I thought that it has something to do with the updates etc.)

Build Success in macOS only: https://travis-ci.org/slee047/node-packer/builds/570121410

Thank you very much.

Ok, I will take a look and see if this method helps or not (In XCode 11, it fails). Right now, I realized that I can compile this with default XCode 10.2 without installing gcc / g++ or llvm.

The build that fails with the use of XCode 11: https://travis-ci.org/slee047/node-packer/jobs/570150107

-> cd /tmp/nodec_tests_tmpdir/node-10.16.2-1.6.0
-> Running ["./configure "]
Did not find a new enough assembler, install one or build with
       --openssl-no-asm.
       Please refer to BUILDING.md
Failed running ["./configure "]

Searching “Did not find a new enough assembler” in the node-10.16.2 source code shows that it’s triggered by this check:

is_x86 = 'x64' in variables['target_arch'] or 'ia32' in variables['target_arch']

# supported asm compiler for AVX2. See https://github.com/openssl/openssl/
# blob/OpenSSL_1_1_0-stable/crypto/modes/asm/aesni-gcm-x86_64.pl#L52-L69
openssl110_asm_supported = \
  ('gas_version' in variables and float(variables['gas_version']) >= 2.23) or \
  ('xcode_version' in variables and float(variables['xcode_version']) >= 5.0) or \
  ('llvm_version' in variables and float(variables['llvm_version']) >= 3.3) or \
  ('nasm_version' in variables and float(variables['nasm_version']) >= 2.10)

if is_x86 and not openssl110_asm_supported:
  error('''Did not find a new enough assembler, install one or build with
   --openssl-no-asm.
   Please refer to BUILDING.md''')
1 Like

xcode_version should be 11.0, and my nasm -v prints the following:

NASM version 2.14.02 compiled on Dec 27 2018

So I think it could be a bug in XCode 11 or sort of, I don’t have this issue when I am using XCode 10.2 or lower in YAML. There is another compilation issues for Linux test cases though, but I shall leave that in Linux sub-forum.

Despite the attempt in the YAML file:

addons:
  homebrew:
    packages:
      - nasm
      - openssl
      - squashfs
      - llvm@8
matrix:
  include:
  - os: osx
    osx_image: xcode11
    node_js: $NODEVER
    env: TEST_SCRIPT=coffeescript_1
install:
  - if [ "$TRAVIS_OS_NAME" = "osx" ]; then export PRJROOT_DIR="$OSXPRJDIR"; export PATH="/usr/local/opt/llvm@8/bin:$PATH"; export LDFLAGS="-L/usr/local/opt/llvm@8/lib -Wl,-rpath,/usr/local/opt/llvm@8/lib"; export CPPFLAGS="-I/usr/local/opt/llvm@8/include"; clang --version; fi
  - if [ "$TRAVIS_OS_NAME" = "linux" ]; then export PRJROOT_DIR="$LINPRJDIR"; export CXX="g++-9" CC="g++-9"; gcc -- version; g++ -- version; fi
  - mkdir -p $NODEC_TESTS_TMPDIR
  - git clone --depth 1 https://github.com/jashkenas/coffeescript.git
  - cd $PRJROOT_DIR

It still failed with the same error

Log:

Therefore, I believe that it is XCode 11 related image issue. Perhaps I will try again when macOS 10.15 is released.

That’s for linking to other libraries. To use the compiler as an executable, add it to PATH.

You can also request debug mode for your repo by sending an e-mail to support@travis-ci.com and/or debug that Python code to find out what the erroneous values are and where they come from.

Also maybe related:

Thanks for the patience in this issue.

Apparently there are several reasons why the test fails, and it is separated by OS environment.

For macOS alone, I can confirm that

  1. XCode 10.2 works without the need of installing GCC-7 or LLVM-7 separately, but the XCode 11 environment just fails.
    Job log:
    https://travis-ci.org/slee047/node-packer/jobs/570410532

  2. Some timeout issue (Typically happens in only one of the 3 test cases)

  3. Some invalid test cases (Or rather, cases in the test suite may have not updated). This happens in only one of my 3 test scenarios, but it can be considered as fixed.

Therefore, I will write in support instead. Thank you very much. :slight_smile: