Boost.Test on Windows x64 - Boost-users - lists.preview.boost.org

newer
Do correct instructions for MinGW...

Boost.Test on Windows x64

older
basic_socket.hpp line 1421

User 8583

28 Jun 2013 28 Jun '13

5:41 a.m.

Hello, I am trying to use Boost.Test 1.53 on a Windows 7 x64 platform and VS2012. I compiled the libraries using .\b2 variant=release link=static threading=multi runtime-link=shared toolset=msvc-11.0 address-model=64 Linking the libraries with my (x64) test program produces the following error: libboost_unit_test_framework-vc110-mt-gd-1_53.lib(unit_test_suite.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' I am surprised as I have used the boost serialization library compiled with the same command line in x64 programs without such error. Any help appreciated, Bob

Attachments:

attachment.html (text/html — 946 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

legalize+jeeves＠mail.xmission.com

29 Jun 29 Jun

12:42 a.m.

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code thusly:

I compiled the libraries using

.\b2 variant=release link=static threading=multi runtime-link=shared toolset=msvc-11.0 address-model=64

Linking the libraries with my (x64) test program produces the following error:

libboost_unit_test_framework-vc110-mt-gd-1_53.lib(unit_test_suite.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

IIRC, this means that the library wasn't linked with the /machine:x64 option. At home, I've been using x64 Windows 7 on trunk and haven't had any problems. At work, I've been using 1.52 with a similar command to yours, except our scripts are calling bjam and not b2. Have you verified that your project was built x64? Have you tried doing just: b2 --with-test to get all the library variants? -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Reply

Sign in to reply online Use email software

User 8583

10:14 a.m.

On Sat, Jun 29, 2013 at 2:42 AM, Richard wrote:

[Please do not mail me a copy of your followup]

boost-users@lists.boost.org spake the secret code thusly:

...
I compiled the libraries using

.\b2 variant=release link=static threading=multi runtime-link=shared toolset=msvc-11.0 address-model=64

Linking the libraries with my (x64) test program produces the following error:

libboost_unit_test_framework-vc110-mt-gd-1_53.lib(unit_test_suite.obj) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

IIRC, this means that the library wasn't linked with the /machine:x64 option.

At home, I've been using x64 Windows 7 on trunk and haven't had any problems. At work, I've been using 1.52 with a similar command to yours, except our scripts are calling bjam and not b2.

Have you verified that your project was built x64?

My project in indeed in x64. When I compile it in x86, I am able to link with the Boost.Test library that is supposed to be x64. Have you tried doing just:

b2 --with-test

I just tried, but it didn't change the outcome.

Reply

Sign in to reply online Use email software

Uthpal Urubail

7:52 p.m.

New subject: fast_pool_allocator + clear memory

Even after clear, seems to be memory is not cleaned up when I use boost::fast_pool_allocator. Can someone help in correct usage? typedef std::set, boost::fast_pool_allocator< unsigned int> > IDSET; int main() { IDSET set; WriteMemoryUsage(); for (int i=0;i<1000000;i++) set.insert(i); WriteMemoryUsage(); set.clear(); WriteMemoryUsage(); return 1; } In WriteMemoryUsage Processid: 4836 Peak Memory used: 1155072 Working Set Size: 2744320 Page File Usage: 1155072 Processid: 4836 Peak Memory used: 34816000 Working Set Size: 36528128 Page File Usage: 34816000 Processid: 4836 Peak Memory used: 34816000 Working Set Size: 36532224 Page File Usage: 34816000 Regards, UJ

Reply

Sign in to reply online Use email software

legalize+jeeves＠mail.xmission.com

30 Jun 30 Jun

4:59 p.m.

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code thusly:

On Sat, Jun 29, 2013 at 2:42 AM, Richard wrote:

...
Have you verified that your project was built x64?

My project in indeed in x64. When I compile it in x86, I am able to link with the Boost.Test library that is supposed to be x64.

It sounds like auto linking of the library is picking up the wrong one. Auto-linking uses #pragma comment(lib, <name>) to specify the library name needed for linking. It doesn't specify a directory location for the library, only its name. Do you have your library search path set to the location of the x64 libraries? You can verify the library is x64 with dumpbin: D:\Code\boost\boost-trunk\stage\lib>dumpbin /all libboost_unit_test_framework-vc110-mt-gd-1_54.lib |find /i "machine" 8664 machine (x64) 8664 machine (x64) 8664 machine (x64) etc. (Mine is 1.54 because I'm building from trunk; yours would be 1.53.) Launch a VS2012 x64 Native Tools Command Prompt window to get dumpbin in your path. Between x86 and x64, the library files have the same name, so they have to be kept in different directories. b2 stage just puts the output products in stage/lib regardless of the address-type setting, so if you build both x86 and x64, then whichever one was built last overwrites the one that was built first. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Reply

Sign in to reply online Use email software

User 8583

6:52 p.m.

On Sun, Jun 30, 2013 at 6:59 PM, Richard wrote:

It sounds like auto linking of the library is picking up the wrong one. Auto-linking uses #pragma comment(lib, <name>) to specify the library name needed for linking. It doesn't specify a directory location for the library, only its name.

I am not using auto-linking, I have defined BOOST_ALL_NO_LIB and provide an explicit path to the library. Actually, CMake does it for me. I have not compiled the x86 versions of the library as I have no use of them. I have checked with the 1.54 RC (in case it would be a known issue) and have the same problem.

Do you have your library search path set to the location of the x64 libraries?

You can verify the library is x64 with dumpbin:

D:\Code\boost\boost-trunk\stage\lib>dumpbin /all libboost_unit_test_framework-vc110-mt-gd-1_54.lib |find /i "machine" 8664 machine (x64) 8664 machine (x64) 8664 machine (x64)

This is interesting, thanks for the tip. I checked with dumpbin and all the library are actually x86 binaries. However, I stated earlier that I used serialization in x64 binaries without error. That is true, but they were compiled with VS2010. I checked and all the libraries compiled with VS2010 are indeed x64 (obtainted with the same b2 command line but with the appropriate toolset). Are you also using VS2012?

Reply

Sign in to reply online Use email software

legalize+jeeves＠mail.xmission.com

8:48 p.m.

[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code thusly:

...
You can verify the library is x64 with dumpbin:

D:\Code\boost\boost-trunk\stage\lib>dumpbin /all libboost_unit_test_framework-vc110-mt-gd-1_54.lib |find /i "machine" 8664 machine (x64) 8664 machine (x64) 8664 machine (x64)

This is interesting, thanks for the tip. I checked with dumpbin and all the library are actually x86 binaries.

OK, then we're back to a build problem. I started with a fresh boost 1.53.0 zip file and did this: D:\Code\boost\boost_1_53_0>.\b2 --with-test address-model=64 That got me the following in stage\lib: D:\Code\boost\boost_1_53_0>dir stage\lib/b libboost_prg_exec_monitor-vc110-mt-1_53.lib libboost_prg_exec_monitor-vc110-mt-gd-1_53.lib libboost_test_exec_monitor-vc110-mt-1_53.lib libboost_test_exec_monitor-vc110-mt-gd-1_53.lib libboost_unit_test_framework-vc110-mt-1_53.lib libboost_unit_test_framework-vc110-mt-gd-1_53.lib I definitely got x64 libraries: D:\Code\boost\boost_1_53_0\stage\lib>dumpbin /all libboost_unit_test_framework-v c110-mt-gd-1_53.lib | find /i "machine" 8664 machine (x64) 8664 machine (x64) etc.

Are you also using VS2012?

Yes, that is the only compiler I have installed. Verify that you are running the x64 compiler: C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC>cl /? Microsoft (R) C/C++ Optimizing Compiler Version 17.00.60610.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC>cl /? Microsoft (R) C/C++ Optimizing Compiler Version 17.00.60610.1 for x64 Copyright (C) Microsoft Corporation. All rights reserved. Note that they are the same command (cl.exe). Boost should find your toolset automatically and use the right path and environment variables to find it. However, if you have explicitly set your path to include the x86 tools, it may end up using that one instead. If b2 address-model=64 gets you x86 binaries, then the wrong compiler is being used. Try unsetting your path, lib, include, etc., environment variables, running .\b2 again and then check the built libraries. None of this should be specific to boost.test either, but I didn't examine all it's bjam files to see exactly what it does to build libraries. -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Reply

Sign in to reply online Use email software

User 8583

1 Jul 1 Jul

4:33 p.m.

On Sun, Jun 30, 2013 at 10:48 PM, Richard

wrote:

[Please do not mail me a copy of your followup] If b2 address-model=64 gets you x86 binaries, then the wrong compiler is being used. Try unsetting your path, lib, include, etc., environment variables, running .\b2 again and then check the built libraries.

I have located the problem, it was of course between the keyboard and the chair. After compiling with the b2 command I mentionned, I was running a .\b2 install --prefix "mypath", a la make. This last command actually recompiled libraries in 32 bits. I did not notice because it starts spending a lot of time copying files, and also because options that are needed the first time b2 is called (like toolset) seems to be cached for the following calls of b2 while address-model is obviously not but has a default value of 32. Another small remark: the documentation in 1.54.0 has changed and mention to run bootstrap/b2 from tool/build/v2, but when I run them from there, no binary is generated. Thanks for your help Richard.

Reply

Sign in to reply online Use email software

legalize+jeeves＠mail.xmission.com

2 Jul 2 Jul

1:49 a.m.

[Please do not mail me a copy of your followup] Great, I'm glad you got it sorted out! -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

Reply

Sign in to reply online Use email software

4253

Age (days ago)

4257

Last active (days ago)

Download

8 comments

3 participants

tags

participants (3)

legalize+jeeves＠mail.xmission.com
User 8583
Uthpal Urubail