building on OS X with custom gcc version

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

building on OS X with custom gcc version

Boost - Users mailing list
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



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list

> On Jun 24, 2018, at 11:22 AM, Steven Watanabe via Boost-users <[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

Any idea what the ld unknown option: -h comes from?

Damien


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
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 <[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list


> On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
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 <[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list


2018-06-25 14:01 GMT+02:00 Steven Watanabe via Boost-users <[hidden email]>:
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 <[hidden email]> 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>




_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Jun 24, 2018, at 7:02 PM, Steven Watanabe via Boost-users
<[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
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
> <[hidden email]> 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
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: building on OS X with custom gcc version

Boost - Users mailing list
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
[hidden email] 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


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users