[flang][regression] Can't build flang. Incorrect dependencies specified for libFIROpenACCSupport.so?

[pawosm-arm]

I'm configuring the build as such:

cmake /path/to/llvm \
-DBUILD_SHARED_LIBS=True \
-DCMAKE_BUILD_TYPE=Debug \
-DLLVM_BINUTILS_INCDIR=/usr/include \
-DLIBOMP_FORTRAN_MODULES=True \
-DLIBOMP_COPY_EXPORTS=False \
-DLIBOMP_USE_HWLOC=False \
-DLIBOMP_OMPT_SUPPORT=ON \
-DLLVM_ENABLE_LLD=True \
-DLLVM_ENABLE_FFI=False \
-DLLVM_TARGETS_TO_BUILD="AArch64" \
-DLLVM_ENABLE_PROJECTS="llvm;clang;flang" \
-DLLVM_ENABLE_RUNTIMES="compiler-rt;openmp" \
-DCMAKE_INSTALL_PREFIX=/some/prefix

Since this machine has somewhat limited resources, I'm running 12 build processes only. The build fails as such:

[ 98%] Building CXX object tools/flang/lib/Optimizer/Transforms/CMakeFiles/FIRTransforms.dir/PolymorphicOpConversion.cpp.o
ld.lld: error: undefined symbol: Fortran::evaluate::ProcedureRef::~ProcedureRef()
>>> referenced by call.h:282 (flang/include/flang/Evaluate/call.h:282)
>>>               CMakeFiles/FIROpenACCSupport.dir/FIROpenACCTypeInterfaces.cpp.o:(Fortran::evaluate::FunctionRef<Fortran::evaluate::Type<(Fortran::common::TypeCategory)0, 1> >::~FunctionRef())
>>> referenced by call.h:282 (flang/include/flang/Evaluate/call.h:282)
>>>               CMakeFiles/FIROpenACCSupport.dir/FIROpenACCTypeInterfaces.cpp.o:(Fortran::evaluate::FunctionRef<Fortran::evaluate::Type<(Fortran::common::TypeCategory)0, 2> >::~FunctionRef())
>>> referenced by call.h:282 (flang/include/flang/Evaluate/call.h:282)
>>>               CMakeFiles/FIROpenACCSupport.dir/FIROpenACCTypeInterfaces.cpp.o:(Fortran::evaluate::FunctionRef<Fortran::evaluate::Type<(Fortran::common::TypeCategory)0, 4> >::~FunctionRef())
>>> referenced 19 more times

[pawosm-arm]

I've verified that I can build flang from before this commit: #122495 so this is a regression.

[thesamesam]

cc @mgorny

[mgorny]

I'm confused now. Did you bisect it to #120966 or #122495?

[pawosm-arm]

@mgorny I didn't bisect it, it would take more time than I have for it today. I've confirmed that I can build flang from one commit before the one which introduced the problematic file into flang, later on I've found your commit which changes the way dependencies are specified

[mgorny]

I'm building LLVM again today, so I'll try reproducing with a fresh ccache.

[pawosm-arm]

@mgorny seems it happens with the commit just before yours too, so again the last known 'good' commit was the one before #122495 and apparently your change despite touching the same files was not the root cause of this regression.

[mgorny]

I'm guessing that you're hitting the problem because of -DBUILD_SHARED_LIBS=True which isn't really well-tested. In fact, I thought it used not to work with Flang, but that was a long time ago.

[pawosm-arm]

Must have been a very long time ago indeed as for many reasons I'm building it like that for as long as I remember. The problem of wrongly specified dependencies returns from time to time, but usually the patches were released fairly promptly.

[mgorny]

Sorry, I recalled wrong. It was LLDB that caused problems, because its libraries used to have lots of cyclic dependencies. I used shared libs myself for a long time. My guess would be that some target is missing a direct dependency.