hard coded gcc paths in UPC++ configuration?

[C]

I was poking around in UPC++ looking at the following configuration file:

#!/bin/sh
CC='/share/opt/GCC/gcc-9/bin/gcc'
CFLAGS='-O3 --param max-inline-insns-single=35000 --param inline-unit-growth=10000 --param large-function-growth=200
000   -Wno-unused -Wunused-result -Wno-unused-parameter -Wno-address   '
CPPFLAGS="-DUPCXXI_ASSERT_ENABLED=0 -DUPCXXI_BACKEND=1 -DUPCXXI_BACKEND_GASNET_SEQ=1 -I/share/opt/upcxx-2022.3.
0/include -I/share/opt/upcxx-2022.3.0/upcxx.opt.gasnet_seq.smp/gen_include   -D_GNU_SOURCE=1 -DGASNET_SEQ     -
I/share/opt/upcxx-2022.3.0/gasnet.opt/include -I/share/opt/upcxx-2022.3.0/gasnet.opt/include/smp-conduit
 $_UPCXX_EXTRA_CPPFLAGS"
CXX='/share/opt/GCC/gcc-9/bin/g++'
CXXFLAGS='-std=c++11 -O2   -Wno-unused -Wunused-result -Wno-unused-parameter -Wno-address   '
GASNET_CONDUIT='smp'
GASNET_PREFIX='/share/opt/upcxx-2022.3.0/gasnet.opt'
LDFLAGS='-O3 --param max-inline-insns-single=35000 --param inline-unit-growth=10000 --param large-function-growth=20
0000  -Wno-unused -Wunused-result -Wno-unused-parameter -Wno-address     '
LIBS="-L/share/opt/upcxx-2022.3.0/upcxx.opt.gasnet_seq.smp/lib -lupcxx -L/share/opt/upcxx-2022.3.0/gasnet.
opt/lib -lgasnet-smp-seq    -lrt -L/.mount/share/opt/GCC/gcc-9.5.0/bin/../lib/gcc/x86_64-pc-linux-gnu/9.5.0 -lgcc -
lm  $_UPCXX_EXTRA_LIBS"
PPFLAGS="$CPPFLAGS"
LIBFLAGS="$LIBS"
GASNET_INSTALL="$GASNET_PREFIX"

I'm curious about the hard coded path "/.mount/share/opt/GCC/gcc-9.5.0/bin..." in LIBS.  In particular what is it there for? Does it really have to be hard coded to the particular compiler that built UPC++?

The reason I ask is kinda complicated...

We run standard CentOS 7 which comes with gcc 4.8.5 which is pretty useless at the point.  We build newer versions (typically many) so that the unbundled collection looks something like:

  /share/opt/GCC/
     ...
     gcc-9 -> gcc-9.5.0
     gcc-9.5.0/
     gcc-8 -> gcc-8.5.0
     gcc-8.5.0/
     gcc-8.4.0/
     gcc-8.3.0/
     gcc-8.2.0/
     gcc-8.1.0/
     gcc-8.0.0/
     ...

Doing things using the gcc-9 link is in response to the problem of accumulating a bunch of software built with different version of gcc over the years, and basically having to keep many old version of gcc around.  By using the gcc-9 link we can refresh gcc (say to gcc-9.6.0) then just move the link and things seem to work (at least so far, for the most point, if we're careful).  Ultimately I'd like to be able to remove prior minor versions unlike in the 8.x.0 example above.

Most of the UPC++ build processes seemed to retain the gcc location with the link, but for some reason that part in LIBS dereferenced the link and used the full absolute path.  (Even if it retained the link I'm guessing the .../x86_64-pc-linux-gnu/9.5.0 would still cause me problems.)

My immediate question is whether there's some way to build UPC++(s) so that I don't have to keep track of their dependencies on particular version(s) of gcc and/or have to rebuild UPC++(s) every time we update the (minor) version(s) of gcc.  (I'm happy to say that we'll stay within a major version without having to rebuild.)

This is of course an issue beyond UPC++ but UPC++ is a good example because it hard codes gcc information into it's configuration files.  I've looked around trying to find some guidance on how people at large installations maintain software without having to maintain/support all major/minor version of gcc forever, or worse yet, having to rebuild everything when a dependent version is updated but I've not found much information.  (Having multiple version isn't the issue, we do that now with modules and stuff, but managing the dependencies of software built on various gcc's is.)

Any suggestions welcome.

[Paul H. Hargrove]

I am afraid you really do need to rebuild UPC++ for each GCC you install.

We only support compilation and linking of UPC++ applications with the exact compiler used at configure time.  We find this to be the only completely reliable means to protect against subtle ABI incompatibilities, such as would occur if a change of version were to invalidate our detailed configure-time probes of compiler capabilities.

-Paul

--
You received this message because you are subscribed to the Google Groups "UPC++" group.
To unsubscribe from this group and stop receiving emails from it, send an email to upcxx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/upcxx/24598f96-dfb5-4c3e-9631-56d3a7afda29n%40googlegroups.com.

--

Paul H. Hargrove <PHHar...@lbl.gov>
Pronouns: he, him, his

Computer Languages & Systems Software (CLaSS) Group

Computer Science Department

Lawrence Berkeley National Laboratory

[C]

Ok, Thanks.  I was afraid this was just a fact of life, but if there was some better way to handle the dependency hell I certainly wanted to know about it.