cross compiling with 6.0.0 not finding gcc paths - fix, what next

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

cross compiling with 6.0.0 not finding gcc paths - fix, what next

Yvan Roux 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.


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: cross compiling with 6.0.0 not finding gcc paths - fix, what next

Yvan Roux via cfe-dev
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-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.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: cross compiling with 6.0.0 not finding gcc paths - fix, what next

Yvan Roux 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:[hidden email]]
Sent: Tuesday, October 2, 2018 3:56 PM
To: Miller Henry <[hidden email]>; [hidden email]
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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: cross compiling with 6.0.0 not finding gcc paths - fix, what next

Yvan Roux 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:[hidden email]]
> Sent: Tuesday, October 2, 2018 3:56 PM
> To: Miller Henry <[hidden email]>; [hidden email]
> 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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev