When is setting CHPL_LIB_PIC necessary for working build?

Chapel linker error and fix

This is the sequence of steps I took to produce and then resolve a linker error on my desktop running ArchLinux.

First attempt

  1. Clone the repository.
git clone https://github.com/chapel-lang/chapel.git
  1. Checkout the latest stable release.

git checkout 1.26.0

  1. Following the instructions under the "Using Chapel in its Preferred Configuration" heading on the Quickstart page in the documentation, set the CHPL_LLVM environment variable to the version of LLVM installed on your system.
export CHPL_LLVM=system
  1. Use one of the provided scripts to set other variables.
source util/setchplenv.bash
  1. Make.
make -j 6
  1. Check.
make check

The check fails with the output below.

[Info] Running minimal test script: $CHPL_HOME/util/test/checkChplInstall
[Info] Found executable chpl in /home/jan/Packages/chapel/bin/linux64-x86_64/chpl.
[Info] Found $CHPL_HOME directory: /home/jan/Packages/chapel
[Info] /home/jan/.chpl does not exist. Creating it.
[Info] Temporary test job directory: /home/jan/.chpl/chapel-test-yFawbT
[Info] Compiling $CHPL_HOME/test/release/examples/hello6-taskpar-dist.chpl
[Info] Compiling with CHPL_TARGET_COMPILER=llvm
[Fail] Test job failed to compile - Chapel is not installed correctly
[Fail] Compilation output:
/usr/bin/ld: /tmp/chpl-jan.deleteme-SMB4h7/chpl__module.o: relocation R_X86_64_32S against `.bss' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: failed to set dynamic section sizes: bad value
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
error: Make Binary - Linking
make: *** [Makefile:202: check] Error 1

Second attempt

Seeing the -fPIE in the error output, my crude instinct was to try to set the -fPIC compiler flag to see what that would do. I didn't immediately find a way to do that, but I did discover the CHPL_LIB_PIC environment variable in the Chapel documentation. So I decided to experiment with it.

  1. Set the CHPL_LIB_PIC variable.
export CHPL_LIB_PIC=pic
  1. Make
make -j 6
  1. Check
make check

The check appears to pass with the following output.

[Info] Running minimal test script: $CHPL_HOME/util/test/checkChplInstall
[Info] Found executable chpl in /home/jan/Packages/chapel/bin/linux64-x86_64/chpl.
[Info] Found $CHPL_HOME directory: /home/jan/Packages/chapel
[Info] /home/jan/.chpl does not exist. Creating it.
[Info] Temporary test job directory: /home/jan/.chpl/chapel-test-bN1Tkv
[Info] Compiling $CHPL_HOME/test/release/examples/hello6-taskpar-dist.chpl
[Info] Compiling with CHPL_TARGET_COMPILER=llvm
[Info] Test job compiled into /home/jan/.chpl/chapel-test-bN1Tkv/hello6-taskpar-dist
[Info] $CHPL_LAUNCHER=none is compatible with test script.
[Info] Running test job.
[Info] Test job complete.
SUCCESS: 'make check' passed!

Question

When is it appropriate/necessary to set the CHPL_LIB_PIC environment variable?

Also, here's the output of printchapelenv.

machine info: Linux monolith 5.17.4-arch1-1 #1 SMP PREEMPT Wed, 20 Apr 2022 18:29:28 +0000 x86_64
CHPL_HOME: /home/jan/Packages/chapel *
script location: /home/jan/Packages/chapel/util/chplenv
CHPL_TARGET_PLATFORM: linux64
CHPL_TARGET_COMPILER: llvm
CHPL_TARGET_ARCH: x86_64
CHPL_TARGET_CPU: native
CHPL_LOCALE_MODEL: flat
CHPL_COMM: none
CHPL_TASKS: qthreads
CHPL_LAUNCHER: none
CHPL_TIMERS: generic
CHPL_UNWIND: none
CHPL_MEM: jemalloc
CHPL_ATOMICS: cstdlib
CHPL_GMP: bundled
CHPL_HWLOC: bundled
CHPL_RE2: bundled
CHPL_LLVM: system *
CHPL_AUX_FILESYS: none

The error I saw looks similar to the ones seen in this topic.

Hi @jfkiviaho -

Some operating systems include a compiler that builds position independent code by default. The Chapel build system sometimes has problems when it does not operate in a consistent manner with that choice. In particular I think that the problem we are running into here is that gcc/the system linker/system libraries assume PIC compilation but that our integration with clang is not picking up on that.

I'm looking at getting an archlinux VM going in order to reproduce the issue.

I have been able to reproduce in a VM. I am thinking that having CHPL_LIB_PIC default to pic on this OS would be a reasonable way to address it.

Another way would be to check for --enable-default-pie in gcc -v -E

I have created this PR Add a workaround for arch linux pic support by mppf · Pull Request #19785 · chapel-lang/chapel · GitHub with one way to address the problem.

1 Like

Thanks a lot! I don't know why this didn't show up when I was searching different combinations of words from the error message, but looking up the --enable-default-pie flag you mentioned led me to the "right" StackOverflow post. It turns out that configuration was made standard for gcc in ArchLinux circa 2017, and that change caused some headaches.

1 Like

I appreciate the pull request for Arch support, even if the intersection of Arch users and Chapel users is just a handful. Another alternative might be to submit a Chapel package to the Arch User Repository (AUR). I've never submitted a package before. It could be a fun project.

I just ran into this issue building from the 1.26.0 release, but I'm delighted to see that it's already been fixed on main (thanks @mppf!)

@jfkiviaho There are dozens of us, dozens. I actually just reached out to the maintainer of the chapel AUR package earlier today to get added as a co-maintainer after which I plan to bump the version from 1.23.0 to 1.26.0. The chapel package should track major releases, but we could create a chapel-git AUR package that tracks chapel-lang/chapel directly (so would have the PIC fix automatically in this case, rather than having to add the variable define in the build() function for the chapel AUR package). Thoughts?

Awesome! I'm ashamed to admit that, at the time I'd posted my comment about submitting a package to AUR, I hadn't even checked if somebody had already done it. It's Arch. I shouldn't have assumed otherwise.

And, yes, I think that a chapel-git package would be a good idea. This may not be the only occasion when an Arch user might want to get ahead of the latest release. Are you thinking of adding the variable definition for the version 1.26.0 package and then removing it when the next version makes it obsolete?

I agree, having a git version is a good idea in general.

I just got added as a co-maintainer on chapel. Planning to update to 1.26 with the fix (yep, I'm just setting the bash variable manually now, but I'll remove on next release) tomorrow night. I'm still deciding whether I want llvm and clang as dependencies (such that llvm-clang is always backend) or to have them as optional dependencies at AUR install time. The former might be preferable for newer users so they automatically get the most complete version without hassle, but the latter allows more control. Any preference?

Once the chapel package is updated, we can take the script and make chapel-git with minor changes.