18840, "mppf", "problems with -I and -L ordering", "2021-12-10T16:08:06Z"
When building a Chapel program, we use a C compiler to read dependencies (with the LLVM backend, we use an included clang for this) and a C compiler to do linking. We use -I options to control the header search path and -L options to control the linker search path. Similarly, these options are important for the build of the C runtime.
There are various workarounds that add paths to these in a variety of places, including system paths. At the very least we are adding -I/usr/local/include and -L/usr/local/lib in some Mac OS X configurations but I think it's very likely there are others. Additionally, if we simply use pkg-config information, we can end up with such paths to directories containing multiple packages, which might then contain a package we don't want to find as well.
One problem that can come up is when there is both a system installation of a package and it is bundled. This came up for a user in #18816 with RE2. If the -I or -L for the system path appears first in the generated compile or link lines, we have a problem because we will use the system version even if we were supposed to use the bundled one. I suspect that this problem can come up even for mason packages with a particular environment.
How can we fix this problem?
Some ideas:
- always use a path to a particular header / path to a particular library when working with our own third-party bundled versions (but this presents problems - I don't know of a practical way to do it for #includes and doing it for libraries means we have to choose static or dynamic linking ourselves rather than letting the linker decide)
- sort these arguments, so
-Ior-Loptions referring within$CHPL_HOMEappear before the others.