Split bundled and system -I and -L arguments #18880

mppf · 2021-12-16T20:41:54Z

This PR started out as Patches needed for 1.25.1 Homebrew release, so here we start with some information about what went into the 1.25.1 Homebrew release as patches.

Changes from earlier PRs that were included in the Homebrew 1.25.1 formula:

Fix problem setting CHPL_LLVM_CONFIG (already merged to main from PR Fix a few problems that come up on FreeBSD 12.2 #18820)
fix(makefile): support python 3.10 (already merged to main from PR fix(makefile): support python 3.10 #18857)
Allow installing pip dependencies from source Allow installing pip dependencies from source #18926

Changes in this PR that were included in the Homebrew 1.25.1 formula:

Compute the Homebrew prefix with brew --prefix instead of always using /usr/local

Further changes in this PR:

Don't build bundled GMP for CHPL_GMP=system (for https://github.com/Cray/chapel-private/issues/2813)
Check that the runtime is built early in driver.cpp instead of during/after code generation (for different error message for missing configuration by changing CHPL_TARGET_COMPILER #18904).
Have printchplenv compute compile and link args, separated into bundled and system ones, for the runtime as well as the third-party packages. These are separated to address issue for problems with -I and -L ordering #18840. This removes the need for list-includes-and-defines and list-libraries which were saving this information from Makefiles for use by the LLVM backend (which does not use Make). Now, both the C backend and the LLVM backend can use the same information because these details are computed in printchplenv. In my opinion it is also easier to manage computing the appropriate system dependencies from the chplenv Python scripts rather than Makefiles.
To help with the above, adds a bit of Python code to parse pkg-config .pc files for use with bundled third-party packages. This is used for gasnet as an alternative to using a makefile snippet. This code also handles replacing /*/third-party/gasnet/install/ucp with the current third-party dir, to support installation.
Also to help with the above, moves chpl-threads.h and chpl-threads-impl.h to the fifo directory since these threading functions are only used for fifo.

Resolves #18904
Resolves #18840
Resolves https://github.com/Cray/chapel-private/issues/2813
Resolves #18816

Reviewed by @ben-albrecht with feedback from @ronawho - thanks!

full local testing (llvm backend)
full local testing (c backend)
Hello World works with gasnet or ugni on an XC with C and LLVM backends

Future Work:

have compileline.py compute compiler and link arguments using the Python scripts instead of getting it from Makefiles that get it from Python scripts.
see if we can add -lgmp only for programs using the GMP or BigInt modules (harder than it
seems at first because the -lgmp is computed before we start compiling - but would be easier if GMP/BigInt had the dependency expressed through mason)

mppf · 2022-01-06T20:39:22Z

@ben-albrecht @ronawho - I need to do some more testing on this in a few configurations but it's ready for review feedback. I'm hoping to get some feedback from both of you, and I suggest that @ben-albrecht can be the primary reviewer.

ronawho · 2022-01-06T20:55:04Z

I won't get a chance to do a real review until late Friday or more likely Monday, but at a quick glance this seems pretty sprawling. Does all of this belong in a single PR or should it be split out into different logical PRs?

mppf · 2022-01-06T21:00:23Z

@ronawho - yeah. many of the changes are interconnected to deal with #18840. It would be possible, I think, to pull these two parts out into separate PRs:

Work around problems building chpl-venv from source....
Don't build bundled GMP for CHPL_GMP=system

I might be also able to separate this:

Check that the runtime is built early in driver.cpp instead of during/after code generation

but that will cause conflicts because dealing with #18840 involved changing the same code.

My view is that the changes supporting the above are small enough that I'm not sure it's worth pulling them out. Open to suggestions though.

mppf · 2022-01-06T21:50:47Z

I've moved this

Work around problems building chpl-venv from source....

to PR #18926.

ben-albrecht · 2022-01-07T16:04:11Z

Should I move the new function compute_internal_compile_link_args in printchplenv.py into a new file inside of util/chplenv?

I vote for yes. I think we ought to keep printchplenv as small and readable as possible, since it's the main entry point for debugging or adding configuration features.

If so, what should I name it?

There are already a few utils modules in util/chplenv/ that printchplenv already imports:

./chpl_home_utils.py
./third_party_utils.py
./utils.py
./compiler_utils.py

Does one of those seem like a good fit to either of you? If not, I wouldn't oppose creating a new <something>_utils.py module for the compile link args.

mppf · 2022-01-07T16:06:59Z

How about compile_link_args.py or chpl_compile_link_args.py or compile_link_args_utils.py ? (Preference among these 3?)

ben-albrecht

I am OK with this approach at a high-level, and didn't see any major issues within the implementation. I am not too familiar with the configuration and computation of linker flags prior to this PR, so I mostly skimmed them and trust your translations are validated through some form of testing.

Also:

Clarifying question: if we were to add new third party dependencies in the future (hopefully not many more...), would we be required to port however they provide linker flags (Makefiles, pkgconfig, etc.) to Python like we've done here?
We may want to check timings of running printchplenv before and after this PR, since printchplenv gets call during compilation of Chapel programs. I doubt it's an issue, but it could be good to catch anything really slow in the new printchplenv changes.

Makefile

ben-albrecht · 2022-01-07T14:57:33Z

runtime/etc/Makefile.gmp-bundled

@@ -16,5 +16,5 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

-GEN_LFLAGS += -L$(GMP_LIB_DIR) -Wl,-rpath,$(GMP_LIB_DIR)
-
+#GEN_LFLAGS += -L$(GMP_LIB_DIR) -Wl,-rpath,$(GMP_LIB_DIR)


(applies to all runtime Makefiles) -- why comment out the flag definitions instead of removing?

Good point. Commenting them was useful to me during development but I can remove them now.

ben-albrecht · 2022-01-07T15:44:43Z

util/chplenv/third_party_utils.py

+#  $replace_third_party
+#
+@memoize
+def read_pkg_config_file(pcpath,


It would be useful if we had a simple test that (1) demonstrates what the parser is capable of, and (2) makes it easier to debug issues if we ever encounter any in the future (e.g., we expand the usage of this for another third party, or a gasnet update breaks it).

I am not sure where that test file should live at the moment though.

ben-albrecht · 2022-01-07T16:23:28Z

How about compile_link_args.py or chpl_compile_link_args.py or compile_link_args_utils.py ? (Preference among these 3?)

My preference order:

compile_link_args_utils.py -- seems like it belongs in a utils of some sort, and follows convention of other utils scripts
compile_link_args.py
chpl_compile_link_args.py -- chpl_ prefix is mostly used for modules that map directly to a chplenv

mppf · 2022-01-07T16:31:50Z

I can use compile_link_args_utils.py but in defense of chpl_compile_link_args.py -- these do map to CHPL_TARGET_BUNDLED_COMPILE_ARGS and variations (host vs target, bundled vs system, compile vs link) and so it's just not a single variable but a family of variables. In that way it is arguably not that different from chpl_gpu.py computing CHPL_GPU_CODEGEN as well as CHPL_CUDA_PATH. But you might not like that either.

mppf · 2022-01-07T16:36:10Z

Clarifying question: if we were to add new third party dependencies in the future (hopefully not many more...), would we be required to port however they provide linker flags (Makefiles, pkgconfig, etc.) to Python like we've done here?

Well, if they provide pkgconfig, or libtool .la files, or a program that prints out the linker flags, we can use those. We already had some logic to parse the libtool .la files in Python. If not, it is more like the LLVM-clang case here, and we would write Python code to compute the needed linker flags.

Also for smaller projects there really is only need for -I$CHPL_HOME/third-party/something/install/ucp/include -L$CHPL_HOME/third-party/something/install/ucp/lib -lsomething which our Python scripts can easily compute.

mppf · 2022-01-07T16:45:50Z

We may want to check timings of running printchplenv before and after this PR, since printchplenv gets call during compilation of Chapel programs. I doubt it's an issue, but it could be good to catch anything really slow in the new printchplenv changes.

For time ./util/printchplenv --all --internal

On a shared linux system:
before: 0m0.297s - 0m0.477s
after: 0m0.369s - 0m0.443s

On my home linux machine:
before: 0m0.123s - 0m0.127s
after: 0m0.150s - 0m0.165s

On my Mac:
before: .172 - .177 s
after: .264 - .312 s

So it is < 0.1 s. It might be interesting to one day cache these computations per terminal session or something, but I don't think it's worth fussing over right now, when it's 0.1 s out of 8 seconds.

mppf · 2022-01-07T16:54:13Z

Also the timings are a bit faster with CHPLENV_SKIP_HOST set which we do for the compiler running it.

ben-albrecht · 2022-01-07T17:14:41Z

I can use compile_link_args_utils.py but in defense of chpl_compile_link_args.py -- these do map to CHPL_TARGET_BUNDLED_COMPILE_ARGS and variations (host vs target, bundled vs system, compile vs link) and so it's just not a single variable but a family of variables. In that way it is arguably not that different from chpl_gpu.py computing CHPL_GPU_CODEGEN as well as CHPL_CUDA_PATH. But you might not like that either.

I see. I still prefer the utils name, because the contents seem like a general utility to me (especially pkgconfig parser), but I now feel less strongly about it. If you or @ronawho feel strongly about a name, I could be swayed.

ben-albrecht · 2022-01-07T17:17:31Z

We may want to check timings of running printchplenv before and after this PR, since printchplenv gets call during compilation of Chapel programs. I doubt it's an issue, but it could be good to catch anything really slow in the new printchplenv changes.

For time ./util/printchplenv --all --internal

On a shared linux system: before: 0m0.297s - 0m0.477s after: 0m0.369s - 0m0.443s

On my home linux machine: before: 0m0.123s - 0m0.127s after: 0m0.150s - 0m0.165s

On my Mac: before: .172 - .177 s after: .264 - .312 s

So it is < 0.1 s. It might be interesting to one day cache these computations per terminal session or something, but I don't think it's worth fussing over right now, when it's 0.1 s out of 8 seconds.

OK, that's good info to have either way. Thanks for collecting some data.

mppf · 2022-01-07T18:35:00Z

especially pkgconfig parser

I was storing this part in third_party_utils.py either way

--- Signed-off-by: Michael Ferguson <[email protected]>

issue chapel-lang#2813 --- Signed-off-by: Michael Ferguson <[email protected]>

--- Signed-off-by: Michael Ferguson <[email protected]>

@jhh67

Fix problem with ofi after PR #18880 Follow-up to PR #18880 to fix a problem with ofi testing. Even before PR #18880, we had * `CHPL_COMM_OFI_OOB` used in Makefiles and set by testing * `CHPL_RT_COMM_OFI_OOB` that was used in printchplenv before that PR and which I used after PR #18880 added to the printchplenv logic and used it during `chpl` invocations but that caused a problem because `CHPL_COMM_OFI_OOB` is set in testing (and `CHPL_RT_COMM_OFI_OOB` is not). This PR just changes the uses of `CHPL_RT_COMM_OFI_OOB` in printchplenv to `CHPL_COMM_OFI_OOB` because it's used for computing `-I` and `-L` flags and these don't happen at runtime. Reviewed by @jhh67 - thanks!

@mppf

Add ifndef's around GNU_SOURCE #defines I bumped into issues building Chapel because of redefined `_GNU_SOURCE`s. This PR prevents that by adding `ifndef`s. The issue likely started with #18880. [Reviewed by @mppf]

@ronawho

Fix problems with CHPL_SANITIZE after PR #18880 This PR fixes testing failures with address sanitizer configurations after PR #18880. I tested this fix with gcc and clang with the instructions in https://chapel-lang.org/docs/developer/bestPractices/Sanitizers.html#best-practices-sanitizers Reviewed by @ronawho - thanks! - [x] full local testing

Follow-up to PR chapel-lang#18880. The pkg-config .pc file we get gasnet flags from includes -O3 in the flags, which caused a failure for the test expressions/bradc/uminusVsTimesPrec (which is sensitive to optimization level and skipped with --fast). Previously the Makefile based approach avoided the -O3 by getting only particular kinds of flags. We could do that too with the pkg-config parsing as well but for now, just filter out the flags we don't want after we parse them. --- Signed-off-by: Michael Ferguson <[email protected]>

@ben-albrecht

Fix problem with CHPL_LIB_PIC after PR #18880 This PR fixes a problem with CHPL_LIB_PIC after PR #18880 * updates clangUtil.cpp to pass `-fPIC` if `CHPL_LIB_PIC` is set * include `-fPIC` in MAKE_COMP_GEN_CFLAGS / COMP_GEN_CFLAGS for C backend * use CHPL_MAKE_LIB_PIC in Makefiles since this is the variable computed by printchplenv - [x] test/interop/python//boolFunctions.chpl passes with C backend - [x] test/interop/python//boolFunctions.chpl passes with LLVM backend - [x] full local testing Reviewed by @ben-albrecht - thanks!

@ben-albrecht

Don't always add -O3 to flags when compiling with gasnet Follow-up to PR #18880. The pkg-config .pc file we get gasnet flags from includes -O3 in the flags, which caused a failure for the test test/expressions/bradc/uminusVsTimesPrec.chpl (which is sensitive to optimization level and skipped with --fast). As well as failures with CHPL_UNWIND testing. Previously the Makefile based approach avoided the -O3 by getting only particular kinds of flags. We could do that too with the pkg-config parsing as well but for now, just filter out the flags we don't want after we parse them. Reviewed by @ben-albrecht - thanks! - [x] test/runtime/stacktrace passes with CHPL_COMM=gasnet and CHPL_UNWIND=bundled - [x] full local gasnet testing

@dlongnecke-cray

Fix multi-locale interop after PR #18880 Follow-up to PR #18880 and PR #18974. * Fixes multilocale interop Makefile targets to use the new split -I and -L variables * Adjusts compileline to print out `-fsanitize=address` for `--libraries` when compiling with `CHPL_SANITIZE`. This matches the previous behavior but I'm not sure it makes sense, because `-fsanitize=address` is a C compiler flag rather than a flag `ld` can accept. In any case this change allows us to continue testing libraries with address sanitizer enabled. * Adds a test that should make the problem #18978 fixed easier to find, if it happens again. - [x] full local testing Reviewed by @dlongnecke-cray - thanks!

@mppf

Fix indexing bug in system libfabric chplenv [reviewed by @mppf] The old code was trying to index into a tuple with `()` instead of `[]`, which doesn't work in python (but does in chapel) so update to use `[]`. Follow on to #18880.

@dlongnecke-cray

Include system dependencies in mli link (#19036) Follow-up to #18985 and #18880. To resolve problems in qthreads+C backend configurations. Passed `COMM=gasnet`, `CHPL_LLVM=none` paratest. Tested and reviewed by @dlongnecke-cray.

@mppf

…gression add missing include path 'gpu/cuda' to get_runtime_includes_and_defines This aims to solve the regression described here: Cray/chapel-private#2961 where we're producing this error every time we run Chapel when we're using the gpu locale model: `stdchpl.h:78:10: fatal error: 'chpl-gpu-gen-includes.h' file not found` It looks like #18880 influenced what include paths get included when we link to the runtime library and that's introduced a regression in our GPU tests. It looks like these are now being computed in our Python scripts specifically by the `get_runtime_includes_and_defines` function in `util/chplenv/compile_link_args_utils`. In this PR I've modified that function so it will also add `runtime/include/gpu/cuda` [Reviewed by @mppf]

bradcray · 2022-02-03T00:48:05Z

compiler/main/driver.cpp

@@ -1584,6 +1597,47 @@ static void checkUnsupportedConfigs(void) {
  }
 }

+static void checkRuntimeBuilt(void) {
+  // no need for a runtime to be built for chpldoc,
+  // or if we stop before codegen with --stop-after-pass or --no-codegen


Sweet! I'd been curious whether moving this check up considered this case. Great to see that it did, thanks!

When the environment variable `CHPL_COMM_DEBUG` is defined we need to define the C preprocessor variable of the same name when building user programs, to adjust certain declarations in the runtime include files that are shared with the Chapel module code. Here, ensure that we do so. Support for this was inadvertently removed in chapel-lang#18880. Signed-off-by: Greg Titus <[email protected]>

@mppf

…grams Throw `-DCHPL_COMM_DEBUG` when building user programs, when appropriate. (Reviewed by @mppf and @jhh67.) When the environment variable CHPL_COMM_DEBUG is defined we need to define the C preprocessor variable of the same name when building user programs, to adjust certain declarations in the runtime include files that are shared with the Chapel module code. Here, ensure that we do so. Support for this was inadvertently removed in #18880.

In a few places our Makefiles were throwing target compiler '-I' options referencing `runtime/include/threads/...` paths that existed at one time but aren't present any more. I believe these include paths were removed in chapel-lang#18880, and these refs were missed just because they were partly built out of `make(1)` variable values. I spotted these references in some warning messages on a runtime build for some unrelated work. Signed-off-by: Greg Titus <[email protected]>

@ronawho

Remove references to nonexistent `runtime/include/threads/...` paths. (Reviewed by @ronawho.) In a few places our Makefiles were throwing target compiler '-I' options referencing runtime/include/threads/... paths that existed at one time but aren't present any more. I believe these include paths were removed in #18880, and these refs were missed just because they were partly built out of make(1) variable values.

@ronawho

Don't use libtool .la files to get 3p lib flags This PR updates Python scripts in util/chplenv to avoid using libtool .la files in most cases. The reason to avoid .la files is that they are removed by package installation on many systems (in particular, we are facing this problems in attempts to create an AUR package for Arch linux - see #19837). Instead of using libtool .la files, this PR changes the scripts use .pc files where available. The single exception is qthreads which doesn't yet build a .pc file and so we still use .la files there. But, common configurations of qthreads don't add any new dependencies, so the current fallback, if the .la file is missing, on `-Lpath/to/qthreads` `-lqthreads` should be sufficient. The .pc file support was added in #18880 and previous to this PR was only used for Gasnet. In more detail: * changed many calls to `get_bundled_link_args` to `pkgconfig_get_bundled_link_args` and adjusted `pkgconfig_get_bundled_link_args` to help make this easier * adjusted `pkgconfig_get_bundled_link_args` to add -rpath arguments similarly to what `get_bundled_link_args` was doing. I'm pretty sure it is only relevant for libraries that build a .so. It was added in 35f8e21 for libfabric support but the only .so I can see being built in a standard configuration is libgmp.so. Even in a `CHPL_COMM=ofi` build with `CHPL_LIBFABRIC=bundled` I am also not seeing any .so libraries other than libgmp.so. * Leaves the old behavior of `get_bundled_link_args` available as `libtool_get_bundled_link_args` which is currently only used with qthreads. Once the bundled qthreads can generate a .pc file, we can remove this function along with `handle_la`. Here is what we do with each 3p when using bundled, before and after this PR: Key: * libtool: parse .la file, add -Lpath -Wl,-rpath,path, add -lbla if .la file is missing * pkcgonfig: parse .pc file (does not add -L or -rpath arguments) * simple: add -Lpath -Wl,-rpath,path -lbla | 3p | Before this PR | This PR | | :--- | :--- | :--- | | gasnet | pkgconfig | pkgconfig | | gmp | libtool | pkgconfig | | hwloc | libtool | pkgconfig | | jemalloc | custom * | custom | | libfabric | libtool | pkgconfig | | libunwind | libtool | pkgconfig | | llvm | custom * | custom | | qthreads | libtool | libtool (for now) | | re2 | simple * | pkgconfig | Notes * jemalloc uses -ljemalloc and also runs jemalloc-config to get additional dependencies * llvm uses llvm-config but also -lbla for various clang libraries not covered in llvm-config. * re2 doesn't produce a .la file so we were falling back on "simple" previously even though the code looked for a .la file Future Work: * we add -rpath flags for 3rd party libraries that are only built as static libraries, which is mostly harmless, but it adds noise to the already complex link lines. We could consider skipping the -rpath args if the -L directory does not contain any .so files. * the .pc file can also include compilation flags which we currently ignore in most cases. The most likely way this could be relevant is for `-I/path/to/dependency` arguments. * qthreads still uses the .la file but we would like to use a .pc file. We opened sandialabs/qthreads#107 to ask qthreads to generate a .pc file. Reviewed by @ronawho - thanks! - [x] 'make check' works on Mac OS X - [x] 'make check' works on Ubuntu 22.04 - [x] compiler functions after a `make install` if all `.la` files are removed from install prefix on Ubuntu 22.04 - [x] draft AUR package can install, compile and run Hello World - [x] Hello World works on a system using `CHPL_COMM=ofi` with `CHPL_LIBFABRIC=bundled` - [x] full local testing

@arezaii

Move override-ld to printchplenv This PR addresses a future work item left by PR #18880. In particular, historically we have saved the linker to use in a file `override-ld` and then the LLVM backend reads this file and uses the selected linker in order to link the binary. We recently observed some problems with this strategy in the context of Homebrew. The Homebrew Chapel package had this `override-ld` file referring to clang in a particular location; but the Homebrew clang package was upgraded and clang was no longer available at that location. (See also Homebrew/homebrew-core#107405 ). So, this PR moves the `override-ld` logic to something supported by the chplenv Python scripts. One wrinkle with that is that the Makefile logic was using `GASNET_LD_REQUIRES_MPI` but that variable is not stored in the Gasnet .pc file that is used by the chplenv scripts in LLVM compilation. So, this PR uses the approximation of determining `GASNET_LD_REQUIRES_MPI` by searching for `mpi` in the `GASNET_LD` command name. Additionally, while debugging the issue, I noticed some odd things about the error handling within `executeAndWait`, so this PR cleans that function up a bit as well. It also removes some arguments to that function that aren't really necessary. It adds a C++ dyno test of this function to make sure the return value of the function is 0 when the command runs and something other than 0 when the command does not exist. The chpl-env-gen.h needed some adjustment to work with this change so I tidied it up to stop filtering out environment variables that often have characters that can't be in a `#define` and instead to use a more comprehensive pattern when replacing such characters with `_`. Future Work: * include https://bitbucket.org/berkeleylab/gasnet/pull-requests/554 in our bundled GASNet to actually use `GASNET_LD_REQUIRES_MPI` in the logic to match the previous behavior. Reviewed by @arezaii - [x] full local testing - [x] XC gasnet+aries testing - [x] XC ugni testing - [x] XC mpi testing - [x] Mac OS X testing - [x] testing Hello world on a real ibv system

This was referenced Dec 16, 2021

Always add -I/usr/local/include etc on darwin #18845

Closed

chapel 1.25.1 Homebrew/homebrew-core#91257

Closed

mppf force-pushed the 1.25.1-homebrew-patches branch 2 times, most recently from 77cb4b0 to f8c2307 Compare December 21, 2021 19:54

mppf mentioned this pull request Jan 4, 2022

different error message for missing configuration by changing CHPL_TARGET_COMPILER #18904

Closed

mppf force-pushed the 1.25.1-homebrew-patches branch from 7b8d186 to 3698967 Compare January 5, 2022 16:23

mppf marked this pull request as ready for review January 6, 2022 20:37

mppf force-pushed the 1.25.1-homebrew-patches branch from 30a5d5b to fcc958c Compare January 6, 2022 21:06

mppf mentioned this pull request Jan 6, 2022

linking problem on FreeBSD (12.2). #18816

Closed

mppf force-pushed the 1.25.1-homebrew-patches branch from fcc958c to c201b1d Compare January 6, 2022 21:50

mppf force-pushed the 1.25.1-homebrew-patches branch from c201b1d to 13378e1 Compare January 7, 2022 16:08

ben-albrecht reviewed Jan 7, 2022

View reviewed changes

mppf changed the title ~~Patches needed for 1.25.1 Homebrew release~~ Split bundled and system -I and -L arguments Jan 7, 2022

mppf added 3 commits January 10, 2022 11:43

Add -I and -L according to Homebrew prefix

60df192

--- Signed-off-by: Michael Ferguson <[email protected]>

Don't build bundled GMP for CHPL_GMP=system

b98fca6

issue chapel-lang#2813 --- Signed-off-by: Michael Ferguson <[email protected]>

Use homebrew prefix for finding LLVM

fee5695

--- Signed-off-by: Michael Ferguson <[email protected]>

mppf mentioned this pull request Jan 12, 2022

Fix problems with CHPL_SANITIZE after PR #18880 #18974

Merged

1 task

mppf mentioned this pull request Jan 12, 2022

Fix problem with CHPL_LIB_PIC after PR #18880 #18976

Merged

3 tasks

mppf mentioned this pull request Jan 12, 2022

Don't always add -O3 to flags when compiling with gasnet #18978

Merged

2 tasks

mppf mentioned this pull request Jan 13, 2022

Fix multi-locale interop after PR #18880 #18985

Merged

1 task

ronawho mentioned this pull request Jan 14, 2022

Fix indexing bug in system libfabric chplenv #19015

Merged

mppf mentioned this pull request Jan 18, 2022

Include system dependencies in mli link #19036

Merged

stonea mentioned this pull request Jan 27, 2022

add missing include path 'gpu/cuda' to get_runtime_includes_and_defines #19133

Merged

mppf mentioned this pull request Feb 2, 2022

llvm@11, chapel: migrate to Python 3.10 Homebrew/homebrew-core#90708

Closed

bradcray reviewed Feb 3, 2022

View reviewed changes

ronawho mentioned this pull request Feb 4, 2022

llvm verification failures with CHPL_COMM_DEBUG #19185

Closed

gbtitus mentioned this pull request Mar 16, 2022

Throw -DCHPL_COMM_DEBUG when building user programs, when appropriate. #19463

Merged

gbtitus mentioned this pull request Apr 27, 2022

Remove references to nonexistent runtime/include/threads/... paths. #19712

Merged

mppf mentioned this pull request Jun 1, 2022

Don't use libtool .la files to get 3p lib flags #19913

Merged

6 tasks

mppf mentioned this pull request Aug 4, 2022

Move override-ld to printchplenv #20385

Merged

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Split bundled and system -I and -L arguments #18880

Split bundled and system -I and -L arguments #18880

mppf commented Dec 16, 2021 •

edited

Loading

mppf commented Jan 6, 2022

ronawho commented Jan 6, 2022

mppf commented Jan 6, 2022

mppf commented Jan 6, 2022

ben-albrecht commented Jan 7, 2022

mppf commented Jan 7, 2022

ben-albrecht left a comment

ben-albrecht Jan 7, 2022

mppf Jan 7, 2022

ben-albrecht Jan 7, 2022

ben-albrecht commented Jan 7, 2022 •

edited

Loading

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

ben-albrecht commented Jan 7, 2022

ben-albrecht commented Jan 7, 2022

mppf commented Jan 7, 2022

bradcray Feb 3, 2022

Split bundled and system -I and -L arguments #18880

Split bundled and system -I and -L arguments #18880

Conversation

mppf commented Dec 16, 2021 • edited Loading

mppf commented Jan 6, 2022

ronawho commented Jan 6, 2022

mppf commented Jan 6, 2022

mppf commented Jan 6, 2022

ben-albrecht commented Jan 7, 2022

mppf commented Jan 7, 2022

ben-albrecht left a comment

Choose a reason for hiding this comment

ben-albrecht Jan 7, 2022

Choose a reason for hiding this comment

mppf Jan 7, 2022

Choose a reason for hiding this comment

ben-albrecht Jan 7, 2022

Choose a reason for hiding this comment

ben-albrecht commented Jan 7, 2022 • edited Loading

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

mppf commented Jan 7, 2022

ben-albrecht commented Jan 7, 2022

ben-albrecht commented Jan 7, 2022

mppf commented Jan 7, 2022

bradcray Feb 3, 2022

Choose a reason for hiding this comment

mppf commented Dec 16, 2021 •

edited

Loading

ben-albrecht commented Jan 7, 2022 •

edited

Loading