1.51 build issue, I think...
I am new to building boost, so I apologize if this is an uninformed question. I was able to build the boost 1.49 and 1.50 libraries using qcc 4.4.2 (QNX's gcc 4.4.2) without major issues. Boost 1.51 has added a new wrinkle, and I'm not sure how to address it. Here's a snipit from the build.log. Any help is appreciated. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf not matched next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc not matched
On Aug 21, 2012, at 3:32 PM, Lemay.Steve <Steve.Lemay@IGT.com> wrote:
I am new to building boost, so I apologize if this is an uninformed question. I was able to build the boost 1.49 and 1.50 libraries using qcc 4.4.2 (QNX’s gcc 4.4.2) without major issues. Boost 1.51 has added a new wrinkle, and I’m not sure how to address it. Here’s a snipit from the build.log. Any help is appreciated.
How are you building it? b2 toolset=qcc ? I did some cleanup on the config system for 1.51; it's possible I broke qcc, since I don't think that have any testers for it. Tell me more, please. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
do you use the bjam version provided by boost-1.51? on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and wich ABI is used. otherwise QNX is not supported by boost.context. Oliver Am 22.08.2012 00:32, schrieb Lemay.Steve:
I am new to building boost, so I apologize if this is an uninformed question. I was able to build the boost 1.49 and 1.50 libraries using qcc 4.4.2 (QNX's gcc 4.4.2) without major issues. Boost 1.51 has added a new wrinkle, and I'm not sure how to address it. Here's a snipit from the build.log. Any help is appreciated.
error: No best alternative for libs/context/build/asm_context_sources
next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf
not matched
next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>intel
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel
not matched
next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin
not matched
next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel
not matched
next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc
not matched
next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>intel
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel
not matched
next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin
not matched
next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel
not matched
next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc
not matched
next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc
not matched
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
do you use the bjam version provided by boost-1.51? Yes, bjam is created on the first build. I'm using QNX SDK 6.5 SP1 on a Windows hosted development environment. VS2012 also installed. Contents of batch file provide below. (gcc 4.4.2 support, and gcc 4.7.1 prototype) on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and which ABI is used? Although the SDK support several target processors, this builds target for x86 (AMD K8 architecture - 32-bit addressing). I believe ELF and SYSV (still need to verify) and the boost toolset configuration is set to qcc (not gcc). Is there a good/simple way to verify the ABI? As I am not very familiar with bjam syntax - could the boost_1_51_0\libs\context\build\jamfile.v2 just be confused because of the toolset definition? Considering qcc wraps gcc...? I'm looking specifically at: rule configure ( properties * ) { local result ; if ( ! ( <toolset>gcc in $(properties) || <toolset>intel in $(properties) || <toolset>msvc in $(properties) ) ) { result = <build>no ; ECHO "toolset not supported" ; } return $(result) ; } ================= Example of building boost for use with QNX 6.5 SDK ================== @ECHO OFF :: In file tools\build\v2\tools\qcc.jam, in the "actions piecemeal archive" block, replace the line: ar rc "$(<)" "$(>)" with the following: ntox86-ar rc "$(<)" "$(>)" :: For Boost 1.50 modify the following files until the bug is addressed. :: boost\serialization\factory.hpp - line 27 remove "|| defined (__QNXNTO__)" :: boost\test\impl\execution_monitor.ipp - add to line 56 "|| defined (__QNXNTO__)" remove line 61-66 as no longer necessary. CLS SET DRIVE=D: SET BOOSTVER=1_51_0 @PUSHD %DRIVE%\boost_%BOOSTVER% @IF NOT EXIST bjam.exe call bootstrap @IF NOT EXIST bjam.txt bjam --help > bjam.txt @IF NOT EXIST bjam_libs.txt bjam --show-libraries > bjam_libs.txt @IF NOT EXIST bjam_obscure_options.txt bjam --help-options > bjam_obscure_options.txt @IF EXIST build.log del build.log @ECHO ON @ECHO Building Boost libraries for QNX 6.5.x @REM Static library @REM bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-fnothrow-opt,-std=c++11,-std=gnu++11" --without-mpi --without-python install >build.log 2>&1 bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x" --without-mpi --without-python install >build.log 2>&1 @POPD SGL steven.lemay@igt.com<mailto:steven.lemay@igt.com> From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oliver Kowalke Sent: Tuesday, August 21, 2012 9:27 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] 1.51 build issue, I think... do you use the bjam version provided by boost-1.51? on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and wich ABI is used. otherwise QNX is not supported by boost.context. Oliver Am 22.08.2012 00:32, schrieb Lemay.Steve: I am new to building boost, so I apologize if this is an uninformed question. I was able to build the boost 1.49 and 1.50 libraries using qcc 4.4.2 (QNX's gcc 4.4.2) without major issues. Boost 1.51 has added a new wrinkle, and I'm not sure how to address it. Here's a snipit from the build.log. Any help is appreciated. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf not matched next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>o32 <architecture>mips1 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <target-os>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <target-os>darwin not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>msvc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc not matched _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 22 August 2012 16:47, Lemay.Steve <Steve.Lemay@igt.com> wrote:
@REM bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-fnothrow-opt,-std=c++11,-std=gnu++11" --without-mpi --without-python install >build.log 2>&1
bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x" --without-mpi --without-python install >build.log 2>&1
Since the error seems to be caused by context, try adding '--without-context' to the bjam call.
Adding --without-context surely solved the build problem. But, it also leaves boost 1.51 on QNXNTO devoid of boost.context. Will it be missed? If there is a better long-term solution to the boost.context build issue - please let me know, I'd be happy to try it. SGL steven.lemay@igt.com -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Wednesday, August 22, 2012 9:02 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] 1.51 build issue, I think... On 22 August 2012 16:47, Lemay.Steve <Steve.Lemay@igt.com> wrote:
@REM bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-fnothrow-opt,-std=c++11,-std=gnu++11" --without-mpi --without-python install >build.log 2>&1
bjam -a -q -j4 --prefix=%DRIVE%\boost --build-type=minimal --build-dir=%DRIVE%\boostBuild_QCC_%BOOSTVER% --layout=system toolset=qcc target-os=qnxnto threadapi=pthread --variant=release link=static threading=multi runtime-link=shared cxxflags="-DFD_SETSIZE=2048 -march=k8-sse3 -mtune=k8-sse3 -mmmx -msse3 -mfpmath=sse -mno-3dnow -mstackrealign -Wc,-fPIC,-std=c++0x,-std=gnu++0x" --without-mpi --without-python install >build.log 2>&1
Since the error seems to be caused by context, try adding '--without-context' to the bjam call. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Am 22.08.2012 17:47, schrieb Lemay.Steve:
/do you use the bjam version provided by boost-1.51?///
Yes, bjam is created on the first build. I'm using QNX SDK 6.5 SP1 on a Windows hosted development environment. VS2012 also installed. Contents of batch file provide below. (gcc 4.4.2 support, and gcc 4.7.1 prototype)
/on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and which ABI is used?/
Although the SDK support several target processors, this builds target for x86 (AMD K8 architecture -- 32-bit addressing). I believe ELF and SYSV (still need to verify) and the boost toolset configuration is set to qcc (not gcc). Is there a good/simple way to verify the ABI?
As I am not very familiar with bjam syntax - could the boost_1_51_0\libs\context\build\jamfile.v2 just be confused because of the toolset definition? Considering qcc wraps gcc...? I'm looking specifically at:
rule configure ( properties * )
{
local result ;
if ( ! ( <toolset>gcc in $(properties)
|| <toolset>intel in $(properties)
|| <toolset>msvc in $(properties) ) )
{
result = <build>no ;
ECHO "toolset not supported" ;
}
return $(result) ;
}
I don't know qcc, but if I look inside tools/build/v2/tools/qcc.jam it is derived from gcc. The question is if you could use gcc as toolset value on QNX too (bjam toolset=gcc)? Is GNU as available and installed on QNX (required to compile the assembler)? Maybe you could try to add <toolset>qcc in $(properties) in rule configure. Is a free version of QNX available? AFAIK some years ago it was but the new owner of QNX has revoked the free license. Oliver
The qcc toolset basically "wraps" the gcc environment. The current supported compiler is gcc 4.4.2. I believe QNX provides free downloads of the development environment, as well as a pre-made QNX hosted VM. The 30 day trial license can be found here: http://www.qnx.com/products/evaluation/ I get the same issue with qcc 4.7.1 (which is currently considered prototype). I seemed to get the same result with this change. (but, I don't really know specifically what I'm doing in bjam files) if ( ! ( <toolset>gcc in $(properties) || <toolset>qcc in $(properties) || <toolset>intel in $(properties) || <toolset>msvc in $(properties) ) ) SGL steven.lemay@igt.com<mailto:steven.lemay@igt.com> From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oliver Kowalke Sent: Wednesday, August 22, 2012 10:18 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] 1.51 build issue, I think... Am 22.08.2012 17:47, schrieb Lemay.Steve: do you use the bjam version provided by boost-1.51? Yes, bjam is created on the first build. I'm using QNX SDK 6.5 SP1 on a Windows hosted development environment. VS2012 also installed. Contents of batch file provide below. (gcc 4.4.2 support, and gcc 4.7.1 prototype) on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and which ABI is used? Although the SDK support several target processors, this builds target for x86 (AMD K8 architecture - 32-bit addressing). I believe ELF and SYSV (still need to verify) and the boost toolset configuration is set to qcc (not gcc). Is there a good/simple way to verify the ABI? As I am not very familiar with bjam syntax - could the boost_1_51_0\libs\context\build\jamfile.v2 just be confused because of the toolset definition? Considering qcc wraps gcc...? I'm looking specifically at: rule configure ( properties * ) { local result ; if ( ! ( <toolset>gcc in $(properties) || <toolset>intel in $(properties) || <toolset>msvc in $(properties) ) ) { result = <build>no ; ECHO "toolset not supported" ; } return $(result) ; } I don't know qcc, but if I look inside tools/build/v2/tools/qcc.jam it is derived from gcc. The question is if you could use gcc as toolset value on QNX too (bjam toolset=gcc)? Is GNU as available and installed on QNX (required to compile the assembler)? Maybe you could try to add <toolset>qcc in $(properties) in rule configure. Is a free version of QNX available? AFAIK some years ago it was but the new owner of QNX has revoked the free license. Oliver
Am 22.08.2012 19:43, schrieb Lemay.Steve:
The qcc toolset basically "wraps" the gcc environment. The current supported compiler is gcc 4.4.2. I believe QNX provides free downloads of the development environment, as well as a pre-made QNX hosted VM. The 30 day trial license can be found here: http://www.qnx.com/products/evaluation/ I get the same issue with qcc 4.7.1 (which is currently considered prototype).
I seemed to get the same result with this change. (but, I don't really know specifically what I'm doing in bjam files)
if ( ! ( <toolset>gcc in $(properties)
|| <toolset>qcc in $(properties)
|| <toolset>intel in $(properties)
|| <toolset>msvc in $(properties) ) )
**
*SGL*
steven.lemay@igt.com <mailto:steven.lemay@igt.com>
you don't see stuff like Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes ...patience... ...found 1002 targets... ...updating 20 targets... gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.6/debug/link-static/unit_test_main.o ... ? Oliver
*From:*boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] *On Behalf Of *Oliver Kowalke *Sent:* Wednesday, August 22, 2012 10:18 AM *To:* boost-users@lists.boost.org *Subject:* Re: [Boost-users] 1.51 build issue, I think...
Am 22.08.2012 17:47, schrieb Lemay.Steve:
/do you use the bjam version provided by boost-1.51?/
Yes, bjam is created on the first build. I'm using QNX SDK 6.5 SP1 on a Windows hosted development environment. VS2012 also installed. Contents of batch file provide below. (gcc 4.4.2 support, and gcc 4.7.1 prototype)
/on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and which ABI is used?/
Although the SDK support several target processors, this builds target for x86 (AMD K8 architecture -- 32-bit addressing). I believe ELF and SYSV (still need to verify) and the boost toolset configuration is set to qcc (not gcc). Is there a good/simple way to verify the ABI?
As I am not very familiar with bjam syntax - could the boost_1_51_0\libs\context\build\jamfile.v2 just be confused because of the toolset definition? Considering qcc wraps gcc...? I'm looking specifically at:
rule configure ( properties * )
{
local result ;
if ( ! ( <toolset>gcc in $(properties)
|| <toolset>intel in $(properties)
|| <toolset>msvc in $(properties) ) )
{
result = <build>no ;
ECHO "toolset not supported" ;
}
return $(result) ;
}
I don't know qcc, but if I look inside tools/build/v2/tools/qcc.jam it is derived from gcc. The question is if you could use gcc as toolset value on QNX too (bjam toolset=gcc)? Is GNU as available and installed on QNX (required to compile the assembler)?
Maybe you could try to add <toolset>qcc in $(properties) in rule configure.
Is a free version of QNX available? AFAIK some years ago it was but the new owner of QNX has revoked the free license.
Oliver
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Excerpts from the build log below, and build.log file attached. Feel free to e-mail me directly so I don't keep spam'ing everyone. I'd be glad try any build modification for you. ...found 13 targets... ...updating 10 targets... common.mkdir D:\boostBuild_QCC_1_51_0 common.mkdir D:\boostBuild_QCC_1_51_0\boost common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2 common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config\qcc common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config\qcc\debug common.mkdir D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config\qcc\debug\target-os-qnxnto qcc.compile.c++ D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config\qcc\debug\target-os-qnxnto\32.o ...updated 10 targets... Performing configuration checks - 32-bit : yes ...found 3 targets... ...updating 1 target... qcc.compile.c++ D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\context\config\qcc\debug\target-os-qnxnto\x86.o ...updated 1 target... - x86 : yes error: No best alternative for libs/context/build/asm_context_sources [trying next alternatives removed] error: No best alternative for libs/context/build/asm_context_sources [more - trying next alternatives removed] next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <target-os>windows <toolset>gcc not matched ...found 13 targets... ...updating 7 targets... [lots of noise about icu related to boost::locale] ...updated 6 targets... - gcc visibility : yes ...found 47 targets... ...updating 1 target... qcc.compile.c++ D:\boostBuild_QCC_1_51_0\boost\bin.v2\libs\math\config\qcc\debug\target-os-qnxnto\has_long_double_support.o ...updated 1 target... - long double support : yes error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf <toolset>gcc [ more alternative trying ] not matched error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties: <abi>aapcs <architecture>arm <binary-format>elf <toolset>gcc not matched Component configuration: - chrono : building - context : building - date_time : building - exception : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - math : building - mpi : not building - program_options : building - python : not building - random : building - regex : building - serialization : building - signals : building - system : building - test : building - thread : building - timer : building - wave : building SGL steven.lemay@igt.com<mailto:steven.lemay@igt.com> From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oliver Kowalke Sent: Wednesday, August 22, 2012 10:51 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] 1.51 build issue, I think... Am 22.08.2012 19:43, schrieb Lemay.Steve: The qcc toolset basically "wraps" the gcc environment. The current supported compiler is gcc 4.4.2. I believe QNX provides free downloads of the development environment, as well as a pre-made QNX hosted VM. The 30 day trial license can be found here: http://www.qnx.com/products/evaluation/ I get the same issue with qcc 4.7.1 (which is currently considered prototype). I seemed to get the same result with this change. (but, I don't really know specifically what I'm doing in bjam files) if ( ! ( <toolset>gcc in $(properties) || <toolset>qcc in $(properties) || <toolset>intel in $(properties) || <toolset>msvc in $(properties) ) ) SGL steven.lemay@igt.com<mailto:steven.lemay@igt.com> you don't see stuff like Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes ...patience... ...found 1002 targets... ...updating 20 targets... gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.6/debug/link-static/unit_test_main.o ... ? Oliver From: boost-users-bounces@lists.boost.org<mailto:boost-users-bounces@lists.boost.org> [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Oliver Kowalke Sent: Wednesday, August 22, 2012 10:18 AM To: boost-users@lists.boost.org<mailto:boost-users@lists.boost.org> Subject: Re: [Boost-users] 1.51 build issue, I think... Am 22.08.2012 17:47, schrieb Lemay.Steve: do you use the bjam version provided by boost-1.51? Yes, bjam is created on the first build. I'm using QNX SDK 6.5 SP1 on a Windows hosted development environment. VS2012 also installed. Contents of batch file provide below. (gcc 4.4.2 support, and gcc 4.7.1 prototype) on which architecture you have QNX running (i386/x8664,arm, mips, ...), which binary format and which ABI is used? Although the SDK support several target processors, this builds target for x86 (AMD K8 architecture - 32-bit addressing). I believe ELF and SYSV (still need to verify) and the boost toolset configuration is set to qcc (not gcc). Is there a good/simple way to verify the ABI? As I am not very familiar with bjam syntax - could the boost_1_51_0\libs\context\build\jamfile.v2 just be confused because of the toolset definition? Considering qcc wraps gcc...? I'm looking specifically at: rule configure ( properties * ) { local result ; if ( ! ( <toolset>gcc in $(properties) || <toolset>intel in $(properties) || <toolset>msvc in $(properties) ) ) { result = <build>no ; ECHO "toolset not supported" ; } return $(result) ; } I don't know qcc, but if I look inside tools/build/v2/tools/qcc.jam it is derived from gcc. The question is if you could use gcc as toolset value on QNX too (bjam toolset=gcc)? Is GNU as available and installed on QNX (required to compile the assembler)? Maybe you could try to add <toolset>qcc in $(properties) in rule configure. Is a free version of QNX available? AFAIK some years ago it was but the new owner of QNX has revoked the free license. Oliver _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (4)
-
Daniel James -
Lemay.Steve -
Marshall Clow -
Oliver Kowalke