[LLVMdev] tools/llvm-config/find-cycles.pl

[Óscar Fuentes]

reed kotler <rkotler at mips.com> writes:

> We've had some problems with false complaints about circular 
> dependencies from tools/llvm-config/find-cycles.pl in the past but just 
> worked around them.
>
> Sometimes if you have nested directories which include header files from 
> other enclosing directories you get this problem.
>
> Today we realized that it seems to be Ubuntu related ( or perhaps the 
> version of perl on Ubuntu or some other tool used by llvm make).
>
> lvm[1]: Checking for cyclic dependencies between LLVM libraries.
> find-cycles.pl: Circular dependency between *.a files:
> find-cycles.pl:   libLLVMMipsCodeGen.a libLLVMMipsDesc.a
> llvm[1]: Building llvm-config script.
> cat: /home/rkotler/jack/build/tools/llvm-config/FinalLibDeps.txt: No 
> such file or directory
> make[1]: *** [/home/rkotler/jack/build/Debug+Asserts/bin/llvm-config] 
> Error 1
> make[1]: Leaving directory `/home/rkotler/jack/build/tools/llvm-config'
>
>
> But the same make on a red hat machine works just fine.
>
> We could tar up our exact source tree and give it to whomever works on 
> this script.
>
> I'm not interested in debugging this perl script myself.
>
> ????
>
> Thoughts.

I don't think the problem is find-cycles.pl. The problem is, more
likely, in GenLibDeps.pl. Or, to be more precise, either in the
binutils-related tool (nm) that GenLibDeps.pl uses for doing the job or
in how the compiler places some internally used symbols such as virtual
tables in object files. We had similar problems in the cmake build, with
library dependency info varying not only in different distros, but on
the very same machine on consecutive runs of the build (being this
project full of compiler experts, I asked here about what could cause
that, without much success, but I guess that it is somewhat related to
parallel builds.)

My experience says that the problem always involves vtables and/or other
stuff automatically generated by the compiler (C++ destructors, etc.)