[cfe-dev] cross compiling with 6.0.0 not finding gcc paths - fix, what next

[Miller Henry via cfe-dev]

This is a follow up to my message from last april https://lists.llvm.org/pipermail/cfe-dev/2018-April/057693.html.  I've finally had time to dig deeper and fix my problem. I'm sending this in part so that if someone else has this problem maybe google will find this message and help them; and in part to ask if there is a patch that should be applied

For the record, I was seeing errors like the following in clang 4.0+ (3.9 and below work).  The ultimate cause is in my environment system headers and libraries are not found in a path clang knows to search by default.  Gcc is probably compiled with a hard coded path and so it works.

The first error I get is is from cmake:
    [2/2] Linking C executable cmTC_03cd5
FAILED: cmTC_03cd5
    : && /opt/jdx/tools//usr/local/share/icecc/bin//clang --sysroot=/home/user/repo/jdx/wr8-baytrail_64/buildbox -fno-omit-frame-pointer -gsplit-dwarf -fdiagnostics-color=always --target=x86_64-wrs-linux  --sysroot=/home/repo/jdx/wr8-baytrail_64/buildbox -rdynamic -O2 -L/home/repo/jdx/wr8-baytrail_64/buildbox/usr/local/lib -Wl,--gdb-index -lrt -lpthread -Wl,--disable-new-dtags CMakeFiles/cmTC_03cd5.dir/testCCompiler.c.o  -o cmTC_03cd5   && :
/opt/jdx/tools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-linux/x86_64-wrs-linux-ld: error: cannot open crtbegin.o: No such file or directory
/opt/jdx/tools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-linux/x86_64-wrs-linux-ld: error: cannot open crtend.o: No such file or directory
    /opt/jdx/tools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-linux/x86_64-wrs-linux-ld: error: cannot find -lgcc
    /opt/jdx/tools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-linux/x86_64-wrs-linux-ld: error: cannot find -lgcc
    clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)

My fix is in two parts, first in llvm/tools/clang/lib/Driver/Toolchains/Gnu.cpp, function Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
add to Suffixes[]:  (about line 2181)
      {CandidateTriple.str(), "../..", true},
Which is to say you need to make this get from the system lib directory to where the triple-specific directories are.

Then in llvm/tools/clang/lib/Driver/Toolchains/Linux.cpp, function Linux::addLibStdCxxIncludePaths()
Add to LibStdCXXIncludePathCandidates[]: (about line 867)
    LibDir.str() + "/include/c++/" + Version.Text,
Which is to say you need find libstdc++ relative to the lib directory.

>From here I see several options (there might be more)
1: someone can read this and say "I'll add that patch quick".  Since it is probably only a few minutes work for someone who knows the processes around committing code this is easiest
2: submit a bug report asking someone to apply the patch above.
3: I can go through the work of submitting code.  (This is mostly about getting corporate legal to approve, a formality that should just take a couple weeks)
4: Do nothing - there are infinite ways to configure a system file locations, and supporting all the weird ones is not worth the code clutter.  Distributions should use the common locations or patch clang themselves. (while somewhat hostile it isn't entirely a bad option)

If nobody suggests otherwise I'll take the lazy approach and choose 4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181002/b81f3fc2/attachment.html>