Kartikaya Gupta (email:kats@mozilla.staktrace.com) Reporter
	Description • 7 years ago

I'm trying to do a build with --enable-clang-plugin, but it's failing. The part that's failing is when it tries to run the clang plugin on the test files int build/clang-plugin/tests. Output from |mach build --verbose| is at [1]. As you can see there's no compiler error message, so I did some experimentation [2] and it looks like even though the compiler is not outputting any error message, it has an exit code of 1 which triggers the build failure. If I remove the |-Xclang -verify| options I do get an error message, which points to the "error_category" symbol being undefined in the plugin. Not really sure what to make of this, because the only use I can find of that symbol is at [3] and I don't see why that would be an issue.

[1] https://gist.github.com/staktrace/af3fb3f5ced087538e6126618d9f5fc0#file-01-build-output
[2] https://gist.github.com/staktrace/af3fb3f5ced087538e6126618d9f5fc0#file-02-fiddling-with-command-line
[3] https://searchfox.org/mozilla-central/rev/9bab9dc5a9472e3c163ab279847d2249322c206e/build/clang-plugin/VariableUsageHelpers.cpp#79

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Reporter
	Comment 1 • 7 years ago

After some more poking around I believe the problem I'm running into is basically the one described at [1] - that is, when building the libclang-plugin.so file, it links against libstdc++ from my ~/.mozbuild/clang/lib directory instead of the system one. So then later when it tries to run clang with the libclang-plugin.so loaded, it does so using the system libraries and thus cannot find some symbols.

I'm still trying to figure out how to fix this, though. Pretty much anything I try results in symbols from clangASTMatchers going missing, and I can't figure out why.

[1] https://searchfox.org/mozilla-central/rev/797c93d81fe446f78babf20894f0729f15f71ee6/build/autoconf/clang-plugin.m4#55-56

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Reporter
	Comment 2 • 7 years ago

So one of the workarounds I tried for the above problem was to drop the -L/home/.mozbuild/clang/lib from the linker invocation and replace -lclangASTMatchers with /home/.mozbuild/clang/lib/libclangASTMatchers.a. I also added -Wl,--verbose and inspected ht output to make sure the right versions of libstdc++ and libASTMatchers were being picked up. That seemed to be right. When I run clang with the resulting libclang-plugin.so, though, it complains about this symbol being missing (as alluded to in my previous comment):

 _ZN5clang12ast_matchers8internal14HasNameMatcherC1ESt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS9_EE

which demangles to this:

 clang::ast_matchers::internal::HasNameMatcher::HasNameMatcher(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)

and when I look to see this symbol in ~/.mozbuild/clang/lib/libclangASTMatchers.a, sure enough, it's not there. However there is a very similar symbol that demangles to this:

clang::ast_matchers::internal::HasNameMatcher::HasNameMatcher(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >)

and presumably that's causing the missing symbol error. I'm not sure why the symbol in libclangASTMatchers.a uses std::basic_string but the symbol required in libclang-plugin.so uses std::__cxx11::basic_string. I guess I need to keep fiddling with things.

	Steve Fink [:sfink] [:s:]
	Comment 3 • 6 years ago

I've just stumbled across the same stuff. Or at least, if I run the failed compile command with LD_DEBUG=libs, it complains about not finding _ZNSt3_V214error_categoryD2Ev

The symbol that exists in clang/lib/libstdc++.so is _ZNSt14error_categoryD2Ev

Those are:

% c++filt _ZNSt3_V214error_categoryD2Ev _ZNSt14error_categoryD2Ev
std::_V2::error_category::~error_category()
std::error_category::~error_category()

I'm rather confused by why they'd be different. The compile line for the relevant .o is:

/home/sfink/src/mozilla/clang/bin/clang++ -o host_VariableUsageHelpers.o -c  -I/home/sfink/src/mozilla/clang/include -fPIC -Qunused-arguments -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections -O3 -DNDEBUG -fno-exceptions -fno-rtti -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_NEW_ASTMATCHER_NAMES -DHAS_ACCEPTS_IGNORINGPARENIMPCASTS -fno-rtti -fno-exceptions -DDEBUG=1 -I/home/sfink/src/mozilla/build/clang-plugin -I/home/sfink/src/mozilla/obj-debug/build/clang-plugin -I/home/sfink/src/mozilla/obj-debug/dist/include -MD -MP -MF .deps/host_VariableUsageHelpers.o.pp -I/home/sfink/src/mozilla/obj-debug/dist/include/nspr /home/sfink/src/mozilla/build/clang-plugin/VariableUsageHelpers.cpp

I attempted to chase this down, but it led me into a twisty maze of inline namespaces, symbol versioning, and other scary stuff.

Anyway, I just wanted to build with --enable-clang-plugin and couldn't, despite using a single common version of clang and the libstdc++.so contained therein.

	Nathan Froyd [:froydnj]
	Comment 4 • 6 years ago

What you need is for bug 1451104 to land (I think); bug 1451104 comment 26 and maybe following has a partial, probably garbled, explanation of the vagaries of library lookup and whatnot.

	Steve Fink [:sfink] [:s:]
	Comment 5 • 6 years ago

(In reply to Nathan Froyd [:froydnj] (away 18 Oct - 21 Oct) from comment #4)
> What you need is for bug 1451104 to land (I think); bug 1451104 comment 26
> and maybe following has a partial, probably garbled, explanation of the
> vagaries of library lookup and whatnot.

Oh, nice! I didn't document everything I tried, but that explains more of the weirdness I ran into when attempting to force the correct header to be used. I guess I should have tried forcing use of the system libstdc++, I just didn't imagine that it could be finding that header. (Actually, I'm still confused, since strace seemed to say that it *wasn't* using the system header. Oh well.)

Thanks!

	Steve Fink [:sfink] [:s:]
	Comment 6 • 6 years ago

Just in case anyone else stumbles over the same problem before bug 1451104 magically fixes things, I was able to work around it by temporarily renaming /usr/lib/gcc to /usr/lib/gcc.away. That enabled clang to find the correct <system_error> header (as in, its own, rather than the system gcc's.)

I figured out the problematic path by injecting -v into the clang invocation where it compiled the relevant clang-plugin file (host_VariableUsageHelpers.o), so it printed out the system include search path. In my case, that was

  /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7

With /usr/lib/gcc gone, it found

  /home/sfink/src/mozilla/clang/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.4/../../../../include/c++/4.9.4

Nasssssty hobbitses.

	Kartikaya Gupta (email:kats@mozilla.staktrace.com) Reporter
	Comment 7 • 6 years ago

(In reply to Steve Fink [:sfink] [:s:] from comment #6)
> Just in case anyone else stumbles over the same problem before bug 1451104
> magically fixes things, I was able to work around it by temporarily renaming
> /usr/lib/gcc to /usr/lib/gcc.away. That enabled clang to find the correct
> <system_error> header (as in, its own, rather than the system gcc's.)

Nice, thanks for the tip! Just to flesh it out a bit more, running the clang invocation for host_VariableUsageHelpers.o with -v says this on my machine:

  Found candidate GCC installation: /home/kats/.mozbuild/clang/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.4
  Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5                  
  Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.4.0              
  Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6                  
  Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/6.0.0              
  Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5                
  Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0            
  Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6                
  Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.0.0            
  Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.4.0   

and after renaming /usr/lib/gcc to /usr/lib/gcc.away it says this:

  Found candidate GCC installation: /home/kats/.mozbuild/clang/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.4
  Selected GCC installation: /home/kats/.mozbuild/clang/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.9.4

and the include directories come from the selected GCC installation. I googled and apparently this is a common problem where clang picks an undesirable gcc installation, and there doesn't appear to be any legit solution. Somebody on the cfe-dev mailing list said they would accept a patch that added a command-line argument to pick the GCC installation [1] but AFAICT this never happened.

[1] http://lists.llvm.org/pipermail/cfe-dev/2016-March/047858.html