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

[Tom Stellard via cfe-dev]

On 10/02/2018 02:05 PM, Miller Henry wrote:
> 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

Your best bet here is probably to just use the standard layout that clang
expects:

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

If gcc can detect your non-standard path, and clang can't it would be worth filing
a bug for this too.

-Tom

> 
> 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
>>
>