building on OS X with custom gcc version
All, I’m trying to get 1.65.1 compiled on OSX 10.13.5. I have gcc 8.1 installed and I’ve added it to user-config.jam in the home directory. When I run "bootstrap.sh —with-toolset=gcc" it uses the Darwin gcc toolset, if I try —with-toolset=gcc-8.1 I get an unknown toolset error. If I use the Darwin-based gcc version of b2 and try and build with gcc 8.1 I get this series of errors: error: No best alternative for libs/context/build/asm_sources. and also linker errors from an unknown option -h on ld. I’m assuming this is because b2 built with Darwin gcc doesn’t have the right options for gcc 8. Is there a way to force b2 to be built based on gcc 8 so it gets the assembly and linker options right? Damien
AMDG On 06/24/2018 09:16 AM, Damien Hocking via Boost-users wrote:
I’m trying to get 1.65.1 compiled on OSX 10.13.5. I have gcc 8.1 installed and I’ve added it to user-config.jam in the home directory. When I run "bootstrap.sh —with-toolset=gcc" it uses the Darwin gcc toolset, if I try —with-toolset=gcc-8.1 I get an unknown toolset error.
If I use the Darwin-based gcc version of b2 and try and build with gcc 8.1 I get this series of errors:
error: No best alternative for libs/context/build/asm_sources.
Can you post the rest of the error? It should give a list of which alternatives matched or didn't match.
and also linker errors from an unknown option -h on ld. I’m assuming this is because b2 built with Darwin gcc doesn’t have the right options for gcc 8. Is there a way to force b2 to be built based on gcc 8 so it gets the assembly and linker options right?
It doesn't matter what compiler you use to build b2. No toolset information is compiled into the executable. In Christ, Steven Watanabe
On Jun 24, 2018, at 11:22 AM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
AMDG
On 06/24/2018 09:16 AM, Damien Hocking via Boost-users wrote:
I’m trying to get 1.65.1 compiled on OSX 10.13.5. I have gcc 8.1 installed and I’ve added it to user-config.jam in the home directory. When I run "bootstrap.sh —with-toolset=gcc" it uses the Darwin gcc toolset, if I try —with-toolset=gcc-8.1 I get an unknown toolset error.
If I use the Darwin-based gcc version of b2 and try and build with gcc 8.1 I get this series of errors:
error: No best alternative for libs/context/build/asm_sources.
Can you post the rest of the error? It should give a list of which alternatives matched or didn't match.
Thanks for the fast response. This is the full list: error: No best alternative for libs/context/build/asm_sources next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi not matched
and also linker errors from an unknown option -h on ld. I’m assuming this is because b2 built with Darwin gcc doesn’t have the right options for gcc 8. Is there a way to force b2 to be built based on gcc 8 so it gets the assembly and linker options right?
It doesn't matter what compiler you use to build b2. No toolset information is compiled into the executable.
In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Any idea what the ld unknown option: -h comes from? Damien
AMDG On 06/24/2018 01:32 PM, Damien Hocking via Boost-users wrote:
On Jun 24, 2018, at 11:22 AM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
On 06/24/2018 09:16 AM, Damien Hocking via Boost-users wrote:
I’m trying to get 1.65.1 compiled on OSX 10.13.5. I have gcc 8.1 installed and I’ve added it to user-config.jam in the home directory. When I run "bootstrap.sh —with-toolset=gcc" it uses the Darwin gcc toolset, if I try —with-toolset=gcc-8.1 I get an unknown toolset error.
If I use the Darwin-based gcc version of b2 and try and build with gcc 8.1 I get this series of errors:
error: No best alternative for libs/context/build/asm_sources.
Can you post the rest of the error? It should give a list of which alternatives matched or didn't match.
Thanks for the fast response.
This is the full list:
<snip>
Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX. You can work around the issue by finding this in libs/context/build/Jamfile.v2: # X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ; and making a copy, replacing clang with gcc.
and also linker errors from an unknown option -h on ld. I’m assuming this is because b2 built with Darwin gcc doesn’t have the right options for gcc 8. Is there a way to force b2 to be built based on gcc 8 so it gets the assembly and linker options right?
<snip>
Any idea what the ld unknown option: -h comes from?
You may need to set <linker-type>darwin in the toolset initialization. The relevant code was significantly rewritten and it should work automatically in 1.67 (1.66 has significant problems on darwin, and I don't recommend using it.) In Christ, Steven Watanabe
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
AMDG
On 06/24/2018 01:32 PM, Damien Hocking via Boost-users wrote:
On Jun 24, 2018, at 11:22 AM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
On 06/24/2018 09:16 AM, Damien Hocking via Boost-users wrote:
I’m trying to get 1.65.1 compiled on OSX 10.13.5. I have gcc 8.1 installed and I’ve added it to user-config.jam in the home directory. When I run "bootstrap.sh —with-toolset=gcc" it uses the Darwin gcc toolset, if I try —with-toolset=gcc-8.1 I get an unknown toolset error.
If I use the Darwin-based gcc version of b2 and try and build with gcc 8.1 I get this series of errors:
error: No best alternative for libs/context/build/asm_sources.
Can you post the rest of the error? It should give a list of which alternatives matched or didn't match.
Thanks for the fast response.
This is the full list:
<snip>
Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc.
This didn’t work, unfortunately the errors are the same as before. We decided to go with 1.67 seeing as this was a new platform for us. I can use LLVM/Clang 6.0 though, and that seems to be working on 1.67. I had to add the clang 6.0 entry to user-config.jam but that’s all.
and also linker errors from an unknown option -h on ld. I’m assuming this is because b2 built with Darwin gcc doesn’t have the right options for gcc 8. Is there a way to force b2 to be built based on gcc 8 so it gets the assembly and linker options right?
<snip>
Any idea what the ld unknown option: -h comes from?
You may need to set <linker-type>darwin in the toolset initialization. The relevant code was significantly rewritten and it should work automatically in 1.67 (1.66 has significant problems on darwin, and I don't recommend using it.)
In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG On 06/24/2018 08:53 PM, Damien Hocking via Boost-users wrote:
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
<snip> Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc.
This didn’t work, unfortunately the errors are the same as before.
I assumed that you were building for x86_64. If you're building for a different platform, then you'd need to find the alias for that architecture, instead.
We decided to go with 1.67 seeing as this was a new platform for us. I can use LLVM/Clang 6.0 though, and that seems to be working on 1.67. I had to add the clang 6.0 entry to user-config.jam but that’s all. <snip> In Christ, Steven Watanabe
2018-06-25 14:01 GMT+02:00 Steven Watanabe via Boost-users < boost-users@lists.boost.org>:
AMDG
On 06/24/2018 08:53 PM, Damien Hocking via Boost-users wrote:
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <
boost-users@lists.boost.org> wrote:
<snip> Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc.
This didn’t work, unfortunately the errors are the same as before.
I assumed that you were building for x86_64. If you're building for a different platform, then you'd need to find the alias for that architecture, instead.
We decided to go with 1.67 seeing as this was a new platform for us. I can use LLVM/Clang 6.0 though, and that seems to be working on 1.67. I had to add the clang 6.0 entry to user-config.jam but that’s all. <snip>
take a look at: https://www.boost.org/doc/libs/1_67_0/libs/context/doc/html/context/architec...
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
<snip> Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc. This didn’t work, unfortunately the errors are the same as before. I assumed that you were building for x86_64. If you're building for a different platform, then you'd need to find the alias for that architecture, instead.
Actually I'd like to understand what we did wrong. Just to be clear because terminology can be different, that's a full 64-bit build for 64-bit Intel architecture, correct? That is what we were after. Our build command for a gcc release build was: ./b2 --toolset=gcc-8.1 address-model=64 --stagedir=./stage64release --build-dir=./build64release --layout=system --without-mpi variant=release link=shared threading=multi runtime-link=shared install --prefix=./osx64release/indep --exec-prefix=./osx64release/bin --libdir=./osx64release/lib --includedir=./osx64release/include user-config.jam entry is: # gcc 8 using gcc : 8.1 : "/usr/local/bin/g++-8" ; Damien
AMDG On 06/25/2018 10:31 AM, Damien via Boost-users wrote:
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
<snip> Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc. This didn’t work, unfortunately the errors are the same as before. I assumed that you were building for x86_64. If you're building for a different platform, then you'd need to find the alias for that architecture, instead.
Actually I'd like to understand what we did wrong. Just to be clear because terminology can be different, that's a full 64-bit build for 64-bit Intel architecture, correct?
Right. Hmm. The easiest way to debug this is to use --with-context --debug-building which will show the build properties. (--debug-building generates a lot of output, so it's better to restrict it to Boost.Context only, hence --with-context). In particular, check the values of <abi> and <binary-format> for the asm_sources target. <architecture> and <address-model> should be correct, especially since you're passing address-model explicitly, but it wouldn't hurt to check them as well.
That is what we were after. Our build command for a gcc release build was:
./b2 --toolset=gcc-8.1 address-model=64 --stagedir=./stage64release --build-dir=./build64release --layout=system --without-mpi variant=release link=shared threading=multi runtime-link=shared install --prefix=./osx64release/indep --exec-prefix=./osx64release/bin --libdir=./osx64release/lib --includedir=./osx64release/include
user-config.jam entry is:
# gcc 8 using gcc : 8.1 : "/usr/local/bin/g++-8" ;
In Christ, Steven Watanabe
On 2018-06-25 10:48 AM, Steven Watanabe via Boost-users wrote:
AMDG
On 06/25/2018 10:31 AM, Damien via Boost-users wrote:
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <boost-users@lists.boost.org> wrote:
<snip> Okay. I see what's going on here. Boost.Context only supports darwin and clang on OSX.
You can work around the issue by finding this in libs/context/build/Jamfile.v2:
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>clang ;
and making a copy, replacing clang with gcc. This didn’t work, unfortunately the errors are the same as before. I assumed that you were building for x86_64. If you're building for a different platform, then you'd need to find the alias for that architecture, instead. Actually I'd like to understand what we did wrong. Just to be clear because terminology can be different, that's a full 64-bit build for 64-bit Intel architecture, correct? Right. Hmm. The easiest way to debug this is to use --with-context --debug-building which will show the build properties. (--debug-building generates a lot of output, so it's better to restrict it to Boost.Context only, hence --with-context).
In particular, check the values of <abi> and <binary-format> for the asm_sources target. <architecture> and <address-model> should be correct, especially since you're passing address-model explicitly, but it wouldn't hurt to check them as well.
That is what we were after. Our build command for a gcc release build was:
./b2 --toolset=gcc-8.1 address-model=64 --stagedir=./stage64release --build-dir=./build64release --layout=system --without-mpi variant=release link=shared threading=multi runtime-link=shared install --prefix=./osx64release/indep --exec-prefix=./osx64release/bin --libdir=./osx64release/lib --includedir=./osx64release/include
user-config.jam entry is:
# gcc 8 using gcc : 8.1 : "/usr/local/bin/g++-8" ;
We revisited this, and we got it to work building 1.67 with a Brew installed gcc 8. I thought I'd record it on the mailing list for anyone else who might need it. This is on OSX 10.13.5. It needs a new asm entry as above, under
# X86_64/SYSV/MACH-O alias asm_sources : asm/make_x86_64_sysv_macho_gas.S asm/jump_x86_64_sysv_macho_gas.S asm/ontop_x86_64_sysv_macho_gas.S : <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <toolset>gcc ; and we modified the user-config.jam to contain # gcc 8 using gcc : 8.1 : "/usr/local/opt/gcc8/bin/g++-8" : <cxxflags>"-std=c++14 -isystem /usr/local/opt/gcc8/include/c++/8.1.0" ; Debug b2 command was: ./b2 --toolset=gcc-8.1 address-model=64 --stagedir=./stage64debug --build-dir=./build64debug --layout=system --without-mpi variant=debug link=shared threading=multi runtime-link=shared install --prefix=./osx64debug/indep --exec-prefix=./osx64debug/bin --libdir=./osx64debug/lib --includedir=./osx64debug/include Release is: ./b2 --toolset=gcc-8.1 address-model=64 --stagedir=./stage64release --build-dir=./build64release --layout=system --without-mpi variant=release link=shared threading=multi runtime-link=shared install --prefix=./osx64release/indep --exec-prefix=./osx64release/bin --libdir=./osx64release/lib --includedir=./osx64release/include Damien
participants (4)
-
Damien -
Damien Hocking -
Oliver Kowalke -
Steven Watanabe