In Boost Build 1.59 (and the current module boost trunk) the "unit-test" rule will break the entire build, showing a stack trace with a bunch of internal Boost Build jam files, if the "using boost" line of the site-config.jam file is missing or incorrectly specified. I've reproduced this on two Windows 10 machines using msvc 12 and 14.

To get more specific, the following Boost Build example works just fine in previous versions of Boost Build: https://github.com/TimSimpson/BoostBuildExamples/blob/master/boost-test/Jamroot.jam

All this time my site-config.jam files looked like this:

using boost
    : 1.59 
    ;

(of course previously they were 1.58, 1.57, etc etc).

When I build the boost-test example linked to above I see this:

https://gist.github.com/TimSimpson/027b5c0b1b32793471a1

...
C:/Tools/Local/boost/boost_1_59_0/tools/build/src/tools\builtin.jam:769: in [email protected]
*** argument error
* rule type.is-derived ( type base )
* called with: ( SHARED_LIB )
* missing argument base
C:/Tools/Local/boost/boost_1_59_0/tools/build/src/build\type.jam:219:see definition of rule 'type.is-derived' being c
alled
C:/Tools/Local/boost/boost_1_59_0/tools/build/src/build\generators.jam:994: in try-one-generator-really
...etc etc...

I tried debugging it by putting echo statements all over the source, and while I am not a Jam expert it seems like the unit-test rule has its sources expanded to include all of the Boost modules, and at some point boost accumulators is pulled in which has no concrete type and things blow up.

Now if I change the site-config.jam to look like this:

using boost
  : 1.59
  : <include>C:/Tools/Local/boost/boost_1_59_0
    <library>C:/Tools/Local/boost/boost_1_59_0/stage/lib
  ;

It works- in that instead I get a linker error: "LINK : fatal error LNK1181: cannot open input file 'boost_test_exec_monitor-vc120-mt-gd-1_59.lib'" (though never have I been so overjoyed to see a linker error).

Now here's the funny thing: as part of trouble shooting I set up Boost 1.58 from scratch, using a clean command prompt. It all worked, but only using the old site-config.jam (the one that didn't specify the include or library arguments) with 1.59 changed to 1.58. When I changed the site-config.jam to specify the include and library arguments, I now get linker errors, for the similar file "boost_test_exec_monitor-vc120-mt-gd-1_58.lib".

It seems like in the past the include and library arguments did not need to be specified but now they do. That isn't a huge deal, but I'd be embarrassed to admit how long it took me to figure out what needed to change. It seems like Boost Build should be validating the "using boost" statement and giving a nice, solid error message when users aren't specifying everything.

Additionally, if I completely omit the "using boost" I get another stack trace / non-error message situation:

https://gist.github.com/TimSimpson/e0d168f02bee2ea2c065

...
C:/Tools/Local/boost/boost_1_59_0/tools/build/src/build\generators.jam:1102: in ensure-type from module generators
error: target { link%link.do-link-recursively-chrono/stopwatches-headers. { libs/chrono/stopwatches/include/boost. }
} has no type
C:/Tools/Local/boost/boost_1_59_0/tools/build/src/build\generators.jam:1359: in generators.construct from module gene
rators
...etc etc

In Boost Build 1.58 the boost-test example builds perfectly, running the tests along the way.

So again- it looks like the unit-test rule isn't validating this at all, but I also wonder why it suddenly needs "using boost" to be there in the first place.

Finally, about the file "boost_test_exec_monitor-vc120-mt-gd-1_58.lib" / "boost_test_exec_monitor-vc120-mt-gd-1_59.lib"- I've been using Boost Build for years now so I had my old 1.56 directory sitting around. I do not see any files named "boost_test_exec_monitor-etc" but I do see "boost_prg_exec_monitor-etc". I'm guessing the test monitor is static only which is why that file doesn't exist, and Boost Build normally just figures this out and uses the correct thing. However what's troubling me now is I still am left with a non-working Boost Build 1.59 that won't run my tests.

It seems that at link stage the linker arguments are not correct, please see this issue:

http://stackoverflow.com/questions/29450634/compile-boost-python-tutorial-with-vs-2015-ctp-5-and-python-3-5a-on-windows-10-t

Link command line:
link /NOLOGO /INCREMENTAL:NO /DLL /NOENTRY /DEBUG /MACHINE:X86 /MANIFEST /subsystem:console /out:"bin\msvc-14.0\debug\threading-multi\hello_ext.dll" /IMPLIB:"bin\msvc-14.0\debug\threading-multi\hello_ext.pdb" /LIBPATH:"C:\python35a3\libs" @"bin\msvc-14.0\debug\threading-multi\hello_ext.dll.rsp"

Note: /IMPLIB points incorrectly to pdb file (program database = debug symbols)

Suggested solution fix the build problem, but is it ok?

[15:27:09.68] D:\code\3party\build>src\engine\bin.ntx86\bjam -d3 -sBOOST_BUILD_PATH="test/.." -d0 --quiet dir1-link dir2-link toolset=msvc --test-config="test\test-config.jam" --ignore-toolset-requirements
notice: could not find main target dir1-link
notice: assuming it is a name of file to create.
notice: could not find main target dir2-link
notice: assuming it is a name of file to create.
make    --      <e>dir1-link
make    --      <e>dir1-link
bind    --      <e>dir1-link: dir1-link
time    --      <e>dir1-link: missing
don't know how to make <e>dir1-link
made+   nofind  <e>dir1-link
make    --      <e>dir2-link
make    --      <e>dir2-link
bind    --      <e>dir2-link: dir2-link
time    --      <e>dir2-link: missing
don't know how to make <e>dir2-link
made+   nofind  <e>dir2-link
...found 2 targets...
...can't find 2 targets...

output of run -d9:
fail9.txt

I'm continuously working on and using the Python port and I've been bitten by a similar bug several times: I pass in a string when the function is expecting a list. The function will usually continue on as normal and later on show some cryptic error message about how it can't find some target named '_', 'L', or any other various first letters of one of my targets.

Some of the core boost-build functions and methods already contain asserts for type checking, but there are a lot that don't. I've developed somewhat of a solution that utilizes bjam_signature. It uses the signature passed in to determine the appropriate type of a parameter and raises a TypeError if, say, a string is passed in where a list was expected.

I've already tried implementing this solution and it works. However, there are some functions that require a list as a parameter and account for parameters that might be passed a string. For example, feature.compose:

# feature.py
@bjam_signature((["composite_property_s"], ["component_properties_s", "*"]))
def compose (composite_property_s, component_properties_s):
    # ...
    component_properties_s = to_seq (component_properties_s)

And in type.register, feature.compose is called with a string instead of a list:

if base_type:
        feature.compose ('<target-type>' + type, replace_grist (base_type, '<base-target-type>'))
        feature.compose ('<base-target-type>' + type, '<base-target-type>' + base_type)

My solution doesn't work when variables are allowed to be either a list or a string even though the bjam signature says it should be a list. My question: would it be permissible to enforce this strict(er) typing by implementing the bjam_signature type check and removing all type coercions in the core? Or should I try the next idea:

Instead of or along with utilizing the bjam_signature type check, it would be nice to place type checking asserts for each function/method that cannot support a bjam_signature.

Both solutions would require a small change to the engine code to enable the the PYTHONOPTMIZE flag by default (so all asserts and if __debug__ blocks are removed) and allow the optimization flag to be disabled by another flag for development/debugging purposes.

In darwin.jam, it looks like gcc.jam is inherited instead of clang.jam. I'm not sure why this is the case since Apple basically replaces gcc with clang on Mac OS X. This means that build flags are not inherited like I would expect.

Could the variant with static release runtime be build by default?

It's a frequently used option to allow xcopy deployments.

Jamroot:
exe main : main.asm ;

main.asm:
empty

command line:
b2.exe toolset=clang-win -sBOOST_ROOT=C:\path\to\boost

error:
clang-win.compile.asm bin\clang-vc14-win\debug\main.obj
'-c' is not recognized as an internal or external command,
operable program or batch file.
-c -Zp4 -Cp -Cx /Zi /Zd /W3 -Fo "bin\clang-vc14-win\debug\main.obj" "main.asm"
...failed clang-win.compile.asm bin\clang-vc14-win\debug\main.obj...

As you can see, ml.exe (or ml64.exe for address-model=64) is missing in command line.

I am trying to build and install latest master branch of Boost by running the following commands:

bootstrap
b2 --build-type=complete address-model=64 toolset=msvc runtime-link=shared stage
b2 --build-type=complete address-model=64 toolset=msvc runtime-link=shared install

I am using Visual Studio 2017 (x64) on Windows 10.

No errors are encountered during the build. However, there are a number of missing files and folders in the C:\Boost\include\boost-1_65 after running the install step. (The symlinks/junctions for these files are also missing in the boost subdirectory that I have cloned from GIT)

Below I show the additional files that get installed when I build and install Boost 1.64. These files and folders do not appear when building and installing the master branch.

• Missing directories (top-level)
  accumulators
  assign
  bimap
  circular_buffer
  compatibility
  compute
  concept_check
  convert
  coroutine2
  dll
  endian
  flyweight
  format
  geometry
  gil
  hana
  heap
  icl
  lambda
  local_function
  lockfree
  logic
  metaparse
  msm
  multiprecision
  multi_array
  polygon
  process
  ptr_container
  qvm
  signals2
  sort
  statechart
  tr1
  tti
  units
  uuid
  vmd

• Missing files (top-level)
  align.hpp
  asio.hpp
  assign.hpp
  bimap.hpp
  circular_buffer.hpp
  circular_buffer_fwd.hpp
  compute.hpp
  convert.hpp
  crc.hpp
  cstdfloat.hpp
  cxx11_char_types.hpp
  date_time.hpp
  dll.hpp
  filesystem.hpp
  flyweight.hpp
  format.hpp
  functional.hpp
  function_output_iterator.hpp
  generator_iterator.hpp
  geometry.hpp
  hana.hpp
  last_value.hpp
  locale.hpp
  local_function.hpp
  make_default.hpp
  make_unique.hpp
  metaparse.hpp
  mpi.hpp
  multi_array.hpp
  nondet_random.hpp
  parameter.hpp
  phoenix.hpp
  pointer_cast.hpp
  polymorphic_pointer_cast.hpp
  process.hpp
  program_options.hpp
  progress.hpp
  random.hpp
  ratio.hpp
  regex.h
  scope_exit.hpp
  shared_container_iterator.hpp
  signal.hpp
  signals.hpp
  signals2.hpp
  spirit.hpp
  wave.hpp

For this cmd :
X:BLABLA1\boost-build\build\b2.exe toolset=msvc-14.0 variant=release threading=multi link=shared address-model=64 warnings=on target-os=windows -d1 > X:BLABLA2\test\test_boost-build\test_helloworld\bin\msvc-14.0-64-release-64-multi.log

it doesn't works :
failed compile-c-c++ bin\msvc-14.0\release\address-model-64\threading-multi\hello.obj...

Because of b2 call that :
'"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64' >nul

And it doesn't work if i try my self to see the output of this cmd:
«The specified configuration type is missing. The tools for the
configuration might not be installed.»

I use visual 2015 express and the right command is :
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"

which toolset used, when building b2 use TDM-GCC 64bit?
gcc, gcc-nocygwin or mingw?

thank you.

When using an externally installed GCC version (e.g. from homebrew) linking fails due to unknown linker options.

gcc.link.dll bin.v2/libs/iostreams/build/gcc-5/release/threading-multi/libboost_iostreams.dylib
ld: unknown option: -h
collect2: error: ld returned 1 exit status

    "g++-5"    -o "bin.v2/libs/iostreams/build/gcc-5/release/threading-multi/libboost_iostreams.dylib" -Wl,-h -Wl,libboost_iostreams.dylib -shared -Wl,--start-group "bin.v2/libs/iostreams/build/gcc-5/release/threading-multi/file_descriptor.o" "bin.v2/libs/iostreams/build/gcc-5/release/threading-multi/mapped_file.o" "bin.v2/libs/iostreams/build/gcc-5/release/threading-multi/bzip2.o"  -Wl,-Bstatic  -Wl,-Bdynamic -lbz2 -Wl,--end-group -m64 

This is due to the build system expecting the GNU linker however on OS X the default Apple linker is being used (which is correct, though, it doesn't understand the newer flags).

Hi,

I would like to use boost.build for some embedded systems but I need a few more tools to do so. Now the question is if I should try to get it into boost build or just keep it as my own extension.

There are a few things, several compilers would support, like the following:

• Disassembly
• Symbol table
• Map files

Additionally I would like to add those things.

• HexFiles (i.e. objcopy)
• Linker Scripts (as arguments when linking, not as target)
• GCov support (i.e. registering the files as targets when using the coverage flag).

Would that fit into boost/build or should I keep it in my own extension? There is a partial implementation here.

grok-machine:boost dendisuhubdy$ ./bootstrap.sh
./bootstrap.sh: line 196: ./tools/build/src/engine/build.sh: No such file or directory
Building Boost.Build engine with toolset ...
Failed to build Boost.Build build engine
Consult 'bootstrap.log' for more details

When building 1.64 beta 2 on VC2017 / W7, this is logged over and over but the build still seems to finish OK.

When I try to build boost with toolset=msvc-12.0_xp I get the error:

D:/boost/src/tools/build/src/tools\msvc.jam:288: in configure-version-specific
*** argument error
* rule path.make ( native )
* called with: (  )
* missing argument native
D:/boost/src/tools/build/src/util\path.jam:479:see definition of rule 'path.make' being called
D:/boost/src/tools/build/src/tools\msvc.jam:1141: in configure-really
D:/boost/src/tools/build/src/tools\msvc.jam:200: in configure
D:/boost/src/tools/build/src/tools\msvc.jam:152: in msvc.init
D:/boost/src/tools/build/src/build\toolset.jam:43: in toolset.using
D:/boost/src/tools/build/src\build-system.jam:461: in process-explicit-toolset-requests
D:/boost/src/tools/build/src\build-system.jam:527: in load
D:\boost\src\tools\build\src/kernel\modules.jam:289: in import
D:\boost\src\tools\build\src/kernel/bootstrap.jam:139: in boost-build
D:\boost\src\boost-build.jam:17: in module scope`

And everything is fine if I build boost-1.56 in the same environment. Also replacing msvc.jam helps.

build/src/tools/python.jam says:

Unlike most *nix systems, Mac OS X's linker does not permit undefined

# symbols when linking a shared library. So, we still need to link against
# the Python framework, even when building extensions.

Passing -undefined dynamic_lookup to the linker (instead of -lpython or -framework Python) permits undefined symbols and achieves the desired behavior. This has existed since OS X 10.1 so there should be no compatibility concerns.

Linking a module against one Python framework and importing it from another (ABI-compatible) interpreter causes the interpreter to segfault, so the current behavior is a pain point for e.g. Homebrew.

... but -mcpu=c3 is for VIA C3 X86 CPUs. That is broken. The default for SPARC should probably be -mcpu=v7.

Hi,
I just wanted to build Boost with

bootstrap
.\b2

But when I tried to run b2, Kaspersky interrupts and deletes the file. The same happens, if I try to install Boost.Build.

Is there any way to make this file non-infected?

When using BB standalone and following the default install procedures one gets errors because the default install location for BB isn't searched for the build system files. For example:

git clone https://github.com/boostorg/build.git
cd build
bootstrap.bat
b2.exe install
cd /my-project/test
b2.exe

Results in:

Unable to load Boost.Build: could not find "boost-build.jam"
---------------------------------------------------------------
BOOST_ROOT must be set, either in the environment, or 
on the command-line with -sBOOST_ROOT=..., to the root
of the boost installation.

Attempted search from C:\projects\predef\test up to the root
at C:/boost-build-engine/share/boost-build

Please consult the documentation at 'http://www.boost.org'.

As compared to the equivalent steps on Unix that work without the error.

Installation directories are now:
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\VS15 Preview 5\Common7\IDE\VisualCpp
VS150COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio\VS15 Preview 5\Common7\Tools\

VCVARSALL.BAT is now located at:
C:\Program Files (x86)\Microsoft Visual Studio\VS15 Preview 5\Common7\IDE\VisualCpp\Auxiliary\Build\

./b2 -j268 does not work:

Invalid value for the '-j' option, valid values are 1 through 256.

I have more than 256 cores, I'd like to use them :)

Since GCC has switched its version scheme (starting with GCC 5), building the Boost libraries (with b2) with parameters --layout=versioned and toolset=gcc-5 (or newer GCC) does no longer create library-names containing the compiler's version number. At least, this is the case on Linux.

For example, building Boost.Program_Options with --layout=versioned results in:

• GCC 4.8: libboost_program_options-gcc48-mt-1_63_0.so
• GCC 4.9: libboost_program_options-gcc49-mt-1_63_0.so
• GCC 5: libboost_program_options-gcc-mt-1_63_0.so
• GCC 6: libboost_program_options-gcc-mt-1_63_0.so

It would be great if this could be fixed so that the Boost-libraries build with GCC 5 and 6 could be installed side-by-side into the same directory.

build/src/tools/clang-darwin.jam does

actions piecemeal archive
{
    "$(.AR)" $(AROPTIONS) rc "$(<)" "$(>)"
    "ranlib" -cs "$(<)"
}

which ignores <archiver> and <ranlib> from any .bjam config.

This is bad when trying to set up an Android cross compile using clang (and it's very disturbing when everything "just worked" for Android g++/NDK....)

Everything installs nicely, but with a minor warning

warning: ranlib: warning for library: /tmp/build/armeabi/boost/boost/bin.v2/libs/system/build/clang-darwin-android/release/link-static/target-os-android/threading-multi/libboost_system.a the table of contents is empty (no object file members in the library define global symbols)

and when you try to use the library with CMake/NDK it fails with

libboost_program_options.a: no archive symbol table (run ranlib)

It seems odd that the Android NDK bundles up everything as the same version (takes the same flags, makes the same output) across Windows/OSX/linux but the boost configuration options shard the handling across the host type.

Hi
I use booost_1_58_0 with gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2, I used the easy way to install it

./bootstrap.sh 
./b2
sudo ./b2 install

Shared libraries are in /usr/lib//usr/lib/x86_64-linux-gnu/, and header are in /usr/include/boost/ ,
the example from http://www.boost.org/doc/libs/1_58_0/more/getting_started/unix-variants.html#link-your-program-to-a-boost-library work well with

c++  example.cpp -o example  -lboost_regex

Now, my objective is to use python. so I tried with libs/python/example/tutorial and it worked after adding boost-build.jam
the problems start with quickstart, when I compiled I got http://paste.debian.net/171254/ , you'll find 2 errors messages :

*** Error in `bin/gcc-4.8/debug/embedding': double free or corruption (!prev): 0x000000000149f560 ***
testing.capture-output bin/test_embed.test/gcc-4.8/debug/test_embed.run

...failed testing.capture-output bin/test_embed.test/gcc-4.8/debug/test_embed.run...
...failed updating 1 target...
...skipped 1 target...
...updated 15 targets..

I seems that tests was passed successfully, but when I used python test_extending.py
http://paste.debian.net/171251/
Second question : am I obliged to keep boost_1_58_0 directory in on my file system ?
I found /usr/local/share/boost-build/ and /usr/share/boost-build/ but I don't know if it can replace boost_1_58_0

The following scenario occurred (simplified for brevity):

# in a jamfile
alias MY_ALIAS ;
lib LIB : MY_ALIAS ;

Then, trying to build the LIB target:

*** argument error
* rule [email protected] ( project name ? : property-set : sources + )
* called with: ( object(project-target)@3272 LIB : object(property-set)@7510 :  )
* missing argument sources

The source for the LIB target ends up producing an empty source list (user error). I can clearly tell that has happened from the error message, but I can't tell where it occurred.

Note: we use the convention of specifying a single LIB target per library and in a project that uses multiple libraries, there are multiple LIB targets which is why it's not entirely clear which LIB target the error message is referring to.

I have a couple of ideas that could be used to help the end user solve this problem.

1. For the base generator class, the run signature could be updated to use * instead of + and then check to see if sources is empty and print a better error message (target name, location, etc).
2. The Jam interpreter and the class implementations could be modified to support a "to string" or "repr" method and those would be called in the above error message. This would also be a benefit in several other places like --debug-building and --debug-generators.

The problem with the second idea is that it doesn't help the Python port.

Thoughts?

I have run into an error when using a custom toolset under Windows. I have developed and been using a toolset for the TI Code Generation Tools (cross-compiler for TI DSP) under Linux, OS X, and Cygwin. I have been developing a toolset tester to ensure that everything for these toolsets work. Incidentally, is there a better way to test a toolset within the Boost.Build project?

I am now trying to use it under Windows and running in the error below. I've worked around the issue by changing property.jam (see the last commit of https://github.com/tee3/build/commits/devel-workaround-for-possible-windows-bug), but I'm looking for a real fix wherever it needs to be.

I'm hoping that someone sees the description and can check this without needing to run this toolset. If not, and you feel like spending a lot of time on this problem, I've included instructions for reproducing the problem using a free TI compiler.

b2 --test-config=user-config.jam link=static -a
building for the following toolsets:
   * tms320c6000-8.0.4
C:/Users/xxx/Development/boost-build/src/build\property.jam:743: in [email protected] from module object(property-map)@26
error: Ambiguous key 
C:/Users/xxx/Development/boost-build/src/build\type.jam:333: in generated-target-ps from module type
C:/Users/xxx/Development/boost-build/src/build\type.jam:270: in type.generated-target-suffix from module type
C:/Users/xxx/Development/boost-build/src/build\virtual-target.jam:509: in virtual-target.add-prefix-and-suffix from module virtual-target
C:/Users/xxx/Development/boost-build/src/build\virtual-target.jam:468: in _adjust-name from module object(file-target)@215
C:/Users/xxx/Development/boost-build/src/build\virtual-target.jam:253: in abstract-file-target.__init__ from module object(file-target)@215
C:/Users/xxx/Development/boost-build/src/build\virtual-target.jam:561: in class@file-target.__init__ from module object(file-target)@215
C:/Users/xxx/Development/boost-build/src/kernel\class.jam:90: in class.new from module class
C:/Users/xxx/Development/boost-build/src/build\generators.jam:558: in generated-targets from module object(C-compiling-generator)@115
C:/Users/xxx/Development/boost-build/src/build\generators.jam:453: in construct-result from module object(C-compiling-generator)@115
C:/Users/xxx/Development/boost-build/src/build\generators.jam:412: in run-really from module object(C-compiling-generator)@115
C:/Users/xxx/Development/boost-build/src/build\generators.jam:386: in [email protected] from module object(C-compiling-generator)@115
C:/Users/xxx/Development/boost-build/src/build\generators.jam:994: in try-one-generator-really from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1056: in try-one-generator from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1294: in construct-really from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1378: in construct from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1069: in generators.construct-types from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:609: in convert-to-consumable-types from module object(generator)@138
C:/Users/xxx/Development/boost-build/src/build\generators.jam:405: in run-really from module object(generator)@138
C:/Users/xxx/Development/boost-build/src/build\generators.jam:386: in [email protected] from module object(generator)@138
C:/Users/xxx/Development/boost-build/src/build\generators.jam:994: in try-one-generator-really from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1056: in try-one-generator from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1294: in construct-really from module generators
C:/Users/xxx/Development/boost-build/src/build\generators.jam:1378: in generators.construct from module generators
C:/Users/xxx/Development/boost-build/src/build\targets.jam:1553: in construct from module object(typed-target)@152
C:/Users/xxx/Development/boost-build/src/build\targets.jam:1353: in [email protected] from module object(typed-target)@152
C:/Users/xxx/Development/boost-build/src/build\targets.jam:774: in generate-really from module object(main-target)@192
C:/Users/xxx/Development/boost-build/src/build\targets.jam:746: in [email protected] from module object(main-target)@192
C:/Users/xxx/Development/boost-build/src/build\targets.jam:272: in [email protected] from module object(project-target)@119
C:/Users/xxx/Development/boost-build/src\build-system.jam:710: in load from module build-system
C:\Users\xxx\Development\boost-build\src\kernel\modules.jam:295: in import from module modules
C:\Users\xxx\Development\boost-build\src\kernel\bootstrap.jam:139: in boost-build from module
C:\Users\xxx\Development\boost-build\boost-build.jam:8: in module scope from module

Follow the very long list of steps below to reproduce the problem.

1. Install at least one of the compilers and disabled the rest of the compilers in project-config.jam are commented out. I would recommend installing TI CGT TMS320C6000 8.0.4 for WIndows as it does not have export restrictions as the other versions do. The compilers are available for Linux as OS X as well, see here. Downloading the compilers requires registering for a free TI login account, so I understand if no one wants to investigate this.

I recommend installing to %HOME%\opt\ti\ti-cgt-c6000-8.0.4, but anywhere you have access will do and can be set up in project-config.jam as described below.
2. Run the following commands to see the failure. At the point where the error occurs in property.jam, $(best) is obj obj instead of just obj, resulting in an ambiguous key.

C:\> mkdir C:\TEMP
C:\> cd C:\TEMP
C:\TEMP\> git clone https://github.com/tee3/build build
C:\TEMP\> cd build
C:\TEMP\> git checkout develop
C:\TEMP\boost-build\> bootstrap.bat
C:\TEMP\boost-build\> cd ..
C:\TEMP\> git clone https://github.com/tee3/boost-build-ti
C:\TEMP\> git clone https://github.com/tee3/boost-build-toolset-tester
C:\TEMP\> cd boost-build-toolset-tester
C:\TEMP\> rem modify project-config.jam to reflect your configuration
C:\TEMP\> b2 --test-config=user-config.jam link=static -a

3. The last commit on https://github.com/tee3/build/commits/devel-workaround-for-possible-windows-bug works around the issue. This does not address the logic, but just works around the immediate problem.

   After this, the build then runs. It fails for other reasons (I'm still working out getting the tools to work properly as they make a lot of assumptions, like the assumption that the current user has exclusive access to the tools when it builds the standard library on demand). I believe the rest of the issues are surmountable within the toolset definition and the user's environment, but the issue above is not.

I'm trying to build attached example using BB from 1.63.

It builds just fine if toolset=msvc-14.0, but with toolset=clang-win I'm getting LNK1120: unresolved external. -d+2 shows that user32.lib is missing in linker rsp file.

Building with address-model=32 gives another linker error.

clang-min.zip

Thanks.

On one of our larger projects, building the entire project all at once can produce a segmentation fault. To try and pinpoint the problem I broke out Dr. Memory.

There were several uninitialized read errors for the builtin_calc rule due to using the sign variable without it being initialized. Changing the declaration for sign to

char const * sign = "";

removed all of the uninitialized read errors.

There are many LEAK errors and I believe these to be the cause of the seg fault. The majority of the errors are LEAK 0 direct bytes which a few LEAK 8 direct bytes.

The Dr. Memory output file can be found here.

This patch ae5e63a doesn't work with VS2017RC1

See also Finding the location of a VC++2017 install

BTW toolset should be vc141 for VS2017 and %VSxxxCOMNTOOLS% environment variable doesn't exist

Overview

I spent a little time trying to implement a language standard feature and I was hoping someone might find some time to review the overall approach. If it is a viable approach, there would be a bit more work to complete it. It is current working for the gcc toolset as a proof of concept. I think it looks like a reasonable approach.

See https://github.com/tee3/build/tree/develop-language-standard,

Currently, only C, C++, Objective-C, and Objective-C++ are supported. Other languages could be implemented in a similar way.

The language standard features are named as follows:

• <cstd> - c89, c90, gnu89, msvc89, etc.
• <ccxxstd> - c++98, c++03, gnu++98, msvc++98, etc.
• <objcstd> - objc1, objc2
  • the C language standards also apply
    • combinations of C standard and Objective-C standards is not tested yet
• <objcxxstd> - objc1, objc2
  • the C++ language standards also apply
    • combinations of C++ standard and Objective-C++ standards is not tested yet

Status:

• only gcc is implemented
  • darwin, clang-linux, clang-darwin, intel-linux, intel-darwin all inherit flags, so these work too
  • does not yet use the compiler version to further restrict supported versions
• only clang and darwin on OS X are tested so far
• failures result in a compiler failure that hopefully is readable

I created a test harness for this change externally and a Travis CI build.

• https://github.com/tee3/boost-build-toolset-tester-std
  • this generates files and compiles them to verify that the right version was selected
    • more work has to be done here to ensure that extensions are not enabled when not requested
• https://travis-ci.org/tee3/boost-build-toolset-tester-std/jobs/100043766
  • the failing tests are expected in most cases (eg, gcc doesn't support msvc dialects)
    • would be nice to fail expectedly on unsupported language standards

To Do

• review and refine the language standard names for each lanuage
• implement version-based refinement of language standards in gcc
• implement version-based refinement of language standards in msvc
• implement prototypes of all other toolsets for public compilers
• refine approach to unsupported language standard requests?
• integrate test with Boost.Build test harness
• add builtin.jam support for other languages (fortran, others?)
• implement in Python as well
• documentation

VS2015 / W10:

PS C:\vc\boost_1_64_0> .\bootstrap.bat

Building Boost.Build engine
HRESULT was unexpected at this time.

PS C:\vc\boost_1_64_0>

It seems to be this bit of code that causes the error but I have no clue why.

if "_%BOOST_JAM_TOOLSET_ROOT%_" == "__" (
    if NOT "_%VS150COMNTOOLS%_" == "__" (
        set "BOOST_JAM_TOOLSET_ROOT=%VS150COMNTOOLS%..\..\VC\"
    ))

Hmm

echo "%BOOST_JAM_TOOLSET_ROOT%"

"_Exception calling "Query" with "1" argument(s): "Error HRESULT
E_FAIL has been returned from a call to a COM component."\VC\_"

It would be more convenient for users if b2 defaulted to address-model=64 when hosted on a 64 bit machine.

I want to use Boost.Dll under Windows Embbedded Compact 2013, but I've to build the Boost.System for WEC to do so.

boostorg/dll#10
boostorg/winapi#38
https://svn.boost.org/trac/boost/ticket/12853#comment:1

Normally I build static boost with the following commands:

bootstrap.bat
.\b2.exe headers
.\b2.exe variant=release,debug link=static runtime-link=static threading=multi address-model=32 architecture=x86 --toolset=msvc-15.0 --without-python --without-mpi --stagedir=stage stage

The WEC SDK 2013 comes bundled with a Microsoft Toolchain (VS 2012 based) like the Windows 7.1 SDK.
What are correct --toolset= settings for the build?

Hello, everyone,

For bjam using ICC on Windows got error:

bootstrap intel-win32

<snip>

Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

   http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

Full log added in attachment.

The source of error is symbol -. If in files:

<BOOST sources>\tools\build\src\engine\build.bat
<BOOST sources>\tools\build\src\engine\build.jam

remove it from string intel-win32, bjam would be successfully built using command bootstrap intelwin32. The drawback of such solution, that there are other files, which refer intel-win32 key:

<BOOST sources>\boost\config\compiler\intel.hpp
<BOOST sources>\doc\html\jam.html
<BOOST sources>\doc\html\jam\history.html
<BOOST sources>\status\expected_results.xml
<BOOST sources>\status\explicit-failures-markup.xml
<BOOST sources>\tools\build\doc\bjam.qbk
<BOOST sources>\tools\build\doc\history.qbk
<BOOST sources>\tools\build\src\engine\boehm_gc\doc\README.Mac
<BOOST sources>\tools\build\src\tools\intel-win.jam

@eas provided a fix for this issue (see eas/build@fdbef0e), but for some reason it didn't appear in Boost.build master. Thus added an appropriate PR #211.

Environment:

• Windows 10 x64,
• Intel Parallel Studio XE 2017 Update 4,
• Visual Studio 2015 Update 3,
• BOOST-1.64.0.

Alexander

Initially reported at https://svn.boost.org/trac/boost/ticket/12515 and independently rediscovered while packaging Boost for Fedora 26. The Trac ticket says:

In Boost 1.62, specifying "python=3.5" is not working anymore: Always the first python entry in user-config.jam is selected. It seems to be related to a change in tools/build/src/tools/python.jam (line 905 ff), which appeared between 1.61.0 and 1.62.0.

It also means that it makes it impossible (or at least hard for me) to build libboost_python and libboost_python3 at one run. While both files are present, in fact they are both python2 bindings.

The trac ticket says it's caused by 78ffbe0

In the Fedora package we have this in user-config.jam:

using python : 2.7 : /usr/bin/python2 : /usr/include/python2.7 : : : : ;
using python : 3.6 : /usr/bin/python3 : /usr/include/python3.6m : : : : m ;

And then we invoke b2 with python=2.7 in the arguments, with this comment:

# The "python=2.*" bit tells jam that we want to _also_ build 2.*, not
# just 3.*.  When omitted, it just builds for python 3 twice, once
# calling the library libboost_python and once libboost_python3.  I
# assume this is for backward compatibility for apps that are used to
# linking against -lboost_python, for when 2->3 transition is
# eventually done.

In previous versions this would cause libboost_python.so to link to libpython2.7.so and libboost_python3.so to link to libpython3.6m.so but now both libs link to libpython2.7.so

Was this an intended consequence of 78ffbe0 or accidental?

Is there some other way to build against both Python2 and Python3, as linux distro packagers require?

If I try to cross-compile Boost.Fiber for the armv6 architecture, the cxx11_* requirements in the Jamfile.v2 will fail, because the building system will try to execute the binaries on the host.

This should not happen.
The fact that the binaries are compiled should be enough to guarantee the cxx11_* support by the compiler.

os.platform is set in jam.h - unfortunately macro arm is not set on 64bit ARM.
Instead aarch64 as to be evaluated in order to detect Aarch64 architectur.
Pull request ' check aarch64 for ARM #58 ' was created.

This will segfault:

import "class" : new ;
segfault = [ new xx ] ;

I dug through the source of class.new and have reduced the segfault to the following:

local id = foo ;
INSTANCE $(id) : bar ;
$(id).something ;

Original, MUCH longer test case

In bug.jam:

class Bug { }

In Jamroot:

import bug ;
import "class" : new ;

segfault = [ new bug.Bug ] ; # Commenting this line out fixes the segfault.

Tested with both 2014 release and latest Git.

http://www.boost.org/build/doc/html/bbv2/installation.html says:

If you are not using a Boost.Build package, but rather the version bundled with the Boost C++ Libraries, the above commands should be run in the tools/build/v2 directory.

However, my boost_1_59_0/tools/build directory has no v2 subdirectory; however,
it does have the bootstrap.sh file mentioned earlier. I'm guessing that is a typo
and should read:

If you are not using a Boost.Build package, but rather the version bundled with the Boost C++ Libraries, the above commands should be run in the tools/build directory.

When building boost 1.60 with Intel C++ 16.0 compiler for MacOS, users have encountered a 'failed Jamfile' issue which is due to incorrect arguments passed to assembler. This problem can be corrected by patching libs/context/build/Jamfile.v2 to add a rule for the Intel toolset (I work for Intel on the Intel C++ compiler). Thanks and best regards, Melanie Blower

Here's the symptom:
Jamfile</Users/xx/software/boost_1_60_0/libs/context/build>.gas64 ../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/make_x86_64_sysv_macho_gas.o
clang: error: unsupported option '--64'
clang: error: no input files

cpp -x assembler-with-cpp "libs/context/src/asm/make_x86_64_sysv_macho_gas.S" | as --64 -o "../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/make_x86_64_sysv_macho_gas.o"

...failed Jamfile</Users/xx/software/boost_1_60_0/libs/context/build>.gas64 ../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/make_x86_64_sysv_macho_gas.o...
Jamfile</Users/xx/software/boost_1_60_0/libs/context/build>.gas64 ../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/jump_x86_64_sysv_macho_gas.o
clang: error: unsupported option '--64'
clang: error: no input files

cpp -x assembler-with-cpp "libs/context/src/asm/jump_x86_64_sysv_macho_gas.S" | as --64 -o "../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/jump_x86_64_sysv_macho_gas.o"

...failed Jamfile</Users/xx/software/boost_1_60_0/libs/context/build>.gas64 ../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/asm/jump_x86_64_sysv_macho_gas.o...
common.mkdir ../boost_build/boost/bin.v2/libs/context/build/intel-darwin-16.0/release/threading-multi/posix

When compiling with toolset=msvc, BB passes /Z7 compiler option.

But with toolset=clang-win this option is omitted. This prevents source-level debugging.

With clang 3.6, there is a new warning for the -finline-functions flag. This should be removed from clang settings.

clang: warning: optimization flag '-finline-functions' is not supported
clang: warning: argument unused during compilation: '-finline-functions'

See http://stackoverflow.com/questions/26108606/no-support-to-finline-functions-in-clang-3-5

clang --version
Apple LLVM version 6.1.0 (clang-602.0.49) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix

I'm trying to build boost using Visual Studio 2015. This is the output what I got:

Microsoft Windows [Version 10.0.15063]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\boost_1_64_0>bootstrap.bat
Building Boost.Build engine

Bootstrapping is done. To build, run:

    .\b2

To adjust configuration, edit 'project-config.jam'.
Further information:

    - Command line help:
    .\b2 --help

    - Getting started guide:
    http://boost.org/more/getting_started/windows.html

    - Boost.Build documentation:
    http://www.boost.org/build/doc/html/index.html

C:\boost_1_64_0>b2 --with-python
Performing configuration checks

    - 32-bit                   : yes
    - arm                      : no
    - mips1                    : no
    - power                    : no
    - sparc                    : no
    - x86                      : yes

Building the Boost C++ Libraries.


    - symlinks supported       : yes

Component configuration:

    - atomic                   : not building
    - chrono                   : not building
    - container                : not building
    - context                  : not building
    - coroutine                : not building
    - coroutine2               : not building
    - date_time                : not building
    - exception                : not building
    - fiber                    : not building
    - filesystem               : not building
    - graph                    : not building
    - graph_parallel           : not building
    - iostreams                : not building
    - locale                   : not building
    - log                      : not building
    - math                     : not building
    - metaparse                : not building
    - mpi                      : not building
    - program_options          : not building
    - python                   : building
    - random                   : not building
    - regex                    : not building
    - serialization            : not building
    - signals                  : not building
    - system                   : not building
    - test                     : not building
    - thread                   : not building
    - timer                    : not building
    - type_erasure             : not building
    - wave                     : not building

...found 1 target...


The Boost C++ Libraries were successfully built!

The following directory should be added to compiler include paths:

    C:\boost_1_64_0

The following directory should be added to linker library paths:

    C:\boost_1_64_0\stage\lib

But the build infrastructure didn't even create resulting folder for boost_python. The library seems to be skipped.
In release 1.63.0 the build procedure works fine for me.

Environment:
boost: 1.62
os: Windows 10
compiler: msvc-12

On start of clean build:

error: Could not create directory '/D:/Projects/somepath/.out'

In util\path.jam, in makedirs at line 458 although .out directory is created, error is logged and build stopped.

https://github.com/boostorg/build/blob/develop/src/util/path.jam#L458

I tried building boost 1.57 for qnxnto using
./b2 toolset=qcc target-os=qnxnto variant=release link=shared install
and I encountered the same issue as the one described here blackberry/Boost#11

The proposed solution of removing HAVE_SONAME in qcc.jam worked for me, and I was wondering:

• whether this issue has been solved since 1.57,
• whether removing SO_NAME is a clean solution.

Here a snippet out of bootstrap.log:

Using 'vc14' toolset.

e:\boost\boost_git\modular-boost\tools\build\src\engine>if exist bootstrap rd /S /Q bootstrap

e:\boost\boost_git\modular-boost\tools\build\src\engine>md bootstrap

e:\boost\boost_git\modular-boost\tools\build\src\engine>cl /nologo /RTC1 /Zi /MTd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG -wd4996 kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c
command.c
e:\boost\boost_git\modular-boost\tools\build\src\engine\jam.h(34): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory
compile.c
e:\boost\boost_git\modular-boost\tools\build\src\engine\jam.h(34): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory
constants.c
debug.c
e:\boost\boost_git\modular-boost\tools\build\src\engine\jam.h(34): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory
execcmd.c

I'm trying to create a feature to control the C++ version that I'm building with.

I've started with the following:

import feature : feature ;
feature cpp-version : cpp11 cpp14 :
        composite propagated optional symmetric implicit
    ;
feature.compose <cpp-version>cpp11 :
        <toolset>clang:<cxxflags>-std=c++11
        <toolset>gcc:<cxxflags>-std=c++11
    ;

One of optional or symmetric doesn't seem to work properly as without specifying cpp11 on the command line the directory isn't included in the build path. In either case the extra compile flag isn't passed on to the compiler.

If I change the feature to this:

import feature : feature ;
feature cpp-version : cpp11 cpp14 :
        composite propagated optional symmetric implicit
    ;
feature.compose <cpp-version>cpp11 :
        <cxxflags>-std=c++11
    ;

Then the compile flag is passed on if I specify cpp11 on the command line, but the default still doesn't work. This will obviously break with compilers that specify this option differently.

I'm going from the documentation here: http://www.boost.org/build/doc/html/bbv2/reference/definitions.html and here: http://www.boost.org/build/doc/html/bbv2/extending/features.html

I'm using the current master of boost build.

Compiler plugins are getting in fashion, so it will be nice to have a support for them in boost-build.

Assuming gcc toolset (clang is similar):

1. Compiler plugin is a variety of shared library which is build with some options derived by running the target compiler (e.g. "gcc -print-file-name=plugin" to set the proper include path).

2. As a dependency, compiler plugin is to be applied to the for each affected source ("-fplugin=/plugin.so").

3. An extra feature will be useful to set plugin specific flags on affected sources ("-fplugin-arg-plugin-foo=bar"). A bit of complication is caused by the fact that any "-fplugin" flags must precede "-fplugin-arg-*" flags on the gcc command line.

I have tried to work out a module of my own - p1 and p3 are pretty easy, but I could not get the p2 right (the whole generators/v-targets thing is pretty confusing),

As Boost Build manual suggests I ask this question inside an issue.
I recently started to study Boost Build and I like how it does things a lot. But when I reached the section about modules and copy-pasted the first example inside a project definition, b2 exited with an error.

Here is the full Jamroot contents:

project someproject ;

module my_module
{
    rule salute ( x ) { ECHO $(x), world ; }
    rule greet ( ) { salute hello ; }
    greet ;
}
my_module.salute goodbye ;

The output is:

hello, world
Jamroot:12: in modules.load
ERROR: rule "my_module.salute" unknown in module "Jamfile</home/grisumbras/Documents/projects/someproject>".
/usr/share/boost-build/build/project.jam:311: in load-jamfile
/usr/share/boost-build/build/project.jam:64: in load
/usr/share/boost-build/build/project.jam:145: in project.find
/usr/share/boost-build/build-system.jam:535: in load
/usr/share/boost-build/kernel/modules.jam:289: in import
/usr/share/boost-build/kernel/bootstrap.jam:139: in boost-build
/usr/share/boost-build/boost-build.jam:8: in module scope

b2 -v produces Boost.Jam Version 2014.03. OS=LINUX.

So, how a rule in a module should be invoked?

Hi,

Sorry if I am posting this in the wrong area, but I couldn't find a solution anywhere else. please point me in the right direction if needed.
I am trying to build the date-time library on a linux (ubuntu) for Android (ideally all platforms arm etc.).
I am expecting to pass some argument to b2 to give the appropriate include directories (and it worked fine). I wanted to do the same for the directories where the existing libraries are (like crtbegin_so.o).
I tried to pass the -L via the linkflags (either on the commend line or in the project-config.jam but in both case I can see that the information is passed to gcc however not to ld.
I am not sure how to find out what is wrong and how to fix it. I tried the --debug-configuration --debug-building --debug-generator but nothing obvious appears.
Any help greatly appreciated.

Eric