# When is setting CHPL\_LIB\_PIC necessary for working build? **URL:** \ **Category:** Users\ **Created:** [May 8, 2022, 11:21pm UTC](https://chapel.discourse.group/t/when-is-setting-chpl-lib-pic-necessary-for-working-build/12339 "2022-05-08T23:21:22Z")\ **Posts on this page:** 3\ **Page:** 2
**Author:** ![mppf](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@mppf](https://chapel.discourse.group/u/mppf)\ **Post date:** [May 18, 2022, 12:02pm UTC](https://chapel.discourse.group/t/when-is-setting-chpl-lib-pic-necessary-for-working-build/12339/21 "2022-05-18T12:02:53Z")
> Generalized package formats like flatpaks could also be nice, since we could hit all the distros at once. Agreed > I don't have any experience in this, but I could look into making one at some point in the future. That would be super, if you are up for it. Please try to keep us in the loop (e.g. with PRs to util/packaging with what you are planning). But for now let's see if we can get this AUR package into good shape. > I've done all of the `make clean` s and clobbers, but it doesn't appear there is an uninstall. I deleted the binary in `/usr/local/bin` manually, but it seems there's more. Yes you should be able to delete /usr/bin/chpl and /usr/lib/chapel /usr/share/chapel. We haven't created 'make uninstall' yet but have an open issue asking for it [make uninstall · Issue #6353 · chapel-lang/chapel · GitHub](https://github.com/chapel-lang/chapel/issues/6353) if you want to comment there / thumbs up / etc. Does `yay` have an uninstall feature that people would expect to work but that needs to be wired up to a `make uninstall` ? My limited experience with other packaging system is that they have their own way of tracking what files are installed by a package (and so they know which files to remove). And `yay -R chapel` seemed to remove it for me. I suppose you were just asking about removing a manual install, then. > `sudo pacman -S yay; yay -S chapel` I get ```Chapel # pacman -S yay error: target not found: yay ``` But, I found some instructions in [GitHub - Jguer/yay: Yet another Yogurt - An AUR Helper written in Go](https://github.com/Jguer/yay) . I was confused by the questions `yay` then asked me but I just answered 'n', hope that is reasonable. Anyway, the default configuration Chapel seems reasonable for the AUR package. You can actually build for multiple configurations and then install. On Homebrew, we build for the C backend with GCC as well as with LLVM, so that this can be toggled without having to build from source. So perhaps it should just match that. To do so, you would just `CHPL_TARGET_COMPILER=gnu make` as well before installing. You could also do a quickstart build (but if you do that, make sure to do an LLVM build afterwards). Depends on how many variations you want the AUR package to support vs. asking people doing something non-default to build from source. Also it looks like the `yay -S chapel` does not lead to a parallel build. Not sure it would help much in my VM but it might be nice to `make -j4` or something. I have no idea what is typical here for AUR packages. But at least we didn't have to build LLVM 🙂 > As for working the Arch packaging into the chapel repo in a PR, I plan to look at that tomorrow. Great. I think it's likely we'll have more intelligent feedback with that. > `undefined reference to `chpl\_hwloc\_get\_obj\_by\_depth' > `error: Make Binary - Linking` > I am hoping this is caused by my own source builds of Chapel interfering with the new AUR build No such luck - I see the same problem. One possibility is that your AUR package isn't installing something that is important. Another possibility is that it's a problem with `make install`. Our `configure` script actually supports two modes - storing all the Chapel stuff in one directory (--chpl-home) or splitting it among bin lib share directories (--prefix). The Homebrew formula uses the all-in-one directory and that might get you to something working sooner. But if there is a problem with `make install` with the other strategy we should fix it. I did my own experiment on my Arch VM with a --prefix install. Worked OK for quickstart and default builds. So I think it's more likely that the AUR scripting is missing something that should be installed or there is some other problem with it. If you make it into a PR then I can review it & see if I see anything obviously wrong (where I'm more familiar with the Chapel end than the AUR end, obviously). ---
**Author:** ![mppf](https://avatars.discourse-cdn.com/v4/letter/m/94ad74/32.png) [@mppf](https://chapel.discourse.group/u/mppf)\ **Post date:** [May 18, 2022, 12:18pm UTC](https://chapel.discourse.group/t/when-is-setting-chpl-lib-pic-necessary-for-working-build/12339/22 "2022-05-18T12:18:02Z")
Actually I'm not so sure if snap/flatpak can work for Chapel because, while we could make the compiler available as a snap/flatpak, how would the binaries built with `chpl` link to the runtime? Would they have to point to something inside of the snap/flatpak image? Seems like something that model would not support, but I don't know. ---
**Author:** ![ghbrown](https://yyz2.discourse-cdn.com/free1/user_avatar/chapel.discourse.group/ghbrown/32/194_2.png) [@ghbrown](https://chapel.discourse.group/u/ghbrown)\ **Post date:** [May 18, 2022, 6:18pm UTC](https://chapel.discourse.group/t/when-is-setting-chpl-lib-pic-necessary-for-working-build/12339/23 "2022-05-18T18:18:21Z")
> [@mppf](#): > > Does `yay` have an uninstall feature that people would expect to work but that needs to be wired up to a `make uninstall` ? My understanding is also "no", it takes care of this by tracking files. > [@mppf](#): > > it might be nice to `make -j4` or something `etc/makepkg.conf` has a configuration variable to set make flags across all package builds, where the user can put their preferred `-j ??` > [@mppf](#): > > I'm not so sure if snap/flatpak can work for Chapel because, while we could make the compiler available as a snap/flatpak, how would the binaries built with `chpl` link to the runtime I have zero experience with flatpak's besides installing and using them very infrequently, but I believe each package includes all the necessary runtime, with the possibility of sharing runtimes between apps. This leads to very simple (but possibly large) installs. > [@mppf](#): > > No such luck - I see the same problem. Darn. I'll just make a PR of the current broken version so we can collaborate and discuss more easily, then I'll do some trial and error with `configure` directory structures to try to get it working. Thanks for doing that `--prefix` test. [Previous page](https://chapel.discourse.group/t/when-is-setting-chpl-lib-pic-necessary-for-working-build/12339.md?page=1)