From evan.cooch at gmail.com Sun Mar 28 18:44:12 2021 From: evan.cooch at gmail.com (Evan Cooch) Date: Sun, 28 Mar 2021 14:44:12 -0400 Subject: [scl.org] devtoolset-9 | missing findloc intrinsic? Message-ID: Weird one (perhaps). Colleague and I trade back a large slug of FORTRAN code -- he is on a Windows machine, running mingw gfortran 9.2. He recently made a small code update that calls the findloc intrinsic, which is suppoted in 9.x.x.? Code compiles fine on his end. But, on my end, no such luck -- I'm on Linux boxes (CentOS 7), running gfortran 9.3.1 under scl devtoolset. When I try to compile the _exact_ same code, I get a fail at the end -- a few lines referring to a call to FINDLOC in one of the modules (something called estmat). /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: estmat.o: in function `filldm.3876': estmat.f90:(.text+0x1201): undefined reference to `_gfortran_findloc0_s1' Was wondering if anyone can give me some advice? Is there a way to 'look for' FINDLOC on my box (irony accidental), or (perhaps) if there is a packaging issue with devtoolkit for CentOS, is there something I can do to correct the problem? Many thanks in advance... If it matters, this is what 'gfortran -v' returns on my machine: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-9/root/usr --mandir=/opt/rh/devtoolset-9/root/usr/share/man --infodir=/opt/rh/devtoolset-9/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-9.3.1-20200408/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.cooch at gmail.com Sun Mar 28 22:22:11 2021 From: evan.cooch at gmail.com (Evan Cooch) Date: Sun, 28 Mar 2021 18:22:11 -0400 Subject: [scl.org] devtoolset-9 | missing findloc intrinsic? In-Reply-To: References: Message-ID: Thought I'd rule out the difference between 9.3.1 on my machines, and 9.2.0 on my colleagues machine. Fired up a VM with 9.2.0, but still get the same error. I had someone email me off list saying FINDLOC is 'twitchy' (his words) and perhaps not worth the effort. But still, puzzled why it seems to be 'found' for the mingw 9.x.x binaries under windows, but not within devtoolset-9. On 3/28/2021 2:44 PM, Evan Cooch wrote: > Weird one (perhaps). Colleague and I trade back a large slug of > FORTRAN code -- he is on a Windows machine, running mingw gfortran > 9.2. He recently made a small code update that calls the findloc > intrinsic, which is suppoted in 9.x.x.? Code compiles fine on his end. > > But, on my end, no such luck -- I'm on Linux boxes (CentOS 7), running > gfortran 9.3.1 under scl devtoolset. When I try to compile the _exact_ > same code, I get a fail at the end -- a few lines referring to a call > to FINDLOC in one of the modules (something called estmat). > > /opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/ld: > estmat.o: in function `filldm.3876': estmat.f90:(.text+0x1201): > undefined reference to `_gfortran_findloc0_s1' > > > Was wondering if anyone can give me some advice? Is there a way to > 'look for' FINDLOC on my box (irony accidental), or (perhaps) if there > is a packaging issue with devtoolkit for CentOS, is there something I > can do to correct the problem? > > Many thanks in advance... > > If it matters, this is what 'gfortran -v' returns on my machine: > > Using built-in specs. > COLLECT_GCC=gfortran > COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-9/root/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --enable-bootstrap > --enable-languages=c,c++,fortran,lto > --prefix=/opt/rh/devtoolset-9/root/usr > --mandir=/opt/rh/devtoolset-9/root/usr/share/man > --infodir=/opt/rh/devtoolset-9/root/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared > --enable-threads=posix --enable-checking=release --enable-multilib > --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-linker-build-id --with-gcc-major-version-only > --with-linker-hash-style=gnu > --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin > --enable-initfini-array > --with-isl=/builddir/build/BUILD/gcc-9.3.1-20200408/obj-x86_64-redhat-linux/isl-install > --disable-libmpx --enable-gnu-indirect-function --with-tune=generic > --with-arch_32=x86-64 --build=x86_64-redhat-linux > Thread model: posix > gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwheat5487 at gmail.com Wed Mar 31 15:43:14 2021 From: mwheat5487 at gmail.com (Matthew Wheaton) Date: Wed, 31 Mar 2021 15:43:14 -0000 Subject: [scl.org] devtoolset-6 and stdlibc++ Message-ID: Hi, This can't be the first time this has come up. I was very pleased to discover that I could install the gcc-6.3 compiler on a rhel6 host using devtoolset-6, but now discover that the accompanying stdlibc++ is not included. I provide shared libraries as part of an API for my work and it would be greatly beneficial to provide a runtime environment that includes the libraries that come with gcc-6.3. Unless the customer can use a rhel8 equivalent, this is the best way to provide C++11 functionality that I know of. Is there a way to provide the appropriate stdlibc++? Thanks, Matthew Wheaton -------------- next part -------------- An HTML attachment was scrubbed... URL: