LTO in LLVM3.8

Hi all,

I’ve been playing around with LLVM and LTO trying to compile some open-source projects.

Prior to the 3.8 release I had been using r250630 (if I remember correctly) and I was able to successfully build GamePlay (https://github.com/gameplay3d/GamePlay).

Sadly, since upgrading to 3.8 I am getting weird link-time-errors (error: undefined reference to ‘XYZ::~XYZ’).

It appears that these destructors are all virtual (although I cannot guarantee this does not break for non-virtual destructors too). The project generates an archive file which is then linked against to generate a few sample applications. During this linking phase, the above error (undefined reference to ‘XYZ::~XYZ’) appears.

I have upgraded the gold-linker, and I have tried using the current trunk of LLVM - both did not help. After three days of trying to debug this, I have run out of ideas.

Is this a known bug? I have found an issue on the gnu/binutils bugtracker that sounds similar (https://lists.gnu.org/archive/html/bug-binutils/2016-03/msg00235.html - bugged symbol resolution of weak symbols), although in my case compilation is aborted because of said errors.

Have there been any undocumented changes to LTO in 3.8 I should be aware of? Is there maybe a specific gold-linker version I have to use or should I use llvm-ar/nm now, instead of the ar/nm provided by binutils (which have worked for me before 3.8)?

Any help is greatly appreciated,

Daniel

you can also try to find exactly revision number (using binary search through revisions and using comments in suspicious commits) and try to ask author directly… at least it will be additional info…

In the linked bug, the issue is that symbols defined in multiple places (LTO and non-LTO) are provided by the linker plugin (which in GCC’s case marks the symbols as private). The error appears to be a difference in which symbol gold or ld picks as canonical. I don’t think it’s the same as the issue you’re seeing (unless you’re mixing LTO and non-LTO files).

I’d guess likely the ‘ar’ et al needs to be the llvm-ar. I have no experience with LTO in llvm, but with GCC unless one uses the “right” ar, then often LTO information is lost in the archive.

I have tried using llvm-ar/nm/ranlib instead of the ones provided by binutils, but I’m still getting the same errors.

Thank you for clarifying about the linked bug!

You can use gnu ar, but you have to make sure it is also using the plugin.

In the linked bug, the issue is that symbols defined in multiple places (LTO and non-LTO) are provided by the linker plugin (which in GCC’s case marks the symbols as private). The error appears to be a difference in which symbol gold or ld picks as canonical. I don’t think it’s the same as the issue you’re seeing (unless you’re mixing LTO and non-LTO files).

I’d guess likely the ‘ar’ et al needs to be the llvm-ar. I have no experience with LTO in llvm, but with GCC unless one uses the “right” ar, then often LTO information is lost in the archive.

Do I have to add new parameters to the build system with the new release?

It has been working before 3.8 and I have not changed any other settings.

Hi,

You may try to debug it by using -save-temps on the linker invocation, that should save the merged bitcode files before/after LTO, as well as the object file.
You can inspect these to figure at which stage the symbols disappear (llvm-nm, etc.)