Open russel opened 4 years ago
@russel - in order to allow us to reproduce this, can you tell us the linux OS version you are using (Ubuntu, Debian, ... ?) and also give us a couple of hints about how to install Linuxbrew to the point we can do brew install chapel
on that OS? Thanks.
@mppf I think the Linuxbrew home page is now as follows – Linuxbrew was a fork but has now been integrated into Homebrew, so Linuxbrew is not a separate thing:
https://docs.brew.sh/Homebrew-on-Linux
I am using Debian Sid. I believe Linuxbrew should work on Debian, Ubuntu, and Mint in identical fashion – but this is very much a belief statement.
So far I've been able to reproduce on a Debian VM. On that system, the master branch and 1.20 compile a "hello world" just fine under quickstart and standard configurations.
I used the homebrew-on-linux instructions but maybe sudo apt install linuxbrew-wrapper
would work on Ubuntu.
brew install chapel --build-from-source
worked for me.
I don't know what is wrong but... at a guess, maybe the automation used by Linuxbrew is using a compiler with different defaults (maybe it has some sort of hardening enabled) that is affecting the pre-built version stored in the "bottle"?
@mppf I did:
brew reinstall chapel --build-from-source
and then:
mason build
works out of the box. The problem thus comes down to the Homebrew formula not building both the static and dynamic files for the central bottling, at least for the Linux bottle – does it for the macOS bottle?
The homebrew formula just runs make
and doing so in the default configuration doesn't build both the static and dynamic files either. Normally this is fine (it just uses whatever the default is) but the issue appears to be the default is different between the linuxbrew build system and the systems we are trying it on.
@mppf Does that imply the Chapel make script is not doing the right default for the platform?
@russel - when the linuxbrew systems create binary "bottles" there are two platforms involved aren't there? One is the platform on which make
runs (presumably in linuxbrew cloud land somewhere), and the other is the end user system? Do you have some reason to believe that these two platforms are the same? (E.g. same OS version, same compiler, same glibc, ...) ? Obviously they need to be similar for the system to work, but they are apparently different (based on this issue, anyway).
Anyway it might be possible for the Chapel build scripts to detect the default static/dynamic preference for the currently used compiler, to adjust the build path to match. If we did that, something like the homebrew build could build both the shared and static libraries.
Another option is that we could adjust the homebrew script to always set CHPL_LIB_PIC=pic. That would make the situation match the situation on Mac OS X, where binaries are always PIC. However this might come at a performance cost.
(For history... CHPL_LIB_PIC behavior is related to PRs #11327 and #945).
@lydia-duncan @ronawho - any thoughts here?
Is there any reason to suspect that linuxbrew clients want the default PIC behavior that brew on Macs would provide? Or is linuxbrew really more about downloading and installing packages in a true-to-the-linux-platform fashion?
If it's really "I want the same experience as a Mac", then I think setting CHPL_LIB_PIC=pic is appropriate. If it's "I want the same experience for installing as a Mac, but I really care that I'm doing this on a linux machine", then I'm more inclined to build both the shared and static libraries
@lydia-duncan @mppf @ronawho I'd say that Linux users of Homebrew are looking for the native Linux experience. This would seem to support ensuring both dynamic and static libraries are build, especially the dynamic ones. Crucially though the built Mason executable in the default build (assume dynamic linkage) is not currently compatible with the default library build (static only). Changing the Homebrew build for Linux to build both static and dynamic libraries seems to be the right solutions? I'd suggest that assuming Linux users want the macOS is definitely not a good move.
@mppf / @lydia-duncan: I've lost the thread here. Is the expected fix for this something that needs to take place in the Chapel source tree (in which case it'd be nice to make it for the next release), or is it something that just needs to be updated in the linuxbrew formula? Or do we not know? Thanks!
@bradcray - I think this is probably the next step:
Anyway it might be possible for the Chapel build scripts to detect the default static/dynamic preference for the currently used compiler, to adjust the build path to match. If we did that, something like the homebrew build could build both the shared and static libraries.
There is also a temporary workaround available to us - we could adjust the linuxbrew package to set CHPL_LIB_PIC=pic
both in making the compiler and setting up to use it. We could consider doing that for this release and doing the more involved step later.
@mppf: For the temporary workaround, that's something we could do anytime, independently of the release cycle, right? (i.e., its a change to the LinuxBrew code base, not ours?).
@bradcray - yes
I was wondering how easy it would be to find out if the compiler was configured for position independent code and I found this:
It looks like we could compile something and test it with file
but only with a sufficiently new enough version of file
.
file
5.38 seems to require Debian Testing or Ubuntu 20.04 LTS
I may well be the only person using Linuxbrew (Linuxbrew is Homebrew but targeting Linux rather than OSX and macOS.) to install Chapel…
installs 1.20.0 exactly as required. I created a Mason build "Hello World" project.
However:
So the problem here is that by default Mason and chpl are assuming dynamic linking but only the static library is being build by the Linuxbrew formula.
I guess there is not a similar problem with Homebrew OSX and macOS. I have no idea if the Linuxbrew formula can cause both dynamic and static libraries to be build, but if it cannot Linuxbrew is a total bust for Chapel.