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

[Miller Henry via cfe-dev]

clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/jdx/tools/usr/clang-7.0.0/bin

find jdx -name crtbegin.o
jdx/wr8-baytrail_64/buildbox/usr/lib64/x86_64-wrs-linux/5.2.0/crtbegin.o

find jdx -name string
jdx/wr8-baytrail_64/buildbox/usr/include/c++/5.2.0/string

The above are the two paths not found in my system by the default clang that are fixed by the changes below.

-----Original Message-----
From: Tom Stellard [mailto:tstellar at redhat.com] 
Sent: Tuesday, October 2, 2018 3:56 PM
To: Miller Henry <MillerHenry at JohnDeere.com>; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] cross compiling with 6.0.0 not finding gcc paths - fix, what next

On 10/02/2018 01:25 PM, Miller Henry via cfe-dev wrote:
> 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
> 
>  

What base operating system are you using?

Can you post the output of
clang --verbose --sysroot=/home/user/repo/jdx/wr8-baytrail_64/buildbox

Can you provide the full path to the crtbegin.o/crtend.o/libgcc that you are trying to use?

-Tom


> 
> 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-lin
> ux/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-lin
> ux/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-lin
> ux/x86_64-wrs-linux-ld: error: cannot find -lgcc
> 
>     
> /opt/jdx/tools/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/x86_64-wrs-lin
> ux/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.
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>