I'm attempting to manually compile Boost on Ubuntu Linux 12.04. However, it seems to be attempting to cross-compile, even though I haven't told it to.
These are the commands I used:
git clone https://github.com/boostorg/boost
git checkout boost-1.60.0
git submodule init
git submodule update
cd tools/build/
./bootstrap.sh
sudo ./b2 install --prefix=/usr/local/
cd ../../
sudo b2 -j12 --build-dir=/tmp/build_boost --build-type=complete toolset=gcc address-model=64 architecture=x86 threading=multi runtime-link=shared stage --layout=tagged
The last command fails, giving various compilation errors, all similar to the first one shown below:
gcc.compile.c++ /tmp/build_boost/boost/bin.v2/libs/system/build/gcc-arm/release/address-model-64/architecture-x86/threading-multi/error_code.
arm-linux-gnueabi-g++: error: unrecognized command line option ‘-m64’
"arm-linux-gnueabi-g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pedantic -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG -I"." -c -o "/tmp/build_boost/boost/bin.v2/libs/system/build/gcc-arm/release/address-model-64/architecture-x86/threading-multi/error_code.o" "libs/system/src/error_code.cpp"
...failed gcc.compile.c++ /tmp/build_boost/boost/bin.v2/libs/system/build/gcc-arm/release/address-model-64/architecture-x86/threading-multi/error_code.o...
How do I make sure it uses the native g++ (for x86-64)?
Found the problem: there was a user-config.jam in my home directory (probably stored temporarily during cross-compile tests). I only found out because removing all arm-linux-gnueabi-* files from /usr/bin/ led to the following error:
/home/janito/boost/tools/build/src/tools/gcc.jam:83: in gcc.init from module gcc
error: toolset gcc initialization:
error: provided command 'arm-linux-gnueabi-g++' not found
error: initialized from /home/janito/user-config.jam:45
/home/janito/boost/tools/build/src/build/toolset.jam:43: in toolset.using from module toolset
/home/janito/boost/tools/build/src/build/project.jam:1052: in using from module project-rules
/home/janito/user-config.jam:45: in modules.load from module user-config
/home/janito/boost/tools/build/src/build-system.jam:249: in load-config from module build-system
/home/janito/boost/tools/build/src/build-system.jam:389: in load-configuration-files from module build-system
/home/janito/boost/tools/build/src/build-system.jam:524: in load from module build-system
/home/janito/boost/tools/build/src/kernel/modules.jam:295: in import from module modules
/home/janito/boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module
/home/janito/boost/boost-build.jam:17: in module scope from module
At least the solution was simply to remove the ~/user-config.jam file.
Posting it as an answer so that it can be useful in the future if someone runs into the same situation.
Related
When I sudo pip install pyquery, sudo pip install lxml, and sudo pip install cython, I get very similar output with the same error that says:
x86_64-linux-gnu-gcc: error: unrecognized command line option ‘-fstack-protector-strong’
Here's the complete pip output for sudo pip install pyquery:
Requirement already satisfied (use --upgrade to upgrade): pyquery in /usr/local/lib/python2.7/dist-packages
Downloading/unpacking lxml>=2.1 (from pyquery)
Running setup.py egg_info for package lxml
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'bugtrack_url'
warnings.warn(msg)
Building lxml version 3.4.1.
Building without Cython.
Using build configuration of libxslt 1.1.28
Requirement already satisfied (use --upgrade to upgrade): cssselect in /usr/local/lib/python2.7/dist-packages/cssselect-0.9.1-py2.7.egg (from pyquery)
Installing collected packages: lxml
Running setup.py install for lxml
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'bugtrack_url'
warnings.warn(msg)
Building lxml version 3.4.1.
Building without Cython.
Using build configuration of libxslt 1.1.28
building 'lxml.etree' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/libxml2 -I/root/build/lxml/src/lxml/includes -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w
x86_64-linux-gnu-gcc: error: unrecognized command line option ‘-fstack-protector-strong’
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
Complete output from command /usr/bin/python -c "import setuptools;__file__='/root/build/lxml/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-gg4SuG-record/install-record.txt:
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'bugtrack_url'
warnings.warn(msg)
Building lxml version 3.4.1.
Building without Cython.
Using build configuration of libxslt 1.1.28
running install
running build
running build_py
copying src/lxml/includes/lxml-version.h -> build/lib.linux-x86_64-2.7/lxml/includes
running build_ext
building 'lxml.etree' extension
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/usr/include/libxml2 -I/root/build/lxml/src/lxml/includes -I/usr/include/python2.7 -c src/lxml/lxml.etree.c -o build/temp.linux-x86_64-2.7/src/lxml/lxml.etree.o -w
x86_64-linux-gnu-gcc: error: unrecognized command line option ‘-fstack-protector-strong’
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
----------------------------------------
Command /usr/bin/python -c "import setuptools;__file__='/root/build/lxml/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-gg4SuG-record/install-record.txt failed with error code 1 in /root/build/lxml
Storing complete log in /root/.pip/pip.log
The complete log from /root/.pip/pip.log is here: http://pastebin.com/5R4VZDu8
I've looked at this, this, this, and this for help, but I haven't been able to solve the issue yet.
I've already installed libxml2-dev, libxslt1-dev, and python-dev. I'm running Debian 7.0 x64 on a DigitalOcean droplet.
I'm just trying to install pyquery. Can someone please help me out?
Thanks
I ran into this problem when I attempted to upgrade my pandas version to 0.15.2
If you install gcc-4.9 you are likely to still have an older version of gcc on your system (gcc-4.7 in my case).
I can think of 3 ways to solve this issue:
a) symlink /usr/bin/x86_64-linux-gnu-gcc to
/usr/bin/x86_64-linux-gnu-gcc-4.9
if you want to be more organized about this use update-alternatives, see https://askubuntu.com/questions/26498/choose-gcc-and-g-version
b) figure out how to manually specify which compiler pip uses and set it in some sort of .conf file - I haven't examined where this file lives or if there are CLI options for pip that accomplish the equivalent. In principle, creating/editing a /usr/lib/pythonX.Y/distutils/distutils.cfg should do it. I ran into problems when I tried to use this approach.
c) Edit /usr/lib/python2.7/plat-x86_64-linux-gnu/_sysconfigdata_nd.py to reflect your updated compiler
How to use MinGW's gcc compiler when installing Python package using Pip?
https://docs.python.org/2/install/#distutils-configuration-files
I went with the quick and dirty solution (a) to force everything to work
root#localhost:/home/user1$ rm /usr/bin/x86_64-linux-gnu-gcc
root#localhost:/home/user1$ ln -s /usr/bin/gcc-4.9 /usr/bin/x86_64-linux-gnu-gcc
root#localhost:/home/user1$ pip install pandas --upgrade
. . . pandas compiles with gcc-4.9 here . . .
move things back to how they were
root#localhost:/home/user1$ rm /usr/bin/x86_64-linux-gnu-gcc
root#localhost:/home/user1$ ln -s /usr/bin/gcc-4.7 /usr/bin/x86_64-linux-gnu-gcc
One possible solution would be to use GCC 4.9 or higher, which does support the -fstack-protector-strong flag.
Instead of upgrading to GCC 4.9, I was trying to find where the flag was defined and remove it. On Debian Wheezy, I found it in /usr/lib/python2.7/plat-x86_64-linux-gnu/_sysconfigdata_nd.py which belongs to the libpython2.7-minimal package. My solution was to replace all occurrences of -fstack-protector-strong with -fstack-protector within this file. Then pip install executed the correct build command.
My goal is to make some new function to pnacl toolchain. Before I doing so, I think I should build the pnacl toolchain successfully first.
[11/04 Update]
Finally it works. Some package(bison, byacc, flex) I did't install and caused this problem.
[11/03 Update]
I use ubuntu-14.04.1-desktop-amd64 as my system
Also, ubuntu-12.04.5-desktop-amd64 is now testing [11/03 updated]
I've followed the step of the document all the way. Everything goes just fine until I run the toolchain_build_pnacl script
So I add the new error message here :
if I run the script using gcc to compile
toolchain_build/toolchain_build_pnacl.py --gcc --verbose --sync --clobber
--install toolchain/linux_x86/pnacl_newlib
then the following error message is
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/gold
-I../../../src/binutils/gold -I../../../src/binutils/gold/../include - I../../../src/binutils/gold/../elfcpp -DLOCALEDIR="\"/share/locale\""
-DBINDIR="\"/bin\"" -DTOOLBINDIR="\"/arm-pc-nacl/bin\"" -DTOOLLIBDIR="\"/arm-pc-nacl/lib\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=yyscript.o -Wno-extended-offsetof -Wno-absolute-value -Wno-unused-function -Wno-unused-const-variable -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-format-security -MT yyscript.o -MD -MP -MF .deps/yyscript.Tpo -c -o yyscript.o yyscript.c yyscript.c:1:1: error: return type defaults to ‘int’ [-Werror=return-type] yyscript.c:1:1: error: function
declaration isn’t a prototype [-Werror=strict-prototypes] cc1: error:
unrecognized command line option "-Wno-unused-private-field" [-Werror]
cc1: error: unrecognized command line option
"-Wno-unneeded-internal-declaration" [-Werror] cc1: error:
unrecognized command line option "-Wno-unused-const-variable"
[-Werror] cc1: error: unrecognized command line option
"-Wno-absolute-value" [-Werror] cc1: error: unrecognized command line
option "-Wno-extended-offsetof" [-Werror] cc1: all warnings being
treated as errors make[4]: *** [yyscript.o] Error 1
if I run it with default clang to compile
toolchain_build/toolchain_build_pnacl.py --verbose --clobber
--install toolchain/linux_x86/pnacl_newlib
then following error message is generated
/home/albaforia/SVN/nativeclient/third_party/llvm-build/Release+Asserts/bin/clang
-DHAVE_CONFIG_H -I. -I../../../src/binutils/gold -I../../../src/binutils/gold -I../../../src/binutils/gold/../include -I../../../src/binutils/gold/../elfcpp -DLOCALEDIR="\"/share/locale\"" -DBINDIR="\"/bin\"" -DTOOLBINDIR="\"/arm-pc-nacl/bin\"" -DTOOLLIBDIR="\"/arm-pc-nacl/lib\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=yyscript.o -Wno-extended-offsetof -Wno-absolute-value -Wno-unused-function -Wno-unused-const-variable -Wno-unneeded-internal-declaration -Wno-unused-private-field -Wno-format-security -MT yyscript.o -MD -MP -MF .deps/yyscript.Tpo -c -o yyscript.o yyscript.c yyscript.c:1:1: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
main() { return 0;
} ^~~~ 1 error generated. make[4]: *** [yyscript.o] Error 1
By default the PNaCl toolchain builds with a downloaded binary of clang because Google's automated builders run Ubuntu 12.04, and the gcc on those systems cannot build recent versions of LLVM. So there are 2 options:
If you used Chromium's depot_tools to get the Native Client sources, you can easily get a copy of the same compiler the builders use: from the parent directory of native_client run
tools/clang/scripts/update.sh which will download and install clang in the directory where toolchain_build_pnacl.py expects it. Once it is installed, it will be kept up to date automatically by Native Clients DEPS hooks if you use gclient from depot_tools.
Otherwise you can use the system gcc to compile the PNaCl toolchain using the --gcc option. This should definitely work on Ubuntu 14.04 as that the system we develop PNaCl on.
As an aside I've started another document that has a few more details on the build process (even if its focus isn't exactly what you are interested in) and of course there is the -h flag of toolchain_build_pnacl.py and its sources.
Could you post more information on what the error is? You probably need to scroll up a bit (the errors are interleaved with other parts of the build because it builds in parallel). To help debug this you could also run toolchain_build/toolchain_build_pnacl.py on specific targets and reduce the amount of building that goes on, e.g. you could do:
toolchain_build/toolchain_build_pnacl.py llvm_x86_64_linux --verbose --install toolchain/linux_x86/pnacl_newlib
FYI, when you re-run the toolchain_build/toolchain_build_pnacl.py script you don't need to re-specify --sync and --clobber.
You can also run the make command manually as you debug the issue. In any case we'd like to fix the issue you're running into!
To use system compiler instead of compiler from third_party/llvm_build/... you may want to pass the --gcc option to the build script. Though, it's still unlikely that you'll succeed in building toolchain under Ubuntu 14.04.
I'm using Ubuntu 14.04 and in order to build pnacl toolchain I have set up Ubuntu 12.04 chroot environment. Inside it I can successfully build the toolchain using the following commands:
# get sources for NaCl itself
gclient config http://src.chromium.org/native_client/trunk/src/native_client#13992 --name native_client
gclient sync -j16
cd native_client
# sync sources for binutils, llvm, etc.
toolchain_build/toolchain_build_pnacl.py --verbose --sync-only
# build and install toolchain
toolchain_build/toolchain_build_pnacl.py --verbose --gcc --install install_dir
PS: I mount /proc, /dev, /dev/pts, /sys, /run, /run/shm, /tmp into my chroot environment and everything runs smoothly. Without mounting some of these directories some build scripts may fail, though I'm not sure about it.
having installed IPOPT and trying to install pyipopt in Ubuntu 12.04 box, I encountered the following error:
python setup.py install
results in the following error:
running install
running build
running build_py
running build_ext
building 'pyipoptcore' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/local/include/coin/ -I/usr/include/python2.7 -c src/callback.c -o build/temp.linux-x86_64-2.7/src/callback.o
In file included from src/callback.c:36:0:
src/hook.h:5:29: fatal error: IpStdCInterface.h: No such file or directory
compilation terminated.
error: command 'gcc' failed with exit status 1
any ideas ?
this is the interface for the ipopt library which is required to compile. as stated in the setup.py file
# You will probably have to edit this file in unpredictable ways
# if you want pyipopt to work for you, sorry.
the easiest way to handle this is to adjust the setup.py accordingly:
# When I installed Ipopt from source, I used the
# --prefix=/usr/local
# option, so this is where I want pyipopt to look for my ipopt installation.
# I only installed from source because the ipopt packaging
# for my linux distribution was buggy,
# so by the time you read this the bugs have probably been fixed
# and you will want to specify a different directory here.
IPOPT_DIR = '/usr/local/'
adjust IPOPT_DIR to the path where the library has been installed on your system, which of course should has been conducted anyway.
EDIT:
If you are installing from source, just use --prefix=/usr/local for the configure script and compile and install the library by running make; sudo make install. Then you don't have to change the setup.py file.
Using the docs, I run:
$ echo "using gcc : m68k : /opt/freescale/usr/local/gcc-4.2.125-eglibc-2.5.125/m68k-linux/bin/m68k-linux-gnu-g++ ;" > tools/build/v2/user-config.jam
$ ./bootstrap.sh
$ ./bjam -d2 --toolset=gcc-m68k '-sBUILD=release static multi/single' link=static --prefix=/home/damann/coldfire/boost --layout=system --with-filesystem --with-system --with-thread --with-serialization --with-date_time install
Which gives the following errors:
error: toolset gcc initialization:
error: version 'm68k' requested but 'g++-m68k' not found and version '4.4.3' of default 'g++' does not match
error: initialized from
/home/damann/boost_1_48_0/tools/build/v2/build/toolset.jam:38: in toolset.using from module toolset
/home/damann/boost_1_48_0/tools/build/v2/build-system.jam:481: in process-explicit-toolset-requests from module build-system
/home/damann/boost_1_48_0/tools/build/v2/build-system.jam:562: in load from module build-system
/home/damann/boost_1_48_0/tools/build/v2/kernel/modules.jam:283: in import from module modules
/home/damann/boost_1_48_0/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module
/home/damann/boost_1_48_0/boost-build.jam:17: in module scope from module
It seems that the user-config is being ignored, although it is read (see it during --debug-configuration)
Discovered that (at least on Linux) bjam also looks for a user-config.jam in the user's homedir - and I had one (that I had forgotten from an earlier build) - so that one was overriding my efforts.
I'm trying to create mingw binaries for boost on a Linux machine. The mingw compiler is present on my system as /usr/bin/i586-mingw32msvc-g++ and I have been able to create a simple HelloWorld.exe application.
Here is an exact list of my actions:
$ tar xvf boost_1_46_1.tar.gz
$ cd boost_1_46_1/
$ echo "using gcc : 4.4.4: i586-mingw32msvc-g++ ;" > user-config.jam
$ ./bootstrap.sh
$ ./bjam toolset=gcc target-os=windows
The result is this:
Building the Boost C++ Libraries.
...found 83 targets...
...updating 9 targets...
common.mkdir bin.v2
common.mkdir bin.v2/libs
common.mkdir bin.v2/libs/regex
common.mkdir bin.v2/libs/regex/build
common.mkdir bin.v2/libs/regex/build/gcc-mingw-4.4.4
common.mkdir bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug
common.mkdir bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows
gcc.compile.c++ bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows/has_icu_test.o
In file included from /usr/include/unicode/pwin32.h:123,
from /usr/include/unicode/umachine.h:47,
from /usr/include/unicode/uversion.h:47,
from libs/regex/build/has_icu_test.cpp:12:
/usr/include/inttypes.h:290: warning: ISO C++ 1998 does not support ‘long long’
/usr/include/inttypes.h:291: warning: ISO C++ 1998 does not support ‘long long’
libs/regex/build/has_icu_test.cpp: In function ‘int main()’:
libs/regex/build/has_icu_test.cpp:24: warning: unused variable ‘c’
gcc.link bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows/has_icu.exe
/usr/lib/gcc/i586-mingw32msvc/4.4.4/../../../../i586-mingw32msvc/bin/ld: cannot find -licuuc
collect2: ld returned 1 exit status
"i586-mingw32msvc-g++" -L"/usr/bin" -L"/usr/lib" -Wl,-R -Wl,"/usr/bin" -Wl,-R -Wl,"/usr/lib" -Wl,-rpath-link -Wl,"/usr/bin" -Wl,-rpath-link -Wl,"/usr/lib" -o "bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows/has_icu.exe" -Wl,--start-group "bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows/has_icu_test.o" -Wl,-Bstatic -Wl,-Bdynamic -licuuc -licui18n -licudata -Wl,--end-group -g
...failed gcc.link bin.v2/libs/regex/build/gcc-mingw-4.4.4/debug/target-os-windows/has_icu.exe...
...failed updating 1 target...
...updated 8 targets...
Performing configuration checks
- has_icu builds : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
...found 8 targets...
...updating 6 targets...
common.mkdir bin.v2/libs/math
common.mkdir bin.v2/libs/math/config
common.mkdir bin.v2/libs/math/config/gcc-mingw-4.4.4
common.mkdir bin.v2/libs/math/config/gcc-mingw-4.4.4/debug
common.mkdir bin.v2/libs/math/config/gcc-mingw-4.4.4/debug/target-os-windows
gcc.compile.c++ bin.v2/libs/math/config/gcc-mingw-4.4.4/debug/target-os-windows/has_gcc_visibility.o
cc1plus: warnings being treated as errors
libs/math/config/has_gcc_visibility.cpp: In function ‘int main()’:
libs/math/config/has_gcc_visibility.cpp:13: error: visibility attribute not supported in this configuration; ignored
"i586-mingw32msvc-g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -Werror -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -I"." -c -o "bin.v2/libs/math/config/gcc-mingw-4.4.4/debug/target-os-windows/has_gcc_visibility.o" "libs/math/config/has_gcc_visibility.cpp"
...failed gcc.compile.c++ bin.v2/libs/math/config/gcc-mingw-4.4.4/debug/target-os-windows/has_gcc_visibility.o...
...failed updating 1 target...
...updated 5 targets...
- ../config//has_gcc_visibility builds : no
...found 46 targets...
...updating 1 target...
gcc.compile.c++ bin.v2/libs/math/config/gcc-mingw-4.4.4/debug/target-os-windows/has_long_double_support.o
...updated 1 target...
- ../config//has_long_double_support builds : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
************************************************************
Trying to build Boost.Thread with pthread support.
If you need pthread you should specify the paths.
You can specify them in site-config.jam, user-config.jam
or in the environment.
For example:
PTW32_INCLUDE=C:\Program Files\ptw32\Pre-built2\include
PTW32_LIB=C:\Program Files\ptw32\Pre-built2\lib
************************************************************
/home/francis/orig/boost_1_46_1/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target
error: Duplicate name of actual target: <pstage/lib>libboost_date_time.a
error: previous virtual target { common%common.copy-libboost_date_time.a.STATIC_LIB { gcc%gcc.archive-libboost_date_time.a.STATIC_LIB { gcc%gcc.compile.c++-gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_date_time.a.STATIC_LIB { gcc%gcc.archive-libboost_date_time.a.STATIC_LIB { gcc%gcc.compile.c++-gregorian/greg_month.o.OBJ { gregorian/greg_month.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/greg_weekday.o.OBJ { gregorian/greg_weekday.cpp.CPP } } { gcc%gcc.compile.c++-gregorian/date_generators.o.OBJ { gregorian/date_generators.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release
error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug
/home/francis/orig/boost_1_46_1/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)#3884
/home/francis/orig/boost_1_46_1/tools/build/v2/build/virtual-target.jam:135: in object(file-target)#3884.actualize from module object(file-target)#3884
/home/francis/orig/boost_1_46_1/tools/build/v2/build-system.jam:748: in load from module build-system
/home/francis/orig/boost_1_46_1/tools/build/v2/kernel/modules.jam:283: in import from module modules
/home/francis/orig/boost_1_46_1/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module
/home/francis/orig/boost_1_46_1/boost-build.jam:17: in module scope from module
It says libicu is not found on my system, but according to Synaptic Package Manage I have the libicu-dev package installed.
I'm not sure how to get it right. Can anyone help?
Update 1
Following #Luke's recoommendation I now gcc-mingw toolset. So now my build instructions look like this:
tar xvf boost_1_46_1.tar.gz
cd boost_1_46_1/
echo "using gcc : 4.4.4: i586-mingw32msvc-g++ ;" > user-config.jam
./bootstrap.sh
./bjam toolset=gcc-mingw target-os=windows
Which leads to the following errors:
error: toolset gcc initialization:
error: version 'mingw' requested but 'g++-mingw' not found and version '4.4.5' of default 'g++' does not match
error: initialized from
/home/francis/orig/boost-mingw/boost_1_46_1/tools/build/v2/build/toolset.jam:38: in toolset.using from module toolset
/home/francis/orig/boost-mingw/boost_1_46_1/tools/build/v2/build-system.jam:481: in process-explicit-toolset-requests from module build-system
/home/francis/orig/boost-mingw/boost_1_46_1/tools/build/v2/build-system.jam:561: in load from module build-system
/home/francis/orig/boost-mingw/boost_1_46_1/tools/build/v2/kernel/modules.jam:283: in import from module modules
/home/francis/orig/boost-mingw/boost_1_46_1/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module
/home/francis/orig/boost-mingw/boost_1_46_1/boost-build.jam:17: in module scope from module
Update 2
I have also tried specifying gcc-mingw in the user-config.jam file. Then my build instructions look like this:
tar xvf boost_1_46_1.tar.gz
cd boost_1_46_1/
echo "using gcc-mingw : 4.4.4: i586-mingw32msvc-g++ ;" > user-config.jam
./bootstrap.sh
./bjam toolset=gcc-mingw target-os=windows
Which leads to:
error: version 'mingw' requested but 'g++-mingw' not found and version '4.4.5' of default 'g++' does not match
Update 3
Specifying g++-mingw in the user-config.jam file:
using g++-mingw : 4.4.4: i586-mingw32msvc-g++ ;
...leads to the same error.
I got similar error messages. Eventually I was able to compile it using exactly the following commands:
$ echo "using gcc : : i686-w64-mingw32-g++ ;" > user-config.jam
$ ./bootstrap.sh
$ ./b2 --user-config=user-config.jam toolset=gcc-mingw target-os=windows release
I believe your problem is that you don't specify the "--user-config=user-config.jam" parameter. The next problem I encountered was that there will be a name conflict unless I specify either debug or release build (--layout=tagged or --layout=versioned might work also).
Cross-compiling boost 1.72.0 for Windows on Ubuntu 18.04
Install MinGW
$ sudo apt install mingw-w64 mingw-w64-tools
$ sudo update-alternatives --set i686-w64-mingw32-g++ /usr/bin/i686-w64-mingw32-g++-posix
$ sudo update-alternatives --set i686-w64-mingw32-gcc /usr/bin/i686-w64-mingw32-gcc-posix
$ sudo update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
$ sudo update-alternatives --set x86_64-w64-mingw32-gcc /usr/bin/x86_64-w64-mingw32-gcc-posix
32-bit Compilation (install path: ./boost-x86)
$ echo "using gcc : : i686-w64-mingw32-g++ ;" > user-config.jam
$ ./bootstrap.sh
$ ./b2 --user-config=./user-config.jam --prefix=./boost-x86 target-os=windows address-model=32 variant=release install
64-bit Compilation (install path: ./boost-x64)
$ echo "using gcc : : x86_64-w64-mingw32-g++ ;" > user-config.jam
$ ./bootstrap.sh
$ ./b2 --user-config=./user-config.jam --prefix=./boost-x64 target-os=windows address-model=64 variant=release install
I had some difficulty with this too, but it seems to be working for me now. To be clear, I'm cross compiling on Linux for Windows.
in user-config.jam:
using gcc : mingw32 : i686-w64-mingw32-g++ ;
Note that the second term "mingw32" is an arbitrary "version" tag. The toolset flag combines the compiler name and the version name w/ a dash. So, in my case, gcc-mingw32. The third term is what actually gets invoked ("i686-w64-mingw32-g++"). Obviously your version of mingw's compiler may have a different name.
Here is how I invoked bjam:
./b2 toolset=gcc-mingw32 target-os=windows threadapi=win32 --build-type=complete --prefix=/usr/x86_64-w64-mingw32/local --layout=tagged --without-python -sNO_BZIP2=1 -sNO_ZLIB=1
I got all the interesting flags from Congelli501's answer. But didn't bother with the directory of links approach.
This is the commands I use. I have tested them for boost 1.46 and 1.49.
To begin, create links to the compiler inside /usr/i686-w64-mingw32/bin. You can run this script :
#!/bin/bash
binDir="/usr/bin"
destDir="/usr/i686-w64-mingw32/bin"
cd "$binDir"
mkdir -p "$destDir"
for name in $(ls i686-w64-mingw32*); do
newName=$(echo "$name" | sed -e "s/i686-w64-mingw32-\(.\?\)/\1/")
if [ -f "$destDir/$newName" ]; then
rm "$destDir/$newName"
fi
ln -s "$binDir/$name" "$destDir/$newName"
done
Then, install bjam. On ubuntu / debian, it is included in the package "libboost1.48-dev"
apt-get install libboost1.48-dev
To finish, become root and run
env PATH=/usr/i686-w64-mingw32/bin:$PATH bjam toolset=gcc target-os=windows variant=release threading=multi threadapi=win32 link=static --prefix=/usr/i686-w64-mingw32 -j 4 --without-mpi --without-python -sNO_BZIP2=1 -sNO_ZLIB=1 --layout=tagged install
Done !
According to this it looks like you should be using the toolset=gcc-mingw. You have toolset=gcc.
As Luke already mentioned, toolset=gcc-mingw will certainly help.
Your libicu-dev is 99% sure the linux library headers, which is not for mingw. You'll either have to build it yourself or get it from someplace (could be your distribution, otherwise you'll need to build it from source)
I had same problem. Try specifying only a single build variant (i.e., add "variant=Release link=shared runtime-link=shared")