building on OS X with custom gcc version

newer
setup_error: test unit with name...

Damien Hocking

24 Jun 2018 24 Jun '18

3:16 p.m.

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

Attachments:

attachment.html (text/html — 1.4 KB)

Show replies by date

Steven Watanabe

24 Jun 24 Jun

5:22 p.m.

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

Damien Hocking

7:32 p.m.

...

On Jun 24, 2018, at 11:22 AM, Steven Watanabe via Boost-users 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

Steven Watanabe

25 Jun 25 Jun

1:02 a.m.

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

Damien Hocking

2:53 a.m.

...

On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users 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 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

Steven Watanabe

12:01 p.m.

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

Oliver Kowalke

12:16 p.m.

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

Damien

4:31 p.m.

On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users 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

Steven Watanabe

4:48 p.m.

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

Damien

12 Jul 12 Jul

3:02 a.m.

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

2329

Age (days ago)

2347

Last active (days ago)

List overview

Download

9 comments

4 participants

participants (4)

Damien
Damien Hocking
Oliver Kowalke
Steven Watanabe